A measurement checklist

Your revenue numbers disagree. Where do you start?

Choose one journey, one reporting period and one question. For example: how many customers made their first successful payment after signing up last week?

Work through the checks below before changing tracking or trusting a dashboard total. No email address needed.

Trace one customer journey

1. Define the number. Write down the event, date range, time zone, currency and exclusions. Distinguish attempted payments, successful payments, refunds and net revenue.
2. Choose the source record. Identify the billing or order records that establish whether the transaction happened. Keep a small set of test identifiers.
3. Walk the actual journey. Follow acquisition, signup, activation and payment. Record where each event originates and what consent or blocking changes its visibility.
4. Check identity. Follow the same customer across anonymous browsing, account creation and billing. Check that identifiers join correctly without merging different people.
5. Check delivery and duplicates. Look for missing events, retries and both browser and server events counting the same transaction.
6. Reconcile the sample. Compare each source transaction with its recorded event. Explain mismatches individually before extrapolating.
7. Repair and hand over. Record the change, acceptance checks, owner and remaining limitations. Repeat the journey after release.

A worked example: duplicate purchase events

Illustrative example, not a client result. Billing contains 100 successful first payments in the agreed period; analytics shows 112 purchase events.

Matching transaction IDs reveals 12 payments with two events each. The second event appears when the confirmation page is reloaded. The remaining 88 payments appear once.

Proposed repair: emit payment confirmation from the authoritative payment workflow, using the transaction ID for deduplication. Keep browsing events separate from confirmed financial transactions.

Acceptance checks: refreshing the page and replaying the payment notification must not increase the count. A failed payment must not count. A second legitimate payment must still count. Reconcile a fresh sample after release.

Handover: document the event definition, identifier, owner, replay behaviour and monitoring. This explains the sample discrepancy; it does not establish that every historical event is correct.

Want help tracing your own numbers?

Tell me which totals disagree, which tools are involved and what decision this is blocking. We can scope an audit and agreed repairs from there.

See the tracking QA tooling built for GrowthRunner