Product Analytics: The Event Model You Commit To Before the Dashboard

Your dashboard is only as honest as the event names underneath it. Somewhere in your product is an event called clicked_button_2. It fires thousands of times a day, it feeds a chart somebody opens once a quarter, and nobody can tell you what the button was. That is not a data quality problem. It is a naming decision nobody made, compounding since the first sprint. When the chart gets challenged in a planning meeting, the argument will be about the dashboard. The answer will be sitting in a string that cannot be changed.

Product analytics is the practice of recording named actions inside your product and turning them into numbers you can act on. Take that as settled and look one layer down. Under every definition sits an event model: the names your team agreed to fire, the properties attached to each one, and the reason each one exists. Build it deliberately and the tools on top become interchangeable. Skip it and every tool you install is an expensive way to count things you cannot explain.

The Tool Is a Renter. The Schema Is the Asset.

Look this term up and you get a definition, a benefits list and a shopping section. Every page I could read follows that shape, and it leaves out the only part that outlives your current stack. Two of those results also sell the opposite idea, which Contentsquare states in one sentence.

Contentsquare's Smart Capture records every user interaction automatically from day one, no tagging plans or engineering setup required.

That solves a real pain, and automatic capture catches the action your plan forgot. The trouble is that it defers the naming decision rather than removing it. The interaction still arrives with a name, and that name becomes the thing every chart and warehouse model reads. With a plan you argue once, in writing. Without one you argue it every time somebody builds an analysis. One of the readable results describes implementation as integrating a tracking tool and stops there. The position on offer is that naming is a chore somebody else's software will handle.

Here is what decides whether that matters. A vendor relationship ends. Contracts consolidate, a cheaper option appears, and you move. The dashboard rebuilds in a week. What stays put is the vocabulary your product emits, and that is not my opinion. It is three vendors' own documentation.

Amplitude states it without hedging: "After you instrument an event, you can never change the name of that event type in the raw data." You can change the display name in the interface, and Amplitude is explicit that doing so "doesn't change the raw data". The label your team sees and the string your warehouse receives are two different things.

Mixpanel documents the same boundary: "After you ingest raw data into a project, you cannot rename it." Display names are rendered on the front end and, in Mixpanel's words, do not modify "the underlying data in the project's data store".

GA4 reaches the same consequence by a different mechanism. It lets you modify an existing event, a transform applied as data is collected rather than a repair applied to data already stored. The documentation is direct: "Modified and new events do not apply to historical data." New name forward, old name behind.

Three vendors, two mechanisms, one outcome. Whatever you buy, the raw event name is a contract you sign now. The schema is the set of names everything else reads from.

I will not quote you a migration number, because I could not find an honest one. What I can give you is the arithmetic, run with your own event count. A rename arrives with three bills, all paid in engineering time.

The duplicate series. Rename and accept the break is the first documented strategy, and it produces what the name suggests. Avo's guidance states the consequence: "queries spanning old and new event names must include both". Every funnel and dashboard reading the old name carries an extra filter, and anyone who forgets it gets a wrong number that looks right.

The destination drift. The alternative is to rename at the source and map old to new in each destination. That keeps history continuous and moves the risk somewhere less visible. Avo names both costs: "labor-intensive if multiple destinations exist", and "forgetting a destination can lead to discrepancies in your data". Your warehouse, your CDP, your dashboards, the saved query an analyst built two years ago. Each is a place a mapping gets missed.

The tail of old builds. "Old builds (e.g., outdated app versions) may continue sending events with the original names indefinitely." You cannot force an upgrade on a phone in a drawer, so the old name keeps arriving long after the migration is declared finished.

The third documented strategy runs both events side by side and retires one later. Avo puts removal at roughly 6 to 12 months, one team's practice estimate rather than a measured distribution. Six months of dual writes is six months of every analysis knowing which series it reads.

None of those bills arrives from the vendor you are leaving. Your own engineers pay, and the amount is fixed long before the migration starts. Everything here stops at the event; what people build on top of a clean series, including the prediction layer, belongs to predictive marketing analytics.

Naming Events So They Survive

A convention is not a matter of taste, and it is not a standard handed down by anybody. It is a set of decisions your team makes once and writes down. Here is the version I would defend.

Tense is the decision people skip and then argue about for a year. Past simple means the name describes a fact that already happened: report_created is a record, while create_report reads like a command sitting in a queue. A catalogue with two tenses returns half its instances for a single concept.

