Insights · · By Cald
How to Build a Tracking Plan Your Developers Can Implement
A tracking plan tells your team what to collect, when to collect it, and how to prove it works. An event name alone is not enough: a developer also needs the trigger, source system, properties, identity rules, and expected result.
This guide builds a small plan for a B2B product: a visitor submits an enquiry, sales qualifies the lead, and the customer starts a paid subscription. The examples are illustrative; adapt the definitions to your own sales process.
Download the tracking-plan template → Copy the Markdown template into your team's documentation and complete one event specification at a time.
1. Start with a decision you need to make
Write down the question before listing events. For this example: Which acquisition channels bring leads that become paying customers? That question needs downstream outcomes, not just page views and button clicks.
Choose a small first release. Here, three events cover the journey. Record who uses each event and what decision it supports. If nobody can explain its purpose, leave it out of the first release.
| Event | Trigger and source | Purpose |
|---|---|---|
| Lead Submitted | The backend successfully saves an accepted enquiry. | Measure accepted enquiries by acquisition source. |
| Lead Qualified | The CRM records the first transition into the agreed qualified stage. | Compare qualified outcomes across channels. |
| Subscription Started | The billing backend confirms the first successful payment for a subscription. | Connect acquisition with paying customers. |
2. Define the exact trigger and its exclusions
“Track the form” leaves too much room for interpretation. A click can happen before validation, a request can fail, and a confirmation page can reload. For Lead Submitted, our chosen trigger is successful persistence of an accepted enquiry in the backend.
Specify the exclusions too: validation failures, rejected spam, test submissions, and retries of the same accepted submission should not create another business event. Decide whether a later, separate enquiry from the same person is a new event; in this example, it is.
For Lead Qualified, define the actual CRM stage and business rule. Decide whether a lead that leaves and re-enters the stage counts again. Our example counts only the first qualification per lead. A CRM administrator should confirm the rule before anyone writes the integration.
3. Use stable names and a property dictionary
Use a consistent naming pattern, such as an object followed by a completed action. Keep changing values in properties: Lead Submitted with form_id is easier to maintain than a different event name for every form. Segment recommends standardizing event names across your sources; see its event naming guidance.
For every property, document its meaning, type, required status, example, and source. The following are proposed business fields, not a destination-ready API payload.
| Field | Contract | Example |
|---|---|---|
| event_id | Required string. Stable identifier for this occurrence, reused on retries. | evt_demo_001 |
| occurred_at | Required timestamp in UTC. Time the enquiry was accepted, not the retry time. | 2026-10-23T14:30:00Z |
| lead_id | Required string. Internal lead record identifier. | lead_demo_001 |
| form_id | Required string from the maintained form inventory. | demo_request |
| utm_source | Optional string. Captured acquisition source when available and permitted; omit when unknown. | newsletter |
Define how missing values work. Do not replace an unknown campaign source with a guessed value. Keep arbitrary form text, credentials, and unnecessary personal data out of the event contract.
4. Write down identity and retry rules
A lead identifier and a user identifier represent different records. Document how the website's anonymous identifier, CRM lead, product account, and billing customer connect. Identify the system that owns the relationship and what happens when no reliable match exists. Do not assume an anonymous visitor already has a registered user ID.
For retries, keep the original occurrence time and stable event identifier. Specify where duplicate suppression happens and for how long. A stable ID helps implement this rule, but it does not guarantee that every downstream tool will deduplicate automatically.
For Segment, translate the business contract into its message structure explicitly. Its Track specification separates the event name and properties from message-level fields. Record that mapping in the implementation ticket instead of sending the table above unchanged.
5. Map each destination separately
List which tools receive each event and why. An analytics tool may need all three outcomes; a CRM may already own qualification and only need the original enquiry. Sending the CRM its own event again can create an avoidable loop.
For each destination, record the receiving event or action, required fields, identity mapping, timestamp handling, consent conditions, and expected delivery delay. Check that destination's current documentation before implementation. An internal event does not automatically satisfy an ad platform's conversion requirements.
For our example, start with analytics reporting. Treat CRM delivery, lifecycle messaging, and ad-platform conversion uploads as separate mappings with separate acceptance checks. Document what to do when permission or required identifiers are absent rather than silently forwarding an incomplete record.
6. Turn each definition into a test
Run a test journey with synthetic records. Record the source record ID, event ID, timestamps, and evidence from every configured destination. “Visible in Segment” is one checkpoint; it does not prove the final system processed the expected fields.
- Accepted enquiry: one Lead Submitted event has the expected lead and form identifiers.
- Rejected enquiry: no Lead Submitted event appears.
- Retry: the same occurrence keeps its event ID and timestamp; the agreed duplicate handling is verified at each destination.
- Qualification: the first qualifying transition produces one event; re-entry follows the documented exclusion.
- Payment: a failed payment produces no Subscription Started event; a confirmed first payment does.
- Missing data: an absent optional source is handled as specified; a missing required field is surfaced for investigation.
- Restricted routing: a record that fails the agreed permission conditions is not delivered to that destination.
Schema validation can check field structure. It cannot establish whether your application emitted every event at the correct moment. Segment's Tracking Plan documentation describes required property validation and its limits. Combine those checks with source-to-destination tests.
7. Assign owners and keep a change log
Give every event a business owner, implementation owner, and person responsible for investigating delivery failures. Add a status such as proposed, implemented, validated, or retired. Only mark an event validated when its acceptance evidence is linked.
Before changing a trigger, field type, or meaning, identify the reports and campaigns that depend on it. Record the change date, migration approach, and approval. A renamed event can split a report's history; a changed qualification rule can alter the meaning of a conversion without changing its name.
Your tracking plan is ready when these questions have answers
- What business decision does each event support?
- What exact system action triggers it, and what does not?
- Which properties and identifiers are required, and who supplies them?
- How are retries, missing identities, and routing restrictions handled?
- What does each destination expect, and how will delivery be verified?
- Who owns implementation, acceptance, and maintenance?
Download the template and use the Lead Submitted example as your first completed specification. Agree on that event with marketing and engineering before expanding the inventory.