Privacy
Privacy and data handling
This page explains how the Hassan Ali website handles browsing context and contact submissions, why that information is used, how optional analytics choices work, and how to ask about a contact record.
At a glance
The implemented data flow
- 01Browsing context
First-party cookies preserve visitor, session and attribution context on eligible public page requests.
- 02Optional analytics
A tag container can load only when it is configured and you choose Allow analytics.
- 03Contact submissions
Form details and relevant page, campaign and consent context are sent to Hassan Ali's enquiry workflow for review and response.
01 / Contact information
Information provided with a message
The public contact form asks for a name, email address and message. It also requires confirmation that the details may be used to respond to the message.
- Required
- Name, email address, message and contact consent.
- Optional
- Company or organisation, Website / LinkedIn and opportunity type.
- Not requested
- The current public form does not display a phone field.
- Submission metadata
- The form key, page and placement identifiers, submission ID, idempotency key, submission timestamp, visitor and session identifiers, and analytics-consent snapshot accompany the forwarded message.
Contact consent is separate from optional analytics consent. Choosing Essential only does not prevent the contact form from being submitted.
02 / Automatic context
Attribution and operational information
The site creates and carries context that connects a public visit to a later contact submission. These values are not visible form fields.
- Visit identifiers
- Random visitor and session identifiers created by the site.
- Page context
- The first landing URL, path and query string, plus the conversion URL, path and timestamp attached when a message is submitted.
- Referral context
- Initial and latest external referrers, together with the referrer and landing page associated with first-touch and last meaningful-touch attribution.
- Campaign context
- UTM source, medium, campaign, campaign ID, term and content when present in the URL.
- Advertising identifiers
- Google, Microsoft, Meta, LinkedIn and TikTok click identifiers when those values are present in the URL.
- ValueTrack context
- Campaign and ad-group IDs, keyword, match type, device, network, creative, placement, target and configured location IDs when present.
- Configured extras
- Additional query-parameter values only when their keys have been placed on the server allowlist.
- Abuse-prevention event
- A keyed one-way hash derived from the incoming request IP is held temporarily in server memory with the form key and event time for rate limiting. Raw request IP is not included in the forwarded submission.
03 / Cookies and storage
First-party context and analytics choice
| Name or storage | Category | Purpose | Current default |
|---|---|---|---|
tr_vid | Necessary context | Random first-party visitor identifier. | 400 days by default; server-configurable. |
tr_sid | Necessary context | Random first-party session identifier. | 30 minutes by default; server-configurable. |
tr_attr | Necessary context | First- and last-touch attribution, referrer and landing context. | 400 days by default; server-configurable. |
tr_consent | Preference | Remembers a granted or denied optional-analytics choice. | 1 year. |
Session storage success key | Operational | Prevents the same accepted-message success event from being emitted twice in one browser session. | Current browser tab or session. |
The first three cookies support necessary site and attribution functions and are set on eligible public page requests even when optional analytics is not allowed. They are server-set as HttpOnly and SameSite=Lax; production code also marks them Secure. The consent cookie is readable by the preference control, uses SameSite=Lax and is marked Secure on HTTPS.
04 / Uses, access and retention
How records are used and controlled
- Review and response
- Contact details and the message are used to review and respond to the submission and administer its record.
- Submission context
- Page and campaign context is used to understand how a submission reached the site. Visitor and session identifiers and the consent-state snapshot connect that context to the submission.
- Abuse prevention
- The keyed request-IP hash is used to limit repeated submissions within the configured rate-limit window.
- Enquiry delivery
- Messages and their attribution context are forwarded over HTTPS to Hassan Ali's enquiry workflow on an external server. That workflow handles review, response and any subsequent storage.
Submission and administration controls
- Same-origin and JSON content-type checks.
- Form-route allowlisting, field validation and length limits.
- A hidden honeypot field and a minimum completion-time check.
- Best-effort duplicate handling and keyed request-IP rate limiting within each server instance.
- HTTPS delivery with a timeout and an error message if the receiving endpoint does not accept the submission.
- Stable submission identifiers so the receiving workflow can recognise retries.
05 / Requests and preferences
Requests about your information
Use the contact page to ask about contact information associated with a submission, or to request a correction or removal. Include the email address used and enough context to identify the relevant record.