Then comes our working rule rather than anybody's published standard: an object, an action, and at least one property that makes the action measurable. The third is the one teams forget, and it decides whether you have a metric or a counter. checkout_completed tells you how many checkouts completed. Add value, currency, payment method and step index and the same event answers which payment method struggles, at which step, and what the abandoned basket was worth.

```json
{
"event": "checkout_completed",
"occurred_at": "2026-10-31T18:04:00Z",
"properties": {
"order_id": "order_placeholder_0001",
"value": 0,
"currency": "USD",
"payment_method": "card",
"step_index": 4
}
}
```

Read the first line again. No order number, no email address, no screen position. Everything that varies lives in the properties and the name stays a fixed string, the only thing a downstream system can join on. A name built from a variable or a user ID explodes your event count. One built from personal data moves something sensitive into a weaker system. One built from a screen position stops being true at the next redesign.

One limit is hard. GA4 caps event names at 40 characters, so a long prefix runs out of room exactly when the name needs to be most specific.

The Five Questions a Product Analytics Tracking Plan Must Answer

A tracking plan is usually a spreadsheet with an event column, an owner column, and no questions in it. Amplitude's documentation is more useful: a tracking plan "defines every event and property you collect, why you collect each one, and which source emits it". Start from five questions and work backwards to events.

1. Activation. What is the first action that proves a new user got the value? The common definition is the share of new signups who reach a defined value event, which makes activation a choice of event before it is a number. Name it, say first_report_exported, and time to value is the gap between signup and that event.
2. Adoption depth. Which steps of your core workflow should people reach, and what is each step called? This needs one event per step rather than one per screen. report_created, report_shared, report_scheduled describes a journey somebody can complete, while a screen view describes where they were standing.
3. Feature abandonment. What is the last event before somebody stops? Abandonment rarely announces itself, so you infer it from a gap between an entry event and a repeated one. dashboard_created with no dashboard_viewed in the following fortnight is a definition you can compute, and it names both events it needs.
4. Expansion trigger. Which event precedes a seat or plan change? invite_sent, seat_limit_reached, or a workspace_created event fired by a second person. Pick the one your product actually fires and expansion stops being a sales conversation you cannot time.
5. Churn precursor. Which event did they stop doing? Absence is only a signal when the event was named in advance and reliably fired. Name the one that should recur, say report_viewed, then measure the gap against what your best cohorts do.

Look at the five answers together. Every one is a ratio whose numerator and denominator are event names. Change a name and the metric does not get slightly worse. It splits into two series and takes its history with it.

The plan also needs one named owner, and the register that keeps such things from going stale belongs to marketing operations, not to this page.

When to Fix the Schema and When to Live With It

Every team reaches a point where the event names are wrong in a way that matters. The honest first answer is that fixing them is sometimes the worse option. This is not about tidiness, it is a weighing of two costs.

The cost of living with a bad name is bounded by how many decisions it reaches. One team, one dashboard, one quarter: small. Every team, every analysis, every new hire who has to be told what the name really means: it compounds without an invoice. The cost of fixing it is the bill above, plus the political cost of asking people to change how they work. The second is usually larger.

One thing is worth separating, because the two bills sound alike. There is a real cost to keeping a metric nobody acts on, and marketing KPIs already prices it. This is a different bill: not what an unused metric costs to maintain, but what changing a definition costs after months of data were recorded against it. The first you pay monthly, quietly. The second you pay in one lump, to engineers, with a migration attached.

If you want a single trigger, use this rather than a rule of thumb about maturity. Fix the schema when a number you are about to decide with needs a sentence of explanation to be correct. The moment a chart requires somebody to say that it only counts the old flow, the name has stopped doing the job a name is for.

Live with it when the name still describes what the event does, when one dashboard and one team carry the inconsistency, and when the surface emitting the event disappears next quarter anyway. Fixing a name attached to a feature you are retiring costs the same three bills and buys nothing.

Whatever you decide, write the decision down with a date. The next person to hit the same question deserves an answer rather than a reopened argument.

Conclusion

The commitment in product analytics is not the tool, and it is not the dashboard, which will be rebuilt twice before it is retired. It is the list of names your product fires, the only part of the stack you still control after the contract is signed.

You already know the bad names in your product. You could probably list five without opening a spreadsheet. Which are you willing to live with for another year, and which one is worth paying the bill to fix?