Software & TechnicalFree
Event Tracking Plan From Metric Tree
River crosses your metric tree against the event list in both directions, then ranks each event's day-one check by how long a break would go unseen.
River builds the metric tree from the decisions you named, down through drivers to the leaves that can actually be observed, then holds your event list against it and reads the join in both directions. Out comes a tracking plan giving every event the question it answers, and every question the event that answers it. Then a sheet with one row per event: trigger, properties, owner, the assertion that proves it, and the day that assertion first runs.
Page one has moved. The better templates now open with a decision inventory and ask you to justify each event by a question, which is the right instinct and catches the events that serve nothing. What none of them does is read the other direction. A column headed decision finds an event with no question. It cannot find a question with no event, and that is the expensive one, because a wasted event is visible in the diff and a dark branch is invisible until somebody asks.
Built for the analytics engineer writing the spec before a sprint, the product manager who wants the launch measurable rather than merely launched, and whoever gets asked in six months why the number cannot be produced. Run it before the tickets are written, and again whenever a new surface ships with no leaf of the tree attached to it. What the events later cannot answer is a request specification, and their definitions belong in a data dictionary.
The paper that named this asked the question in 2010
Google's Goals-Signals-Metrics paper set the order down sixteen years ago. A metric is unlikely to be useful in practice unless it explicitly relates to a goal, so goals come first, then signals, then metrics. Its signals step asks something almost nobody's template asks: are the relevant actions currently being logged, or could they be. That is the reverse reading. It also notes that failure is often easier to identify than success, which is exactly the half of the tree that goes dark when the plan is written from the interface.
The second thing the tree gives you is when a mistake stops being fixable. Amplitude ignores a repeated event with the same insert_id and device_id within the past 7 days, so a retry loop that double-fires is absorbed for a week and permanent after that. If the event feeds a monthly review, nobody looks for thirty days. The repair window closed twenty-three days before the first person opened the chart, and no amount of care afterwards recovers the month.
The property you cannot add later is identity. Mixpanel's own account of the mechanism is that an anonymous device identifier is only folded into the user when an identify call triggers an ID merge. Fire your funnel's first three steps before that call and they belong to somebody else, which is not a null you can see. The conversion rate simply comes out wrong, confidently, for as long as the funnel is on a dashboard.
How it works
Name the decisions
What will be decided differently, by whom, and how often somebody looks at the answer.
River builds the tree
Drivers down to observable leaves, with the dimension each decision has to cut by.
Cross it both ways
Dark leaves on one side, events serving nothing on the other, counted rather than argued.
Ship with the checks
Each surviving event carries its assertion and the date that assertion first runs.
What you get
- A metric tree from your decisions down to leaves that something can actually observe
- Both directions of the join: leaves with no event, and events serving no leaf
- Events that fire correctly and still cannot be sliced by the dimension the decision needs
- A day-one assertion per event, with its threshold and the count it reconciles against
- Exposure per event in days, which is how long a break would sit before anybody noticed
- The identity and join keys each funnel step needs, resolved before anything is built
Common questions
We already justify every event with a business question.
Then half of it is done and it is the half that catches waste. The other direction catches absence. Glentham's plan had a question against most events and still left six leaves of its own tree measured by nothing, five of them a failure or a non-event. A column cannot find what is not in the column.
Why would a failure be harder to instrument?
Because plans get written from the interface, and an interface has screens for the things that work. Nobody opens a page called gave up halfway. The leaves that go dark are export failures, queue waits, abandonment and anything that happens by not happening, which is where most of the churn signal lives.
Is a 90-day verification cadence not enough?
It removes about a third of the exposure and spends most of its effort in the wrong place. An event on a weekly dashboard validates itself in a week, so auditing it at ninety days is late and pointless at once. An event on an annual review is exposed for months either way. Sort by lag, not by importance.
Can we not just fix the data afterwards?
Some of it, and never the part that was never sent. Duplicates fall outside the suppression window after a week. A property nobody attached does not exist to attach. An anonymous session that was never stitched to an account cannot be stitched later. The fixable window is shorter than the interval before anybody looks.
How many events should a plan have?
As many as the tree has leaves needing observation, which is a count rather than a target. Glentham's tree needed events against seventeen leaves and the draft plan proposed thirty-eight, mostly interface noise. The output is usually smaller than the draft and covers strictly more of the tree.
What comes out of it?
A tracking plan document holding the tree, every event with the question it answers, and the leaves still dark with what would light them. Then a sheet per event: trigger, properties, identity keys, owner, assertion, threshold and the day it first runs. Wrong numbers already shipped are a data quality incident.
Who owns the plan after it ships?
One named person per event, recorded in the sheet, and the assertion is what makes that ownership mean something. An owner with no check is a name beside a guess. The models the events feed carry their own contract in pipeline documentation, and pushing a computed metric into a CRM afterward is a reverse ETL sync with its own overwrite policy to decide.
Event Tracking Plan From Metric Tree
Fill in the form and your workspace opens with the work already underway.