US telehealth practice
an offline conversion channel for paid subscriptions, delivered on infrastructure I hosted. Rated 5 out of 5; current channel availability has not been re-verified.
Tracking & attribution engineeringClient work
I check Meta's data-source restrictions before building permitted conversion events and audiences, with consent respected and order-level reconciliation.
Sounds familiar?
How I solve it
I check the data-source category, context and applicable restrictions before designing measurement. Removing product details does not automatically make a purchase event or audience permitted. I build only permitted collection, with consent on both the browser and server routes, and reconcile the recorded events against real orders. Events that cannot be shared stay in internal reporting.
The process
6 steps. Scope and a fixed price are agreed before the first one.
Read-only inventory of what every tag and server integration currently sends, event by event, parameter by parameter.
Separate the layers: ad policy inputs (creative, targeting) stay with your media team; data obligations and measurement are what this work touches.
Check whether each event may be shared before reducing its payload. Health-conditional detail stays out; prohibited events are withheld.
Review audience criteria and their source context; retire prohibited audiences rather than renaming them as behavioural.
Gate both pipes on consent, with deduplication if pixel and server both run.
Reconcile Meta's reported conversions against store orders, order by order, and repeat on a rhythm.
Handover
A written verdict on what your measurement sends today and what should change; then, per fix: the corrected event design, the rebuilt audiences, the consent-gated collection, and a reconciliation report you can hand to your media team with a straight face.
Built with
Proof
Client work Done for real clients. Client details are anonymised.
Before → after
The intended change is from general-store defaults to permitted collection, reviewed audience criteria, consent gates and reconciliation with orders. Restricted or withheld events remain visible in internal reporting. For one UK subscription supplements brand, the audit stood alone: the rebuild was agreed and never ran, because access was revoked before work started — which is also why I quote on read-only diagnosis first.
US telehealth practice
an offline conversion channel for paid subscriptions, delivered on infrastructure I hosted. Rated 5 out of 5; current channel availability has not been re-verified.
UK subscription supplements brand
a read-only tracking audit delivered; the rebuild was agreed and then access was revoked before any work started. The audit stands; the rebuild never ran.
UK supplement brand, pre-launch
measurement set up before launch; acceptance pending.
What you can look at
A redone event map — page, event, parameters, destination — on synthetic data, with the health-conditional fields visibly absent. No client, catalogue or order-volume data appears in it.
Client details anonymised; no names, domains or account IDs. This is technical implementation, not legal advice: whether an entity is HIPAA-covered, and what privacy law requires of its data, is a determination for counsel.
Price and timeline
A Tracking Health Check, USD 395, read-only, one store and one agreed question, written verdict two working days after the kickoff and confirmed access. A Focused Fix, from USD 450, for one bounded cause at a fixed quote. Several stores or a full server-side rebuild is a Custom Engineering Project, from USD 1,500.
QuoteFixed before work starts
A note from Daniilbefore you decide
If you sell nothing health-adjacent, the general measurement stack applies. If you already operate under a written compliance position, hand it over — the build implements it rather than re-deriving it. And if the question is how to get ads approved, that is a creative and policy question for your media team and Meta’s own pages, not a tracking engagement.
— Daniil
Questions
No. It is read-only: one store, one agreed question, up to three systems, and a written verdict two working days after the kickoff and confirmed access. For this category the standing question is what your tags actually send, and whether it matches what your compliance position says.
No. Condition- or symptom-specific criteria can encode health information. Product-specific cart and purchaser segments can do so too. I check the data-source category, context and applicable restrictions before building an audience; a behavioural label is not proof that it is permitted.
Possibly, and that determination is not mine to make. HIPAA turns on covered-entity status and business-associate relationships; getting it wrong is not a tracking bug. The sequence is counsel first, architecture second — the build takes the compliance answer as an input.
The first answer is free, within one working day. Or write directly: next@taskfordaniel.com