Tracking setup checklist: from naming to a verified conversion

1. Define the business decision and event dictionary

Name the decision the data must improve. Then define campaign, source, medium, content, landing view, lead, checkout, purchase, refund, recurring revenue, and offline outcomes in plain language.

Assign one owner to each event definition and naming rule.

2. Draw the source-to-destination map

List every domain, redirect, link shortener, funnel step, checkout, CRM, affiliate network, ad platform, webhook, and analytics destination.

Mark where identifiers can be dropped, duplicated, transformed, or blocked. Include consent states, cross-domain transitions, and server-side handoffs because they can change which records survive the journey.

3. Run a traceable test conversion

Use a unique campaign value. Record the time and expected amount. Verify the click, session or visitor, goal, revenue, cost, downstream signal, and final report.

Repeat across devices or domains when those paths matter.

4. Prove the first decision before scaling

Use the result to pause, continue, reallocate, or investigate one campaign. Document what the tracker revealed that the old stack did not.

If no useful decision changed, fix the implementation or reconsider the subscription before expanding it.

Launch measurement with known test cases

Before live traffic arrives, define the campaign naming convention, required parameters, destination rules, conversion events, values, attribution window, time zone, and source-of-truth reports. Build a test sheet with several known clicks and conversions, including one duplicate, one refund or reversal if supported, and one path where tracking is expected to fail. The observed data should be explainable before the first optimization decision.

After launch, monitor for broken destinations, sudden drops, impossible conversion rates, missing costs, duplicate events, and time-zone drift. Schedule a short reconciliation against the ad platform and revenue record. Save the configuration and test evidence so future changes can be compared with the known working state instead of debugged from memory.

• Define naming, parameters, events, values, and attribution.
• Test success, duplicate, reversal, and failure cases.
• Set anomaly alerts with clear response owners.
• Save a known-good configuration and reconciliation report.