Event

The oldest way to tell how much a product is being used is to count totals. How many people showed up yesterday, how many signed up this month — those numbers appeared on a screen and that was the end of it. They refreshed every morning, and they were useless for deciding what to build next.

Teams kept hitting the same wall. Mia would ask what the people who upgraded from the free plan had done in the product before they upgraded, and nobody could answer. The signup count existed and the payment count existed, but nothing in between had been written down. Getting an answer meant calling users and asking them to remember.

An event turns that around. Instead of counting totals, it writes down each individual action as a single line at the moment it happens. You aren't producing numbers for questions decided in advance; you're stacking up material that can answer whatever question arrives later. Totals can always be rebuilt by counting those lines, but a total on its own can never be split back open.

One event line is made of three fields — who, when, and what — and it gets created in the user's browser or on a server and sent to an analytics tool, where the lines pile up.

1. Who — a user identifier (UID) pointing at the person who acted. Not a name or an email address but a unique number attached to the account, with a temporary value planted on the device standing in before login.
2. When — the moment the action happened, down to the second. The reason for that precision is ordering rather than daily totals: whether someone created a document and then shared it, or the reverse, can only be settled by this field.
3. What — the name given to the action, usually built as object plus verb, like document_shared. That name is the key that later counts the action, so the same behavior carries the same name no matter which screen it happened on.

On top of those three sits an event property, the extra information carried along with the line — whether a share was a copied link or an email invite, for example. Without properties you can see how many shares happened and nothing about which kinds happen more.

Names and properties are agreed on before anything gets instrumented. A tracking plan is the document that writes down in advance which actions get recorded under which names with which properties, and a naming convention is the rule that standardizes how those names are formed. Skip both and the same share turns into doc_shared on the web and shareDocument in the app, and the share count shows half the truth from either side.

There are two places a line can be sent from. Client-side tracking sends directly from the browser or app, which catches in-screen behavior like a cursor hovering over a button and moving on, but ad blockers stop some of it from ever arriving. Server-side tracking records on the server handling the request, which no blocker can interfere with, but it never sees anything that stays inside the screen. So anything involving money goes through the server, and anything that only happens on screen goes through the client.

Stacked-up events get read three ways: counted, split, and strung together in order.

1. Counting — how many lines share a name. Most metrics are built this way. If document_created fired 1,200 times yesterday, 1,200 documents were created, and counting distinct identifiers on those lines tells you how many people created them.
2. Splitting — comparing groups of lines by property or by person. Break share events down by method and you get something like 80 percent copied links and 20 percent email invites. Split by a user property such as plan — a value that sticks to the person rather than the action — and the gap between free and paying users becomes visible.
3. Stringing together — lining up one person's events by time. Put the signup line, the document-created line, and the share line in order and you see that out of 100 people, 62 created a document and 19 shared one, which makes the drop from 62 to 19 the next thing to work on.

That third reading is what answers the question the team was stuck on earlier. It only works when the same person's lines carry the same identifier, though. Before and after login usually end up with different values, so identity resolution is run separately to stitch the two into one person.

"That button doesn't have an event on it yet, so there's nothing to count right now."

The feature shipped, but the code that records the action was left out.

"That's the event number, so it can run about 3 percent off the payment ledger."

Some of the lines never arrived, which makes the figure lower than reality.

"The name got split in two, so we have to add both together."

The same action is instrumented under two names, so the number on screen is showing half of it.

At Pagedeck, event names get decided in the same working session as the screen design. Mia writes down what she wants to learn from the feature, Theo says where each of those actions can be caught, and the two settle on names and properties before development starts. Deciding to add instrumentation later leaves the entire launch week empty — and the launch week is exactly when where the first users stalled matters most.

The most common assumption is that instrumenting everything now means having something to analyze later. More records look safer than fewer, and keeping feels lower-risk than deleting. But lines with careless names and no properties answer nothing once they've piled up. Six months on, if nobody left at the company knows which button on which screen btn_click_2 referred to, that line may as well not exist.

Taking event counts as the literal number of times something happened is the other mistake. A machine wrote the record automatically, so there seems to be no room for human error in it. In practice blockers and dropped connections mean some lines never land, which is the problem known as data loss. The awkward part isn't that the count shrinks but that it doesn't shrink evenly. When the people running blockers cluster in one segment, that group's behavior is the part that fades.