The Event Tracking Plan You Write Before Any Code

Most event tracking in Indian ecommerce is retrofitted. A founder asks why repeat purchase looks flat. Somebody realises the answer is not in the data. An engineer bolts on an event that afternoon. Repeat that forty times across two years and you have a schema nobody designed, named by whoever happened to be free that week.

That is the real failure. Not a broken tag, not a missing script. A missing design step.

The tracking plan is the artefact that restores it. It is a document, written before anyone touches code, owned by people who understand the business rather than the codebase. It is unglamorous to produce and it is the highest leverage hour in the entire measurement stack.

Retrofitted tracking is wrong by construction

When you add events reactively, each one answers exactly one question that was urgent on one day. The event is shaped by that question. It carries the parameters that question needed and nothing else. It is named in the vocabulary of the person who asked.

None of that composes. Two events added six months apart cannot be joined, because they use different identifiers for the same product, different casing, different notions of when a purchase counts. You end up with a data set that can answer any single historical question and no new one.

Worse, retrofitting makes the past unrecoverable. You cannot go back and collect a parameter you did not think to send. Every month of missing detail is a month you will never analyse properly. This is the argument for doing the design work first, and it is a stronger argument than anything about engineering neatness.

Start from the business questions, not from the screens

The instinct is to walk the app or the site and instrument every screen. Resist it. Screen inventories produce hundreds of events, most of which nobody will ever query, and they still miss the ones you need.

Work the other way. Write down the ten to fifteen questions the business genuinely asks and re-asks. Which acquisition sources produce buyers who come back. Where in checkout do people stop. Whether a particular merchandising change moved add to cart. What a repeat customer does differently on their second visit. Whether the app and the web experience differ for the same cohort.

Then ask, for each question, what would have to be recorded for the answer to exist. That backwards pass usually collapses to a surprisingly small set. A well built consumer commerce plan often needs twenty to thirty events, not two hundred. Fewer events, each carrying richer parameters, beats a sprawl of thin ones every time.

Anything that does not trace back to a stated question does not go in the first version. Add it later when a question demands it, through the same process.

Naming that survives the person who invented it

Naming is not cosmetic. It is the difference between a data set a new analyst can read on day one and one that requires a tribal elder.

Pick one convention and enforce it mechanically. Lowercase, underscores, one casing rule, no spaces. Use an object then action structure, so events sort into families: cart_item_added, cart_item_removed, checkout_started, checkout_completed. Past tense for things that happened. No abbreviations that a new joiner would have to ask about.

Ban product and campaign names from event names. The event is checkout_started, not diwali_checkout_started. Campaign context belongs in parameters, where it can be filtered, not in the name, where it fragments your data forever.

Write the convention down, with three examples of good names and three of rejected ones. The rejected ones do more teaching than the accepted ones.

Parameters are the plan

The event name says something happened. The parameters are what make it analysable. Most tracking plans die here, because parameters get treated as optional extras rather than as the substance.

For each event, specify the parameters, the data type, whether it is required or optional, the allowed values where the set is closed, and an example. Purchase events need order identifier, value, currency, item list with product identifiers, quantity, price, and category. Product events need the same identifier scheme used by your catalogue and your order system, not a display name.

Two rules save more analysis than everything else in the plan. First, the product identifier must be the same string across events, systems and platforms. If the site sends one SKU format and the order system stores another, every product level question becomes a joining exercise. Second, currency and value must be explicit on every monetary event, always in the same unit, decided once. Ambiguity here quietly corrupts revenue reporting for months.

Also specify user and session identity: what identifies a logged in user, what identifies an anonymous one, and what happens at the moment they log in. That single transition is where most identity stitching goes wrong.

The document that keeps both sides honest

The plan is a contract between marketing and engineering. Marketing does not get to ask for data after the fact and act surprised it is missing. Engineering does not get to rename or drop a field without telling anyone.

Keep it in one place, versioned, with an owner. Every row should carry a status: specified, implemented, verified in production, deprecated. Verified means somebody looked at real payloads from a real device and confirmed they match the spec, not that a ticket was closed.

Add a change process. New events and parameter changes go through the same review that created the plan. Deprecated events stay listed with a date, because someone will find old data and need to know why it stopped.

Tie it to release. If a feature ships without its events implemented and verified, the feature is not shipped. That is a product decision, not an engineering one, which is exactly the point.

Why this is design work

A tracking plan looks technical. It is not. Every meaningful decision inside it is a business decision: which questions matter, what counts as a purchase, what a product is, when a session ends, which user is the same user across a phone and a laptop. Engineering can implement any answer you give. It cannot give you the answer.

That is why the plan should be drafted by whoever owns the questions and reviewed by whoever owns the code, and never the other way round. Hand the exercise to engineering and you get a faithful description of your software. You want a faithful description of your business.

Spend the week. Write the plan. Then write the code.