Your First Ninety Days of Analytics

A.Why 'track everything' fails specifically

The instinct on day one is to capture as much as possible, on the reasoning that you cannot analyse what you did not record. That reasoning is correct and the conclusion does not follow, because the binding constraint is not what was captured. It is whether any two events can be compared.

An implementation with four hundred events has four hundred naming decisions made by several people over several months under deadline. Some are named after the page, some after the button, some after the outcome, and no two funnels can be built from them without a translation layer nobody has time to write.

A twelve-event schema where every name describes something a person did will answer more questions than a four-hundred-event one, and it will still be answering them in three years.

B.Write the ten questions down, literally

Not a strategy document. Ten sentences, each one a question somebody will ask out loud in a meeting within the next year.

Which channel produces customers who are still here in six months. Where does onboarding lose people. Which feature predicts renewal. What is a trial worth. Do the people who read our content buy differently from the ones who do not.

Then work backwards to the minimum events and properties that answer them. The list will be short, and the shortness is the deliverable rather than a compromise.

A.Days 1 to 14: identity, and exactly one conversion

Nothing else matters until you can tell that the person reading a post on Tuesday and the person paying on Friday are the same human. Get the snippet in, and call identify at every point somebody hands you a stable identifier: signup, login, newsletter form, email click, support conversation.

Most implementations identify once, at signup, and lose the entire pre-purchase journey. Every missed identify call is an anonymous fragment that never joins the person it belongs to. See people, events and properties.

Then define one conversion. Only one. The event that most directly represents money committing to change hands. Resist the second one for now, per which events deserve to be conversions.

B.Days 15 to 45: the funnel between the two, and nothing outside it

Now add the steps between first touch and that conversion. For most businesses that is four to eight events, and the discipline is refusing everything that is not on the path.

Name them after what the person did rather than where they were. “Started checkout”, not “Viewed /checkout/step-2”. The second one breaks at the next redesign and takes your historical comparison with it.

Put the circumstances on the event as properties: which plan, which device, which source. Put the current state on the person. Getting that split wrong is the error that silently rewrites history when somebody upgrades.

C.Days 46 to 90: revenue on the person, then retention

Attach payments to the same person record that already carries the acquisition source. The moment that join exists, channel comparison stops being an analysis project and becomes a group-by, which is the whole argument in acquisition measured to lifetime value.

Then, and only then, build the first cohort view. It needs months of history to say anything, which is why it is last: built on day one it is an empty grid that trains everyone to ignore the report.

A.Why the rewrite is usually the wrong call

The instinct on inheriting a bad implementation is to tear it out. It is almost always wrong, because the rewrite takes a quarter, breaks every existing report during it, and arrives at a schema chosen by the same process that produced the last one.

The cheaper move: pick the ten questions, work out the minimum events that answer them, and check how many already exist under some name. Usually most of them do. What is missing is a short list, not a platform.

B.The audit that takes an afternoon

List every event by volume. The long tail below a few hundred occurrences is almost always dead: things instrumented for a launch that shipped, or a test that ended. Mark them.

Then find the duplicates. Two events firing at the same moment under different names is the single most common finding, and it is usually two teams instrumenting the same button. Our piece on duplicate events covers the diagnosis.

What remains is your real schema. Write it down, declare it canonical, and point new reporting at it. The rest can decay without being deleted.

C.What a self-configuring schema changes about all of this

The reason this goes wrong is structural rather than careless. The hardest decision in the project, what to call things and which properties matter, is scheduled first, before anyone knows which questions will be asked, and given to whoever is free.

Kissmetrics works out what kind of business you run from your site, and what is worth capturing for one. Once events are arriving it proposes the rest of the schema: every event, the properties each one carries, and the role each event plays, conversion included. You correct a draft rather than author one from nothing, and the draft already avoids the two errors above by construction, since it names events after actions and puts moments on events.

It does not remove the ten questions. Nothing does. An inferred schema will happily propose a sensible structure for a business whose actual question is unusual, and you will only notice when you try to ask it. Write the questions down first either way; the difference is whether you are checking a draft against them or building from zero.