How Event Tracking Records What Users Actually Did

What is event tracking in product analytics?

Product analytics tools use event tracking to record named user actions such as signup_completed or checkout_started along with properties describing each action, which turns page-level traffic data into a record of what people actually did. A pageview says someone reached the checkout screen. An event says they started checkout, on the team annual plan, from the pricing page, and never came back. Flowsery ships goal and event tracking alongside its built-in web analytics, so the same account holds the traffic numbers and the action-level record.

What are the two parts of an event?

An event has a name and a set of properties, and the split between them decides whether the data stays queryable a year later. The name identifies the action and stays constant across every occurrence. The properties carry the parts that change from one occurrence to the next: which plan, which source, how much, how long. Put the action in the name and the variables in the properties, and every question about that action becomes a filter instead of a new event.

Five events with good properties answer more questions than fifty events with none. Those five support a signup funnel, a plan-by-plan checkout comparison, a coupon report and a team-expansion metric without a single extra tracking call. The property names in that table follow the object_adjective pattern PostHog documents in its product analytics best practices, with is_ reserved for booleans.

What does a badly named event look like next to a good one?

A badly named event pushes the variable detail into the name, which forks one action into a new event for every combination. Here is the same signup, tracked twice.

// Badly tracked: the plan and the page are baked into the name
track("Clicked Signup Button On Pricing Page Annual");
track("clicked_signup_button_on_pricing_page_monthly");
track("Signup Btn - Homepage");
 
// Well tracked: one stable name, the variables as properties
track("signup_completed", {
  signup_source: "pricing_page",
  plan_slug: "team_annual",
  is_invited: false
});

The first block produces three event names for one action, so the answer to "how many people signed up last week" is a manual sum that breaks the moment someone adds a fourth pricing page. The second block produces one event name and three filters. Ask a marketer to name the action out loud, then check that everything they said after the verb ended up in a property, not in the name.

Which event naming convention should a team pick?

The convention that works is the one written down and applied to every event, and the two published conventions disagree on the details. PostHog's product analytics best practices call for lowercase snake_case, present-tense verbs, and a category:object_action structure such as account_settings:forgot_password_button_click. Amplitude's data planning playbook calls for Title Case with a [Noun] + [Past-Tense Verb] structure such as Song Played, kept from the user's perspective so Message Sent means the user sent it.

Both work. Mixing them does not, because Signup Completed, signup_completed and signup:button_click become three unrelated rows in the same list. The examples in this post use snake_case with past-tense verbs, which reads as object then action and sorts every related event together alphabetically: checkout_completed lands next to checkout_started.

One hard constraint sits underneath whichever convention you choose. Google's GA4 event collection limits cap an event name at 40 characters, allow 25 event parameters per event, cap a parameter name at 40 characters and most parameter values at 100 characters, and place no limit on distinctly named events for web data streams while capping app data streams at 500 per app user. A category:object_action name plus a long noun runs into that 40-character ceiling faster than teams expect, and GA4 silently stops reporting an over-length name as a key event.

How does event tracking differ from autocapture?

Event tracking names the action in the application code before it ships, while autocapture records every click and form submit automatically and lets you define the meaning afterwards from the page structure. Autocapture gets a team a working stream on day one and breaks silently when a redesign changes the CSS selector it was matching. A named event moves with the code it lives in, so a component rename carries the tracking call with it. Most teams run both: autocapture for the exploratory long tail, named events for the numbers that appear in a board deck.

How do properties turn events into a funnel?

Two events with a shared property become a conversion step, which is how a conversion funnel is built out of raw event data. The completion rate for a step is one division:

step conversion rate = completed events / started events x 100

With 4,000 checkout_started events and 1,240 checkout_completed events in a week, the checkout step converts at 31 percent. Add plan_slug as a breakdown and that single number splits into a rate per plan, which is where the actual problem shows up. Properties are also what custom dimensions are built from, so the schema you design for events is the same schema your reports segment by later.

How many events should a team instrument?

Instrument the actions that appear in a decision, and stop. An event nobody has filtered on in three months is schema debt: it costs quota, it clutters the event picker, and it decays without anyone noticing. Start with the steps in the path to revenue, add the actions that separate a retained account from a churned one, then add new events when a specific question has no data behind it.

A smaller schema also keeps the privacy surface small. Flowsery is cookie-free and EU-hosted by design, and the properties a team chooses not to send are the ones that never need a retention policy. Teams weighing that tradeoff against a Google-first setup can read the privacy analytics versus GA4 comparison.

How do you check an event is firing correctly?

Trigger the action yourself, then confirm the event arrived with the right name and the right properties before you trust any chart built on it. The failure that costs the most is an event that fires with a null or misspelled property, since the count looks healthy while every breakdown quietly drops rows. Watching a real session alongside the event stream catches the mismatch in a way a dashboard cannot: Flowsery records every user session and connects to PostHog or Amplitude replays already recorded, with no re-instrumentation, so the replay and the event log sit next to each other.

Re-run that check after every front-end release that touches a tracked flow. An event that stopped firing produces a flat line, and a flat line reads like a product problem until someone opens the code.

Frequently Asked Questions

What is an event in analytics?

An event is a single named action a user took, recorded with a timestamp and a set of properties describing it. checkout_started with plan_slug: team_annual is one event. A pageview is one specific kind of event, recorded automatically by most analytics scripts.

What is the difference between an event name and an event property?

The name identifies the action and stays identical across every occurrence, so it can be counted. The property carries the detail that changes between occurrences, so it can be filtered and grouped. Anything you would want to filter by belongs in a property, never in the name.

Should event names use past tense or present tense?

Both conventions are published and both work, so pick one and enforce it. Amplitude's data planning playbook documents Title Case with past-tense verbs, and PostHog's best practices document lowercase snake_case with present-tense verbs. The cost of switching halfway through is two sets of names describing the same actions.

How many properties should a single event carry?

Send the properties you would filter or group by, and skip the rest. GA4 allows 25 event parameters per event according to Google's event collection limits, which is a ceiling rather than a target. Five to eight well-chosen properties on a core event covers most reporting questions.

Does event tracking require cookies?

No. Recording that an action happened needs no cookie, since a cookie exists to persist identity between visits rather than to capture the action itself. Flowsery runs cookie-free and EU-hosted, and still records events with their properties.

What breaks an event schema over time?

Renamed events, ad hoc events added without a convention, and properties that stop being populated after a refactor. Each one leaves the chart looking fine while the underlying data drifts. A written naming convention plus a check after every release on tracked flows prevents most of it.

What is schema debt in event tracking?

Schema debt is an event nobody has filtered on in three months. It costs quota, clutters the event picker, and decays without anyone noticing until someone finally audits the schema.

Can autocapture replace named events?

Most teams run both instead of choosing one. Autocapture catches the exploratory long tail and gives a team a working stream on day one, but it breaks silently when a redesign changes the CSS selector it was matching. Named events cover the numbers that appear in a board deck, since a component rename carries the tracking call along with the code it lives in.

What is the GA4 character limit for an event name?

Google caps an event name at 40 characters in GA4 and caps a parameter name at 40 characters too, with most parameter values capped at 100 characters. A category:object_action naming structure plus a long noun runs into that ceiling faster than teams expect, and GA4 silently stops reporting an over-length name as a key event.

How do you calculate a funnel conversion rate from events?

Divide completed events by started events and multiply by 100. With 4,000 checkout_started events and 1,240 checkout_completed events in a week, the checkout step converts at 31 percent. Breaking that number down by a property like plan_slug turns one rate into a rate per plan.