Event Tracking Plan

Plan One Question End to End

An event plan is complete when a product fact can travel from the place it happens to a decision the founder must make—and when you have proved that the journey works. A list of event names is only the middle of that plan.

Start with the current metrics tree or product hypothesis. Choose one question whose answer could change the next build, customer conversation, or market choice. For a product that turns advertising exports into weekly client digests, the question might be:

Among small agencies that attempted an export this week, which delivered a digest to a client, which stopped before delivery, and which succeeded only because the founder intervened?

This question supplies the eligible accounts, observation window, strongest defensible value signal, broken branches, and operational burden. If those terms are missing, tracking work will collect activity without resolving a decision.

Draw the Evidence Path

Trace the few product facts needed to answer the question:

qualified agency
  -> source export accepted
  -> digest generated
  -> digest reviewed
  -> delivery accepted
  -> next eligible weekly delivery accepted

broken branches
  -> source export rejected
  -> generation or delivery failed
  -> founder intervention recorded

Write what each step proves before deciding how to emit it. A generated digest proves that the system produced a candidate. It does not prove that an account manager trusted the result. Provider acceptance is stronger than a click on Send, but it still does not prove that the client read or valued the message.

The event taxonomy holds these meanings over time. The tracking plan names the code path, data destination, query, and verification work that will make the meanings observable in the current product.

Assign an Authoritative Source

For every fact on the path, identify the component that actually knows it happened. Record an attempt in the browser only when an attempt is the fact you need. Record accepted imports, completed jobs, delivery outcomes, and billing state from the server, worker, provider callback, or reconciled product record that knows the outcome.

For each event, settle these implementation details:

• stable event name and definition version;
• authoritative emitter and exact emission condition;
• account, actor, role, and value-carrying object identifiers;
• occurrence time and the rule for late delivery;
• bounded properties needed by the decision query;
• deduplication key for retries;
• test, founder, and internal-account marker;
• failure and founder-intervention event that explains a broken path;
• destinations that receive the event and the retention or deletion rule.

Do not copy customer content into analytics to avoid designing a property. Identifiers, statuses, duration bands, controlled reason categories, and safe correlation IDs usually preserve the useful distinction. Names, email addresses, files, digest bodies, prompts, exception text, and arbitrary free text create obligations that this decision rarely earns.

Write the Tracking Record

Copy this record for the plan. Complete the decision and trace before copying the event block; otherwise the event list will expand to fit whatever the interface exposes.

EVENT TRACKING PLAN

DECISION
Founder decision or conversation:
Eligible account or user population:
Observation window and natural cadence:
Activation fact:
Strongest defensible value fact:
Repeated-value eligibility and fact:
Failure or founder burden that could reverse the conclusion:
Decision if evidence is strong / weak / ambiguous:

EVIDENCE PATH
Expected sequence:
Broken branches:
Account, actor, role, and core-object identifiers:
Sensitive data deliberately excluded:
Analytics and storage destinations:
Deletion, opt-out, and retention handling:

EVENT IMPLEMENTATION — repeat only for necessary events
Event name and version:
Product fact and proof boundary:
Authoritative emitter:
Emit when:
Do not emit when:
Required identifiers and properties:
Deduplication or idempotency key:
Failure or intervention relationship:
Acceptance example:
Rejection example:
Implementation location and owner:

DECISION QUERY
Question in ordinary language:
Eligible denominator:
Sequence or grouping rule:
How absence will be interpreted:
Accounts or traces available for inspection:

RELEASE CHECK
Known success trace:
Known stopped or failed trace:
Retry and duplicate check:
Test-account exclusion check:
Dashboard or report reconciliation:
Definition annotation and rollout date:
First review date:
Event to retire if it proves unnecessary:

The line about absence deserves care. No event may mean that the customer stopped, that the emitter failed, that consent excluded the account, that the event arrived late, or that the account was not yet eligible. The plan must say which of those cases can be distinguished before a dashboard treats silence as behavior.

Carry One Event Through the Plan

For the agency workflow, digest_delivery_accepted could be emitted by the server when the delivery provider confirms acceptance. It carries the agency, acting user and role, digest version, delivery, client identifier, channel, and whether founder help was required. The provider delivery ID is the deduplication key.

An acceptance test sends a known digest through the provider sandbox, delivers the callback twice, and finds one event attached to the expected agency, digest, and delivery. A rejection test presses Send but makes the provider reject the delivery; no accepted event appears, while a bounded delivery failure does. Neither event contains the recipient address or digest body.

Now trace two complete accounts. One accepts an export, reviews a digest, delivers it, and returns at the next weekly opportunity. Another generates a digest but fails delivery because its sender lacks permission. The query must place the first account in repeated value and the second on the delivery-failed branch. If both merely appear as “active,” the path has lost the distinction that justified collecting it.

Release Evidence, Not Event Volume

Ship the smallest coherent path that can disagree with your current belief. Validate required properties at the emitter, exercise retries, exclude test accounts, and reconcile the event trace with the product records that produced it. Then inspect the first real accounts by name or stable identifier before trusting an aggregate.

Annotate the rollout date and any product change that alters the meaning of a step. Split or version an event when its proof boundary changes. Do not quietly repair a chart by redefining history.

The plan is ready when one successful trace and one stopped or failed trace survive from product record to decision query; founder help remains visible; and every collected property has a decision use worth its privacy and maintenance cost. The first review should end by choosing an action—and by removing any event that did not help choose it.