Event tracking

Without events, every decision about a page or feature rests on assumption. With them, a vague complaint like "pricing is not converting" becomes specific: where people stop, how long they stayed and what they did next. Behaviour also predicts better than a survey. A buyer who revisits a security page three times is telling the sales team something. An account whose logins fall below its own normal level is a churn risk weeks before it cancels.

• Write a tracking plan first: a list of event names, when each fires and which properties it carries.
• Start with events tied to revenue, such as a trial signup, a demo request or a purchase, and make sure they fire reliably.
• Add the steps above them in the funnel, then in-product events such as invitations sent or a first report created.
• Name events consistently, for example an object followed by a past-tense verb.
• Connect events to a known person or account in the CRM, so a named account visiting pricing twice this week becomes a trigger for sales.
• Check the consent rules for the tool and region in use, because tracking may need permission.

An event is one thing that happened, stored as a small record. It has a name such as demo_requested, a time, who did it if known, and properties like the page, the plan or the campaign. Add up the records and the real path people take through a site or product becomes visible. It is rarely the tidy sequence a team assumes.

Event tracking also covers what is sometimes called activity tracking: following behaviour over time, such as emails opened, logins and features used, to see who is warming up and who is drifting away.

• Tracking every click without a question to answer, then drowning in data.
• Changing event names without a record, which breaks comparisons over time.
• Reading counts without watching a few real sessions to see why.