Cookieless attribution: a first-party data plan for clinics
A first-party data plan a clinic can build in six months: consent and consent mode, CRM identity, server-side collection and offline conversion write-back.
By Roozbeh Nazari · CEO
The end of the third-party cookie was postponed several times, and Google eventually announced that it was dropping the plan to force its removal in Chrome; but clinics' attribution problem was never limited to the cookie anyway. Because of the restrictions Safari and Firefox have applied for years, the iOS tracking prompt, consent management and ad blockers, a share of a clinic website's conversions never reaches the measurement layer at all. This article is not about the theory of the "cookieless" debate; it describes a first-party data plan a clinic can build within six months: what you collect, under which permission, where you send it and in which report you read it.
We covered the conceptual side earlier in the cookieless attribution article; here we take the same problem through a clinic example, in setup order. The example clinic has a site in four languages, a WhatsApp-heavy lead flow and a CRM; on the advertising side it runs Google Ads and Meta.
Layer one: consent and the legal ground
A first-party data plan starts with law, not with technology. Every piece of data collected on a clinic website touches health data; when a patient fills in a form from a treatment page, the form itself is a statement of health interest. Under KVKK, Turkey's data protection law, health data is special-category personal data, so collection, storage and transfer to an advertising platform each need a separate legal assessment. This article is not legal advice; before implementing the plan, settle the privacy notice, the explicit consent mechanism and the transfer conditions with your data protection adviser.
The technical counterpart is a consent management platform and Google's consent mode. Google's documentation says consent mode has no banner of its own; it passes the decision of your existing consent banner to the tags. In basic mode, no tag loads until consent is given; in advanced mode the tags load, send cookieless pings when consent is denied, and Google fills the gap with modelling. Which mode is appropriate for a clinic is the outcome of the legal assessment; we only note that the two modes produce different measurement results.
Layer two: identity and the CRM
The backbone of cookieless attribution is not a cookie but the identity you assign. The patient gets a CRM record at first contact; source information (campaign, page, language, click ID) is written to that record at the moment of first contact, and every subsequent step (consultation, quote, deposit, treatment) is added to the same record. We described this setup for a WhatsApp-heavy flow in the WhatsApp Business API funnel article.
On the GA4 side this identity is carried by User-ID. Google's help page says User-ID connects your own identifier to user behaviour, may not exceed 256 characters, and may not contain information a third party could use to identify the person. In practice the CRM's own patient number is not used; a random token derived from it is. The "blended" or "observed" choice in the reporting identity setting is also made at this stage.
Layer three: server-side collection
Some tags that run in the browser never run at all. Server-side tagging sends the event first to a server under your control and forwards it to the platforms from there; the decision about which data goes to which platform is made on your server. We covered the setup decisions and cost items in the server-side tagging article. The Meta counterpart is the Conversions API; Meta's documentation explains that events sent from the server are processed the same way as Pixel events, and that deduplication is applied when the same event arrives through both channels.
Layer four: writing the conversion back
In a clinic the real conversion does not happen on the site; the treatment happens weeks later, in the clinic. Google Ads' offline conversion import documentation describes exactly this situation: every ad click is assigned an identifier (GCLID), you store it in the CRM, and when the conversion happens you send it back together with the identifier. The same document says these uploads moved to the Data Manager API as of 15 June 2026; integrations still using the old Google Ads API route need updating.
Enhanced conversions are the second write-back route. Google's documentation explains that first-party data such as email and phone is normalised, hashed with SHA256 and then sent, and that the "enhanced conversions for leads" variant matches a web lead to an offline sale. A specific note for clinics is needed here: in a health data context, transferring hashed personal data to an advertising platform falls within the legal assessment in layer one, and the platforms' health-related personalisation policies add further restrictions. Being technically possible does not mean it should be done.
What not to collect
A first-party data plan is not a "collect everything" plan. The safest principle for a clinic is data minimisation: what attribution needs is which source the patient came from and which stage they reached; not which treatment they asked about, their medical history or the photo they uploaded. That second group stays in the CRM and never enters the measurement layer. In the event parameters sent to GA4, carry the page category instead of the treatment name, and only the fact that a conversation started instead of the WhatsApp message content. For every field going to a platform, ask "can we not attribute without this?"; the answer is usually "we can".
The six-month implementation order
- Month 1: data inventory, privacy notice, consent platform and the consent mode decision.
- Month 2: source fields and click ID storage in the CRM; writing the source in the WhatsApp and form flows.
- Month 3: server-side container, GA4 User-ID, Meta Conversions API and the deduplication test.
- Month 4: offline conversion write-back (Data Manager API) and the enhanced conversions decision.
- Months 5-6: putting the platform report and the CRM report side by side, variance analysis and reading the modelling effect.
What you read in the report
The output of this plan is a single table: leads, consultations, deposits and treatments by source, from the CRM. Platform reports are placed next to that table, not above it; the conversion count Google Ads shows is modelled, the count in the CRM is observed, and the gap between them tells you which layer of the plan is missing. If the gap is large and in the platform's favour, the modelling is too optimistic or deduplication is not working; if it is in the CRM's favour, click IDs are not being stored or the write-back is incomplete. This reading is done monthly and each month ends with one layer being fixed. Setting up this report is a standard deliverable of our analytics and data service; for clinics the difference is that health data constraints are built into every layer.
Conclusion
Attribution in a cookieless world is not about finding a new cookie to replace the lost one; it is about keeping identity, consent and conversion in your own system and giving them back to the platforms in a controlled way. For a clinic the order does not change: law first, then identity, then server-side collection, and write-back last. Projects that reverse this order end with a setup that works technically but cannot be defended legally.