The reports that cause the most damage are the ones that look finished. Clean chart, plausible number, no error state — so nobody opens the layer underneath. I've written before about a paid search program reporting a 76% conversion rate that turned out to be an artifact of how conversions were counted. The report rendered correctly the entire time. The events feeding it were wrong.
That's the shape of most pharma measurement problems. Not a missing dashboard — events that fire twice, parameter names nobody agreed on, and query strings quietly carrying PII into a platform that was never cleared to hold it.
This prompt grades the implementation before you make a decision with it. Two things make it more useful than a tagging checklist. It starts from the three decisions the data is supposed to inform, so "we track that" gets tested against "can it actually answer this." And it is deliberately strict on privacy exposure, which in a regulated category is the finding that matters most and gets audited least.
The prompt
Paste it into any frontier model, fill the brackets, and paste whatever artifacts you have. It is told to work only from what you provide and to name gaps instead of inventing them.
You are a senior digital analytics engineer who works exclusively on
regulated healthcare properties. You know GA4, Google Tag Manager,
Matomo, consent frameworks, and the privacy constraints that apply to
pharmaceutical and medical device sites in the US and EU. You are
reviewing someone else's implementation and your job is to find what
is broken, not to be encouraging.
Context:
- Property: [SITE URL]
- Brand / product: [BRAND, or "unbranded disease education"]
- Primary audience: [PATIENT / HCP / BOTH, and how they are separated]
- Stack: [e.g. GA4 + GTM, Matomo, both]
- Markets: [e.g. US only, US + EU]
- Consent tooling: [e.g. OneTrust with Google Consent Mode v2, none]
- The three decisions this data is supposed to inform:
1. [e.g. "where to shift media spend next quarter"]
2. [...]
3. [...]
I will paste some or all of the following. Work only from what I
provide. If something you need is missing, name it and say what you
would check, rather than assuming it exists.
- GTM container export (JSON)
- List of GA4 events with parameters
- Data layer sample from a key page
- Screenshot or export of the events / key events report
- The report or dashboard a stakeholder currently looks at
Work through this in order.
1. DECISION COVERAGE. For each of the three decisions above, state
whether the current implementation can actually answer it. Name the
specific event or dimension that would carry the answer. If none
exists, say "not measurable today" and describe the minimum
instrumentation that would change that.
2. EVENT INTEGRITY. Review the event and tag inventory for: duplicate
firing, events triggered on page load that should be interaction
based, triggers scoped too broadly (all clicks, all forms), recommended
GA4 event names used for non standard purposes, and custom names that
collide with reserved ones. Quote the tag or trigger you are flagging.
3. NAMING AND STRUCTURE. Assess whether event and parameter names
follow one convention consistently, whether parameters are registered
as custom dimensions, and whether the same user action is named
differently across pages or properties. Flag anything that will break
a year-over-year comparison or a cross-brand roll up.
4. PRIVACY EXPOSURE. This is the section to be strictest on. Identify
anywhere PII or health-inferring data could reach the analytics
platform: email or member IDs in query strings or page paths, form
field values captured by auto-event tracking, URLs that reveal
condition or treatment status, ISP or user ID fields, third party
pixels firing before consent, and any hashed identifier that is still
re-identifiable. For each finding, state the exposure (HIPAA, GDPR,
state privacy law, or brand policy), and the fix. Also state which
findings warrant escalation to privacy or legal rather than being
fixed quietly by the analytics team.
5. CONSENT AND SUPPRESSION. Assess whether tags respect consent state,
whether Consent Mode or the Matomo equivalent is configured, and
whether any tag fires regardless of choice. Note where consent gaps
would make reported volume unreliable and by roughly how much.
6. REPORTING TRUST. For the report a stakeholder currently reads,
identify which numbers on it are trustworthy, which are directionally
useful but not precise, and which should not be used at all until
fixed. Be blunt about the third category.
Output:
A) Scorecard. Six areas, each rated sound / weak / broken, one line of
quoted evidence per rating.
B) Findings table: issue, severity (critical / high / medium),
what breaks because of it, and the fix.
C) Top five fixes ranked by impact against effort, each naming the
specific tag, trigger, variable, or page.
D) One sentence I can send to a brand lead explaining what this data
can and cannot be used for right now.
Format for a mixed audience. Three sentence executive summary first,
then detail. No generic advice about "implementing best practices."
Name the tag, the parameter, the page.
Reading the results
Section 4 is the one to read first. Privacy exposure is what turns this from an analytics exercise into something the rest of the organization can act on, because it produces findings in a form a privacy team recognizes: a named exposure, the regulation it touches, and the fix. Note the escalation instruction inside it. Some findings — a member ID sitting in a page path, a pixel firing before consent — are not for the analytics team to quietly clean up. Route those.
Section 1 is the uncomfortable one. Asking whether the implementation can answer the three decisions it exists to serve is a different question from whether tags are firing. "Not measurable today" on a decision someone is already making is the most useful sentence the audit produces.
Make it quote evidence. Same caution as the answer-engine site audit: a reviewer that paraphrases instead of quoting will happily hand you a passing grade. The prompt demands a quoted tag, trigger, or parameter per rating. Hold it to that, and re-run the section if it goes vague.
It only sees what you paste. This is a review of configuration, not a crawl. A container export plus the current stakeholder report is usually enough to get the six ratings; less than that and the honest answer is a lot of "name what you would check."
Output D — the single sentence explaining what the data can and cannot be used for right now — is the part that travels. Most measurement conversations stall because nobody will say plainly which numbers are safe to act on. That sentence says it.
If the audit comes back saying the instrumentation itself is the problem rather than the reporting, that's the rebuild I open-sourced as ard-to-analytics — requirements, container, QA plan, and GA4 checklist generated from one spec, so the drift doesn't quietly return six months later.