Your ARD should be compiled, not written.

Three artifacts, three truths

An analytics build for a biopharma site produces at least three artifacts: an analytics requirements document (ARD) that says what will be measured, a tag manager container that implements it, and a GA4 property configured to receive it. In most engagements they are authored separately — the ARD in a doc, the container by hand in GTM, the GA4 setup from memory of both. They agree on the day of sign-off, and then they drift.

We inherit accounts like this constantly. The ARD says the form conversion fires on submission; the container actually fires it on the thank-you page; GA4 still has the Enhanced Measurement auto-event switched on next to the custom one, double-counting every download. Nobody lied. Three documents were maintained by three people on three timelines, and nothing forced them to agree. A measurement plan that lives in three places is not a plan. It is three opinions.

In a regulated account, drift is not cosmetic. The parameter someone adds mid-build “for context” is how a raw ZIP code or an email address ends up in an analytics payload — and the ARD, the document compliance reviewed, still says it never happens.

The other failure: an ARD written blind

Most ARDs are drafted from an intake call and a sitemap. But the decisions that make or break the tagging live in the site itself. Whether the form is native or an embedded HubSpot or Marketo iframe decides whether the conversion is a submit event or a confirmation page view. Off-domain PDFs and third-party enrollment flows change how downloads are triggered. A leaving-site interstitial intercepts the outbound clicks you planned to count. And the pixels already firing — plus anything identifying in a URL query parameter — belong in the requirements at the highest severity, not in a tagging footnote discovered during QA.

So the process starts by looking: fetch the conversion page, its confirmation page, and the locator, and read the platform, form technology, existing tags, consent tooling, and data-leak risks off the live site before requirements are finalized. The site corrects assumptions the interview can’t.

One spec, generated artifacts

The structural fix is to stop treating the ARD as the source of truth and demote it to a rendering. The source of truth is a machine-readable spec — every event, parameter, trigger, and compliance rule in one file. The ARD is written from the spec. The GTM container is generated from the spec by a deterministic script and checked by a linter. The QA test plan and the GA4 setup checklist come from the same file. When scope changes, you edit the spec and regenerate; the artifacts stay consistent by construction instead of by discipline.

The process keeps two human gates where judgment actually lives: the event list is signed off before the ARD is drafted, and the ARD is signed off before any container is built. Everything downstream of judgment is compilation.

Compliance as a compile-time check

For pharma, the compliance posture belongs in the spec, not in a policy appendix: no PII or PHI in the dataLayer, no raw ZIP codes to analytics (derive a region instead), condition-level dimensions to GA4 only and never to ad platforms, page URLs sanitized of identifying query parameters, consent wired before any tag fires. Encoded in the spec, these stop being guidance and become validations — the build fails on a PII-shaped parameter the way code fails on a syntax error. A linter that refuses to emit a leaking container does more for compliance than any signed PDF.

The pipeline is public

We open-sourced the whole thing: github.com/bzipkin/ard-to-analytics holds the intake template, the site-recon script, the spec schema, the ARD template, the deterministic container generator with its compliance linter, the QA plan generator, and the GA4 checklist — runnable as a Claude skill or as standalone Python. If you keep writing ARDs by hand, take the structure anyway: recon before requirements, one spec, human gates, generated QA.

Four signs your ARD has already drifted

1. The event names in GA4 don’t match the ARD’s event table. Someone renamed in one place. Every downstream report is now reading a dimension the requirements never defined.
2. “Form conversion” has two definitions. The document says submit; the container says thank-you page. With embedded pharma forms this is the most common split we find, and it quietly changes the conversion count.
3. Enhanced Measurement was never reconciled. GA4’s automatic file_download is counting alongside the custom download event the ARD specified. Two numbers, one behavior, and the report picks whichever flatters.
4. Scope changed after sign-off and only the container was updated. If the ARD wasn’t re-issued, it stopped being requirements and became history.

Any one of the four means the document and the data have parted ways. Patching the doc restores agreement for a week. Rebuilding the process — one spec, generated artifacts — restores it for the life of the account. An ARD you cannot regenerate is an ARD you cannot trust.