Features
Part of Analytics tools: what beginners should know
Analytics tools examples compared: what the good ones share
Analytics tools examples worth copying: a tracking plan row, a comparison that ends in a decision, a report that survives one question, and a trial note.
An example is worth reading only if you can copy the shape of it. The four below carry no figures on purpose, because a number out of somebody else's account tells you nothing about yours. What does transfer is the structure: what got written down, what was actually compared, and what the decision turned on.
What to take away
- Copy the structure of an example. Never copy its numbers.
- A worked example ends in a decision and names the thing that would reverse it.
- A sample row or a template is more useful than a case study full of figures you cannot check.
Example one: a row from a tracking plan
The tracking plan is the document that stops one action from ending up with three names. One row per event, filled in before the event is built rather than after somebody notices the mess.
| Column | Sample entry | Why the column is there |
|---|---|---|
| Event name | checkout_started | Fixed, lowercase, agreed once. Renaming later breaks every historic comparison |
| Fires when | The user reaches the first step of the checkout form | A sentence anyone can test by hand in five minutes |
| Properties | Cart value, currency, item count, logged in or not | Decides which questions the event can answer a year from now |
| Not to be used for | Purchase intent in a client report | Blocks the slow drift from a technical event to a business claim |
| Owner | The named analyst on the account | Someone has to say no to a fifth name for the same click |
| Added on | The date it went live | Turns an odd looking trend into a change you can explain |
Fill this in for the ten events you report on most. Ignore the rest until they matter.
Example two: a comparison that ends in a decision
Two candidate tools, one week, one question. Connect the same source to both. Ask both the same thing: which channel brought the customers who were still active after ninety days.
The comparison people expect is the totals. The comparison worth writing is the definitions. Tool A counts a person by login where one exists and by device where it does not. Tool B counts by device throughout. That single difference explains most of the gap before anyone accuses either of being broken. The same argument recurs wherever two systems claim the same sale, which is a standing feature of partner programs. The rest of the write up is short: what each tool needed from you, what neither could do, and the price line that grows.
Then write the decision as one sentence, with its reversal attached. We picked the first tool because it exports event level data on a schedule and the second exports charts. If the second ships scheduled export, this is worth reopening. Decisions written that way stay honest when the person who made them has moved on, which is also the point of the wider tool comparison method.
Example three: a client report that survives one question
The question is always the same. Where did that number come from.
A report that survives it has four things on the page. The metric, in the client's own words, not the tool's label. The source, named. The model or rule that produced it, named too, so an attribution default is not passed off as a fact. And the date of the last tracking change on the account.
That is a header block, not a chapter. Everything else on the page can be charts. The reason it works is that it removes the two conversations that eat a review meeting: what do you mean by conversion, and why is this different from what the platform says.
Example four: a one page note after a trial
At the end of a trial, before anyone builds a spreadsheet, write five lines.
- The question we tested, in one sentence.
- What we connected, including the source we nearly skipped.
- What came back, and what came back wrong.
- What the tool could not do at all.
- The date, and the price line that grows if the account grows.
Five lines per candidate can be read side by side. A scoring matrix cannot, and nobody reopens it. Keep the notes with the rest of the measurement planning rather than in a personal folder.
What these examples deliberately leave out
No sizing, no benchmarks, no performance figures. Those depend on the account, the market, the season, and the setup, and borrowing them is how a plausible number ends up in a client deck with nothing behind it. The transferable part is the discipline: define the event, name the model, date the change, write the reversal condition. The same four moves work on the campaign workflow side, where the equivalent artifacts are a brief, an approval record and a payment.
Where an example turns on what a term means, settle the definition in writing with the client rather than accepting a vendor glossary. Most disputes that look like tool failures are data quality problems with a definition at the bottom of them.
Common questions
Why are there no real case studies with numbers?
Because they do not survive contact with a different account, and most published ones cannot be checked. A structure you can copy is more honest and more useful.
Can we hand the tracking plan row straight to a developer?
Almost. Add your naming convention and the platforms the event has to fire on. The fires when column should already be specific enough to test.
How many events should a plan cover?
Start with the ones that appear in a client report, plus the ones a client asks about. Adding every event you can collect produces a document nobody maintains.
What if the two tools in example two agree exactly?
Check that they are not reading the same source with the same rules, which happens more often than people expect. Agreement between two views of one dataset is not confirmation.
