← writing

ard-to-analytics: analytics implementation as code

2026-07-11
analyticsmeasurementopen-source

Analytics implementations drift. The ARD says one thing, the GTM container does another, and the QA spreadsheet describes a third version that never shipped. Every handoff between documents is a chance for the spec to mutate quietly, and in pharma the mutations carry compliance risk.

I released ard-to-analytics to fix the handoff problem. It generates five artifacts from a single spec.json file, so what the ARD describes is exactly what the container deploys and exactly what the test plan validates.

What it produces

  1. Technical discovery from live page analysis — what's firing, what's missing, what's misconfigured.
  2. Analytics Requirements Document with objectives, KPIs, and event specifications.
  3. GTM container in importable JSON — no manual tag authoring.
  4. QA test plan with verification cases tied back to the ARD line items.
  5. GA4 setup checklist covering custom dimensions, conversions, and audience definitions.

All five are generated from the same spec. Change a parameter name in one place and it propagates everywhere. The drift problem becomes structurally impossible.

Why a single source file matters

Manual container builds are slow and error-prone in ways that don't surface until after launch. A tag fires on the wrong trigger. A custom dimension index doesn't match the GA4 property. An event name in the QA sheet doesn't match what's actually deployed. These are ordinary mistakes in an ordinary workflow, and each one burns hours of debugging time.

Deterministic generation from spec.json means every artifact is consistent by construction, not by careful manual cross-referencing. A validation gate checks for structural issues, unresolved references, and — for pharma and healthcare implementations — PII and PHI exposure before anything ships.

How to use it

The tool works as a Claude skill or as standalone Python scripts. As a skill, you describe what you need in plain language and review outputs at each stage. Standalone, you run the generators directly against your spec file.

python scripts/generate_container.py spec.json
python scripts/validate.py spec.json
python scripts/generate_test_plan.py spec.json

Python 3.9+, no heavy dependencies.

What it's for

This grew out of repeated client work — the same implementation workflow, the same categories of mistakes, the same hours spent reconciling documents that should have been generated from a single source. Regulated industries benefit most because the compliance validation is built in, but the consistency problem exists everywhere analytics implementations involve more than one deliverable.

The repo is MIT-licensed and on GitHub.

machine-readable: markdown · rss · llms.txt
open in: chatgpt · claude · perplexity
more writing ↗