Records the product emits when users do things, tapped a button, viewed a page, completed checkout. The raw material of all product data.
Why it exists
You cannot improve what you cannot see, and by default a product tells you almost nothing about how people actually use it, which leads to guessing at decisions. App events and instrumentation exist to record what users do as structured data, so questions about behavior can be answered with evidence instead of opinion.
How it actually works
Every meaningful action can fire an event: a small record like { event: "add_to_cart", product: "1042", user: "88231", time: ... }. Instrumentation is the work of deciding what to track and adding the code to emit it. Nothing shows up in your analytics that wasn't first emitted as an event.
Those events flow to analytics tools where they become funnels, dashboards, and experiment results. Data you never instrumented is data you simply don't have, which is why event planning matters before launch, not after.
Subtopics
A senior PM walks you through it
A junior PM, stuck
I asked the analyst for revenue by item ahead of the Friday promo review, and the answer came back that it cannot be computed because add_to_cart never sent a price. I own the tracking plan. I signed off on these exact events and I could not even tell whether the analyst was right.
The analyst is right, and checking took me two minutes; it will take you the same. When a customer taps something, the app writes that action down as a few lines of JSON and sends them off, and those lines are everything the analytics tool will ever know about the tap. I pulled the three events the store fired while one customer ordered a Kacchi at Friday lunch, exactly as they left the app. The hole is visible on screen; walk the steps and you will see it.
The three events fired during one Kacchi order, Friday 12:41
01The customer opens the Kacchi card
fires
1{
2 "event": "view_item",
3 "product_id": "p_1042",
4 "price": 649,
5 "user_id": "u_88231",
6 "ts": "2026-03-06T12:41:05Z"
7}
02The customer taps Add
fires
8{
9 "event": "add_to_cart",
10 "product_id": "p_1042",
11 "qty": 1,
12 "user_id": "u_88231",
13 "ts": "2026-03-06T12:41:09Z"
14}
03Checkout completes
fires
15{
16 "event": "checkout_completed",
17 "order_total": 649,
18 "user_id": "u_88231",
19 "ts": "2026-03-06T12:41:52Z"
20}
Click a step to see the lines it points at.
Mistakes I've seen
Signing off a tracking plan by event names alone. add_to_cart sounds complete; only the property list shows the money is missing, and the gap surfaces a quarter later when someone finally asks the revenue question.
Expecting a lookup table to rescue a missing property. The products table knows today's price, not the price on screen at the moment of the tap, and the first price change quietly corrupts every backfilled report.
Promising the analyst history once the fix ships. The new property starts recording the day it goes live; last quarter's add_to_cart rows stay incomplete forever.
Letting each event be designed by whoever happens to build that screen. One event captures price, its sibling does not, and the plan rots one inconsistent payload at a time until nobody trusts the numbers.
Filing the missing metric as a dashboard bug. The dashboard sits downstream of the payload, so the ticket belongs with the team that fires the event, and aiming it at the analytics tool costs a week of ping-pong.
Reply in the thread with: "Confirmed, add_to_cart sends product_id and qty but no price. I am adding a price property captured at the moment of the tap; it will count from the day it ships, so revenue by item starts then and history stays unavailable." You opened the real payload, verified the claim yourself, and scoped the fix without overpromising. That is what owning the tracking plan looks like.
Where a PM meets this
Owning the tracking plan is a core PM task: defining which events and properties get captured so you can answer tomorrow's questions.
"We can't measure that" usually means it wasn't instrumented; the fix is adding events and waiting for data to accumulate.
Hear it in a meeting
"We didn't fire an event on that step, so we're blind to where they drop."