Planning a tracking plan
How to decide what to track before you write any code, with worked examples for a SaaS signup flow and an ecommerce checkout.
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 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
Resist instrumenting things the tracker already covers (outbound links, file downloads) 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.
For the mechanics of sending an event, see custom events.