Tag governance standard operating procedure
Tracking breaks most often not because someone made a mistake but because nobody was responsible for noticing. A governance procedure fixes that with four unremarkable things: a short list of people who can publish, a review step before publishing, tracking verification on the release checklist, and monitoring that alerts a named person. None of it is technical, all of it is skipped, and it prevents more lost data than any amount of implementation work.
Free30 minutesNo obligation
Tag governance · what breaks
Where teams get this wrong — Tag governance
- 01
Everyone has publish rights
Then nobody is responsible and changes happen unreviewed.
- 02
Tracking absent from the release checklist
Which is why redesigns break it so reliably.
- 03
Monitoring alerts going to a shared inbox
Which nobody reads. Name a person.
Tag governance · the fix
What a correct implementation looks like — Tag governance
A short publish list
Named individuals, reviewed when people leave.
A review step before publishing
Someone other than the author looks at it.
Tracking on the release checklist
Verified before deploy, not discovered after.
Alerts to a named person
With an escalation path.
Tag governance · architecture
The procedure — Tag governance
Six elements. None of them technical, all of them routinely absent.
- 1
Access
Named accounts with least privilege. Publish rights to a small reviewed list.
- 2
Change review
Someone other than the author checks before publishing. Catches most simple mistakes.
- 3
Version annotation
Every container version described. Six months later this is the only record of why something changed.
- 4
Release checklist
Tracking verification as a specific step before deploy. This is the single highest-value item here.
- 5
Monitoring
Alerts on conversion volume anomalies and container errors, going to a named person.
- 6
Periodic review
Quarterly access review and a reconciliation. Cheap insurance against slow drift.
Tag governance · diagnose
Common mistakes and how to validate each — Tag governance
Ordered by how often we find them. Each one has a specific check rather than a general instruction to be careful.
- 01
Stale publish lists
Review who has rights. Former staff and former agencies show up regularly.
- 02
Unannotated versions
Open your container's version history. If the entries say nothing, that history is worthless.
- 03
Tracking not in the release checklist
Ask what happened to measurement at the last redesign. The answer usually makes the case.
- 04
Alerts to a shared inbox
Ask who is responsible for acting on one. If the answer is a team, it's nobody.
- 05
No periodic reconciliation
Ask when it was last run. If it was at handover, that's the finding.
Tag governance · prove
How to prove your implementation is right — Tag governance
Against your own records and a live payload, not against a preview screen.
Source of truth
your access lists, version history and release checklists
- Publish rights limited to a named, reviewed list.
- Container versions annotated with what changed and why.
- Tracking verification present as a step in the release checklist.
- Monitoring alerts confirmed reaching a named person.
- A periodic reconciliation with a recorded date.
- Checked on a live conversion, not in preview mode.
- Reconciled over a fully closed window, matched per record.
- Re-checked 30 days later.
Tag governance · free audit
What we check in the free audit
- Stale publish lists
- Unannotated versions
- Tracking not in the release checklist
- Alerts to a shared inbox
- No periodic reconciliation
Checked against
your access lists, version history and release checklists
Free30 minutesNo obligation
Tag governance · when not to buy
What this reference deliberately leaves out — Tag governance
Stated openly, because a reference that's silent about its own gaps is the dangerous kind.
- Organizational structure varies. This is a procedure shape rather than an org chart, and yours can differ.
- Change management tooling is a preference. What matters is that review happens, not which system records it.
- Ad account governance is adjacent and follows the same principles with different specifics.
- Vendor documentation is the authority, not this page. Where the two disagree, the vendor is right and we'd like to know so we can correct it.
- Parameter names and behaviour change. Anything here is accurate as we last verified it; verify against the current documentation before you rely on it for a build.
Tag governance · what we deliver
The checklist — Tag governance
Publish rights limited to named individuals
Reviewed quarterly and when anyone leaves.
Every change reviewed before publishing
By someone who didn't write it.
Container versions annotated
What changed and why, so history is readable.
Tracking verification in the release checklist
A specific step, not a general reminder.
Monitoring alerting a named person
With a documented escalation.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup against this reference, on a live conversion.
- Implementation checked against the spec
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, built to this specification.
- First-party server container on your own subdomain
- Events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, documented to this standard.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
Tag governance questions, answered
A short named list, reviewed quarterly and whenever someone leaves. Broad publish access means changes happen unreviewed and nobody is responsible.
Tracking verification in the release checklist. Most breaks we find date to a deploy where nobody checked.
A person, with a documented escalation. Alerts to a shared inbox are alerts nobody acts on.
Quarterly, and immediately when anyone leaves. Former agencies retaining publish access is more common than you'd expect.
Free · 30 min
Stop the next release breaking your tracking
WhatsAppFree30 minutesNo obligation
