Get your Measurement Strategy tracking to 95%+ accuracy guaranteed in writing.
You're about to spend real money re-instrumenting a site, and the scope is a list of events someone assembled from a blog post and three old vendor proposals. We do the deciding first: what the business conversion is, which system holds the truth, the handful of events that budget decisions genuinely depend on, and the dozens you should stop paying to maintain. Then you go buy the build — from us or from anyone else.
Free30 minutesNo obligation
Measurement Strategy · what breaks
Why rebuilds get scoped wrong — Measurement Strategy
- 01
The tracked conversion isn't the business conversion
A B2B team optimizes toward demo requests while sales only counts accepted opportunities. Everything downstream is technically flawless and commercially useless, and it takes two quarters and a lot of spend to notice.
- 02
Nobody has named the source of truth
When GA4, the ad platforms and the CRM disagree, there's no agreed tiebreaker. The meeting turns into a debate about which tool is more trustworthy instead of a decision about where the money goes next month.
- 03
The spec is a pile of events, not a hierarchy
Scroll depth, video quartiles, every button click. Each one is free to add and permanent to maintain. Six months on, nobody can point to a single decision that any of them changed.
- 04
Scope gets set by whoever is quoting the work
Without your own specification, you're comparing proposals that describe four different projects. The cheapest one usually isn't more efficient — it's just the one that scoped the least.
Measurement Strategy · the fix
What you have before a single tag gets built — Measurement Strategy
One sentence everyone in the room agrees on
The business conversion written down plainly — 'a booked appointment that was attended', 'a trial that became a paid subscription' — with the system that records it named right next to it.
A short, ranked list of money events
Usually four to six events that budget decisions actually turn on, ranked by consequence, with everything else reclassified as diagnostic, deferred, or retired outright.
A build spec that isn't tied to us
Event names, parameters, types, example payloads and trigger conditions, written so your own developers, our team, or a third party would each implement it identically.
Quotes you can genuinely compare
Scope, sequence and priority are set by you before anyone bids, so implementation proposals become competing prices on the same project instead of four unrelated documents.
Measurement Strategy · architecture
The decision hierarchy we build before anything is tagged — Measurement Strategy
No container, no tags, no code. What this engagement builds is the structure that decides which events are worth paying to maintain at all.
- 1
The conversion, in one sentence
The business conversion written plainly — 'a trial that became paid', 'an appointment that was attended' — with the system that records it named beside it.
- 2
The source of truth, named down to the field
Shopify orders, the Stripe ledger or closed-won in the CRM, plus the exact field, timezone and currency that define one counted conversion in it.
- 3
A KPI tree built downward from revenue
Revenue decomposed into inputs somebody can actually move, so each proposed event has to justify itself against a decision a named person makes.
- 4
Money events ranked, the rest demoted
Usually four to six events carry budget decisions; everything else is reclassified as diagnostic, deferred, or retired outright.
- 5
A sequenced backlog and a do-not-build list
Money events ship first and get verified against the source of truth before the diagnostic layer is allowed to start consuming developer time.
Measurement Strategy · events
What gets measured, and which system holds the truth
This engagement produces a measurement inventory rather than an implementation spec, so the columns are provenance and purpose.
| What we measure | Why it earns its place | Where the truth lives | Decision it drives |
|---|---|---|---|
| The conversion itself | It's the number the business is actually run on | Store orders, billing ledger or CRM closed-won | Whether a channel gets more budget next month |
| Qualified vs raw lead | Form fills and accepted opportunities are different populations | CRM stage history | Which event gets sent back to the platforms to optimize on |
| Revenue per conversion | Averages hide a plan or product mix that should bid differently | Order or invoice line items | Whether values are sent flat or weighted |
| Time from click to conversion | It determines which windows and import limits you live inside | Order timestamp against first-touch timestamp | Window policy, and whether offline import is required |
| New vs returning buyer | Acquisition and repeat have to be optimized separately | Customer record in the store or CRM | Whether repeat revenue is allowed into acquisition reporting |
| Refund and cancellation rate | A conversion that reverses shouldn't stay on the books | Store refunds or billing credit notes | Whether adjustments are built in phase one or deferred |
| Consent-granted share | It caps how much truth any browser-only signal can carry | CMP logs, split by region | Whether server-side delivery earns a place in phase one |
| Events nobody queries | Scroll depth, video quartiles and per-button clicks cost maintenance forever | GA4 report usage and the existing tag inventory | What goes on the do-not-build list |
Measurement Strategy · prove
How we test the spec before anyone starts building — Measurement Strategy
A specification is worth what it survives. We stress it against a real order and a real developer before it goes out to quote.
Source of truth
One real order or closed-won deal, traced end to end in the system of record
- Trace one real order from first touch to recorded revenue and check the spec would have captured every step of it.
- Hand the event dictionary to a developer who wasn't in the sessions and confirm they'd implement it identically.
- Test each proposed event against a named decision and a named owner; if neither exists, it goes on the do-not-build list.
- Confirm the source-of-truth field, timezone and currency reconcile to what finance already reports for the same period.
- Check every money event against the attribution windows and offline-import limits it will have to live inside.
- Have the budget owner read the conversion sentence aloud and agree to it in writing before scope is frozen.
Measurement Strategy · free audit
What we check in the free audit
- The tracked conversion isn't the business conversion
- Nobody has named the source of truth
- The spec is a pile of events, not a hierarchy
- Scope gets set by whoever is quoting the work
Checked against
One real order or closed-won deal, traced end to end in the system of record
Free30 minutesNo obligation
Measurement Strategy · when not to buy
When you should skip strategy and go straight to build
This is the thinking half, and not every situation needs to buy it.
- One product, one checkout, one paid channel, and a written spec your team already follows. Go straight to implementation.
- You're pre-revenue. Measure the single money event and ignore the rest until a budget decision depends on more than that.
- Your setup is live and you suspect it's leaking. Run an audit first — strategy decides what should exist, an audit finds what broke.
- Leadership already agrees in writing on the conversion and the source of truth. The main output is yours already; buy the build.
Measurement Strategy · what we deliver
What a strategy engagement leaves behind
Source-of-truth statement
The system whose numbers settle disputes — Shopify orders, the Stripe ledger, closed-won in the CRM — plus the exact fields, timezone and currency that define a counted conversion in it.
KPI tree from revenue down
Revenue decomposed into the inputs you can actually move, so every proposed event has to justify itself against a decision a named person makes on a known cadence.
Event dictionary
Every money and diagnostic event with its name, parameters, data types, required versus optional fields, example payload, trigger condition and destination platforms.
dataLayer specification
The exact pushes your developers implement, versioned, with naming and casing rules written down so events added a year from now don't drift into a second convention.
The do-not-build list
Events, GA4 goals and legacy pixels from previous agencies that we recommend retiring, each with a reason, so the rebuild subtracts maintenance instead of only adding it.
Sequenced implementation backlog
The work split into phases with dependencies and rough effort, ordered so money events ship first and the diagnostic layer waits until they're verified against the source of truth.
Written guarantee
95%+ tracking accuracy
Measured against One real order or closed-won deal, traced end to end in the system of record. Miss it and we keep working at no cost.
FAQ
Measurement Strategy questions, answered
Yes, and it's written to make that easy — no proprietary formats, no dependencies on our tooling. We'll quote the build if you want us to do it, but the whole value of deciding scope first disappears if the document only works for the people who wrote it.
An audit inspects what exists and tells you what's broken. Strategy decides what ought to exist and what should be deleted. They're often run together — audit first if you have a live setup you suspect is leaking, strategy first if you're replatforming or the business model has changed since the tags were written.
Usually it's a reduction. Most mature setups have a handful of events doing real work buried under dozens nobody queries, plus two or three pixels from agencies that left. The output is often 'keep these six, rename these four, retire the rest' — which is faster and cheaper than the rebuild you were about to buy.
Whoever controls the budget, whoever owns the CRM or billing system, and one engineer who'll implement the spec. If the budget owner skips it, the definitions won't survive contact with the first meeting where someone prefers a different number.
No. This is deliberately the thinking half. Your developers implement the dataLayer spec, or we do it as a separate build with its own scope and price. Keeping them separate means you can walk away after the strategy work without having paid for a half-finished implementation.
That disagreement is the finding, and it's usually why the tracking is a mess. The engagement forces it into one written sentence with a named owner. Sometimes the honest answer is two metrics with two clearly separate jobs — that's fine, as long as it's decided rather than left ambiguous.
If you sell one product through one checkout on one paid channel, and your team already follows a written spec, skip this and go straight to implementation. Same if you're pre-revenue — measure the one money event and ignore everything else until there's a budget decision that depends on more.
More on Measurement Strategy
- GuideHow Accurate Is Your Conversion Tracking? Here's How to Actually Measure It
- Measurement strategyDecide which number answers which question, once
- Attribution ConsultingFour systems report four different sales numbers. Only one of them should be run…
- GTM consultingA tag manager container someone can actually maintain
Free · 30 min
Decide the scope before you pay for the build
WhatsAppFree30 minutesNo obligation
