Event tracking
Logging named user actions with details attached, so you can count what people actually did instead of guessing from pageviews.
See it
What it is
An event is a named thing a person did, plus properties describing it, plus who did it and when. 'checkout_completed' with { plan: 'pro', source: 'pricing_page', amount: 19 }. That is the whole idea. Pageviews tell you where people went; events tell you what they actually did once they got there, which is the only way to answer 'how many people finished the thing'.
Every product analytics tool (PostHog, Amplitude, Mixpanel, GA4) speaks this shape, and Segment, a CDP that routes events rather than analyzing them, ships the same shape onward to whichever tool you point it at. Fire the event on the real outcome, not the click: a 'signup' event on the button press counts people whose signup failed. Twenty well named events beat two hundred noisy ones, and the naming scheme that keeps them consistent has its own name (event taxonomy).
Gotcha: properties are cheap to add today and often unrecoverable later. Some values can be reconstructed after the fact from account history, billing records, or warehouse tables, but anything that only existed at event time (which price was on screen, which variant was live, which referrer sent them) is gone unless some other system recorded it. If nothing captured 'plan' in March, no report will ever tell you what March looked like by plan. Second gotcha: browser-side events get eaten by ad blockers and privacy modes, so anything you bill or forecast on should be sent from the server.
Ask AI for it
Instrument event tracking for this flow using the analytics SDK already in the project (PostHog if none exists). Rules: name events in snake_case as object_verb_past ('checkout_completed', 'project_created') unless the installed SDK documents a different house convention, in which case follow that one and say so; fire on the confirmed success path, not the click handler; attach properties for the things I will want to slice by later (plan, source, variant, count, duration_ms). For the anonymous-to-known handoff, read the installed SDK's own docs and use its documented transition at login, because merge semantics differ by vendor. Put every call behind one typed track() wrapper with a union of allowed event names, so names cannot drift, and list the final event catalog as a table when you are done.