Central Eurasian Hub
Privacy policy
Version dated 27 August 2026
This policy explains what data the Central Eurasian Hub (CEH) website receives, why it is needed and what controls are available. We follow data minimisation: the short forms ask only for information needed to answer a specific B2C or B2B enquiry.
1. Who processes the data
This page describes data processing on the Central Eurasian Hub website. The operator’s legal details and a dedicated privacy contact must be approved and published before server-side enquiry delivery is enabled.
If a server adapter is not configured or is unavailable, the website does not claim that the form was sent. Instead, the user may open a direct CEH Telegram contact, review the message and send it from Telegram.
2. Data we receive
The fields depend on the selected B2C or B2B route.
- B2C: name, contact details, an optional objective or direction, and a preference for a message first or a short call.
- B2B: name, company and enquiry purpose, phone or Telegram, email, and a preferred contact time — as soon as possible or a selected date and time.
- Shared technical details: selected route and language, consent state, a submission identifier and, when present, UTM parameters and an external referrer.
- A hidden honeypot field is used only to reject automated spam and is not a field the user is expected to complete.
3. How the data is used
Data is used to validate the enquiry, route it as B2C or B2B, identify a relevant next step and respond through the supplied channel.
When following a direct Telegram link, Telegram receives only the message and details that the user reviews and sends in its interface. Data is not sold or used for automated legally significant decisions.
4. Consent
Before server-side delivery, the form requires explicit consent to process data for responding to the enquiry. Consent may be withdrawn through the operator’s published contact; withdrawal does not affect processing that was lawful before it was received.
A direct Telegram message is sent by the user under Telegram’s terms. Declining analytics does not limit access to the site content, form or direct contacts.
5. Delivery and storage
The website does not use Supabase, its own lead database or any other persistent enquiry store. Only when a server-side adapter is configured may a validated enquiry be delivered to an operator-authorised Telegram, email or CRM channel. Connection secrets remain on the server.
When no server adapter is available, the safe fallback is a direct public Telegram contact: Olzhas Baimagambetov — @seanrichmohammed, or Vitaliy Domanin — @v_domanin. The website does not put personal form data into the link or send a message automatically: the user decides what to send and confirms it inside Telegram.
For rate limiting and safe retries, a server instance may briefly keep technical state in memory. This is not a persistent or distributed database; the state expires after its operational window and may disappear earlier when the instance restarts.
After confirmed delivery, any further retention is determined by the operator and the connected Telegram, email or CRM provider and must be limited to the enquiry purpose and applicable requirements.
6. Cookies, local storage and analytics
The site stores the analytics preference in localStorage. An unfinished short-form draft, its technical submission identifier, UTM attribution and external referrer may be kept only in the current tab’s sessionStorage. The draft is cleared after confirmed server delivery; with the direct Telegram fallback it remains available for review or copying until the tab session ends.
GA4 and Yandex Metrica load only after consent and only when their identifiers are configured. Form field values are not included in analytics events.
A direct link opens the external Telegram service, which applies its own privacy, cookie and retention rules. Opening that link does not give Telegram the form draft.
7. Security and minimisation
In server-adapter mode, the server validates the form, limits request size and frequency and uses a honeypot. Integration secrets and personal data must not appear in client code or diagnostic messages.
To prevent abuse, the server or hosting platform may briefly process technical request signals, including a truncated network-address hash and technical logs, within its configured access and retention rules.
With the direct Telegram fallback, the website does not transmit the draft to a CEH server. The user controls the message contents before sending them through the external service.
No internet service can guarantee absolute security. We apply measures proportionate to the volume and nature of the data.
8. User rights
A user may request information, correction, cessation or deletion within applicable requirements. Locating an enquiry may require verification of the contact used. If a message was sent directly through Telegram, the request should be addressed to the operator and, where applicable, Telegram’s own data controls should also be used.
9. Policy updates
The current version is published on this page with its update date. Changes to form fields, delivery mode, purposes or data categories must be reflected in this policy and the consent text.
