Best practices8 min read
Planning a tracking plan
Start from the question you want answered, not from the code you're about to ship. Work backwards from the question to the events that answer it.
Start from the question
Before naming a single event, write down the decisions you're trying to inform: Are people finishing signup? Where do trial users stall? Which channel brings buyers, not just visitors? Each question implies a small number of events and, usually, one funnel. Events that don't trace back to a question are noise you'll never look at again, and they crowd out the ones you would have.
Pageviews and the built-in engagement events already answer a lot of this for free: which pages people land on, where they go next, how far they scroll, how long they stay, and which links take them off-site. A tracking plan is really a short list of the handful of *product-specific* moments none of that can see: a plan chosen, a trial started, a report exported.
Worked example: SaaS signup flow
| Question | Event | Notes |
|---|---|---|
| Did they reach the pricing page? | pageview /pricing | Already tracked, no code needed |
| Did they start signing up? | signup_started | Fire on form focus or step 1 submit |
| Did they finish? | signup_completed | Star this as a conversion; it's the funnel's last step |
| Did they actually use the product? | project_created | The real activation moment, not just an account existing |
That's a 4-step funnel: pricing → signup started → signup completed → project created. Mark signup_completed as a conversion from the Events page so it's available everywhere a conversion rate is shown, not just inside this one funnel. See funnels.
Worked example: ecommerce checkout
| Question | Event | Notes |
|---|---|---|
| Did they look at a product? | pageview /products/:id | Already tracked |
| Did they add to cart? | added_to_cart | Property: product_id or category, not both if you're near the 8-key budget |
| Did they start checkout? | checkout_started | |
| Did they pay? | mrkr.revenue(amount, { order_id }) | Ties directly into the revenue rollups and ARPV: see reference/metrics |
Don't track everything
Every event gets 8 property slots. Spend them on what changes a decision (plan, source, item category), not on what's merely available. A payload with 20 fields doesn't get you 20 dimensions; it gets you 8, chosen by sorting keys alphabetically and dropping the rest, which is rarely the 8 you meant.
Resist instrumenting things the tracker already covers (outbound links, file downloads, scroll depth) just because you can see the code. Hand-instrumenting a link that already emits outbound produces a near-duplicate event under a different name, not new information, and every "how many clicks" number you read afterwards is doubled: see the double-counting section of accuracy. Start with the smallest plan that answers your actual questions, ship it, and add events when a real question comes up that the current ones can't answer.
Custom events are free: only pageviews count toward your plan's quota. Keep a tracking plan small because a large one is unreadable and unmaintained, not because it costs money. See what counts toward your quota.
For the mechanics of sending an event, see custom events.