Event Tracking: Tracking Plans, Naming & Properties

Q: How do I track users across sessions and devices?

Use an identity model: assign an anonymous id to track activity before login, then call identify when the user authenticates to link that anonymous id to a stable user id. The analytics platform stitches the pre- and post-login activity (and activity on other devices, once they log in) into one user. Consistent identity is what makes cross-session funnels, retention cohorts, and multi-touch attribution possible — without it, every session looks like a different person.

Event Tracking

Event tracking is the practice of recording user actions — a signup, a button click, a purchase — as structured events that analytics tools can analyze. It's the raw material of all modern analytics: funnels, retention, and attribution are only as good as the events feeding them. Instrument well and you can answer almost any behavioral question; instrument carelessly and you get a pile of inconsistent data nobody trusts.

The deciding factor isn't the tooling — it's discipline. A shared tracking plan (which events exist, what they're named, what properties they carry) is what separates analytics that drives decisions from analytics that gets ignored. Event tracking is as much governance as engineering.

TL;DR

An event = a named user action plus properties (context).
A tracking plan defines events, names, and properties before you instrument.
Use consistent naming and tie events to a persistent user identity.
Bad event data is worse than none — govern it like a schema.

Quick Example

A good event has a clear name and rich, consistent properties:

Anatomy of an Event

Event name — the action, in a consistent convention (e.g. Object Action: "Product Added", "Checkout Started").
Properties — structured context (ids, value, category, source) that makes the event analyzable.
User identity — who did it: an anonymous id before login, a stable user id after, linked so the journey connects across sessions and devices.
Timestamp & context — when, and device/page/campaign metadata.

The Tracking Plan

A tracking plan is the schema and source of truth for your events — usually a shared spreadsheet or a governance tool — defining every event, its naming, its properties, and their types. It's written before instrumentation so engineering, product, and analytics agree on what's measured.

💡 Without a tracking plan, every team names events their own way and the data becomes unusable. The plan is the single highest-leverage investment in trustworthy analytics.

Naming Conventions

Pick one convention and enforce it everywhere:

Object Action (past tense) — "Product Added", "Order Completed". Widely recommended.
Consistent case (Title Case or snake_case) for events and properties — don't mix.
Reusable property names — value, currency, product_id mean the same thing everywhere.

Identity

Tie events to a user so cross-session behavior connects:

Anonymous id — assigned before login, tracks pre-signup activity.
identify — when a user logs in, link the anonymous id to a stable user id.
Consistent identity is what makes funnels, retention, and attribution possible across visits and devices.

Best Practices

Write the tracking plan first — events, names, properties, and types, agreed across teams.
Track meaningful actions, not every click — instrument the events that answer real questions.
Be consistent — one naming convention, reusable property names, stable types.
Capture identity — anonymous → identified, linked on login.
Validate events — guard against malformed/renamed events (schema enforcement / a data layer or CDP).

Common Mistakes

Inconsistent naming

Tracking everything (or nothing useful)

FAQ

What is a tracking plan and why do I need one?

A tracking plan is the documented schema for your analytics events — every event name, its properties, their types, and what each means — agreed across product, engineering, and analytics before instrumentation. You need it because without a shared definition, different people track the same action under different names with different properties, producing inconsistent data nobody can analyze. The tracking plan is the single most important investment in analytics quality; it's cheaper to maintain than to fix dirty data later.

How should I name events?

Adopt one convention and enforce it. A widely recommended pattern is Object Action in past tense — "Product Added", "Order Completed", "Signup Started" — which reads naturally and groups related events. Keep case consistent (don't mix Title Case and snake_case), reuse property names across events (value, product_id always mean the same thing), and avoid synonyms for the same action. Consistency matters more than the specific style you pick.

What's the difference between an event and a property?

An event is the action ("Product Added"); properties are the structured context attached to it (product_id, price, quantity, category). Events tell you what happened; properties let you segment and analyze it — revenue by category, conversions by source, funnels filtered by plan. Design events to be reusable and properties to carry the dimensions you'll want to slice by. A few well-propertied events beat many narrow ones.

How do I track users across sessions and devices?

Use an identity model: assign an anonymous id to track activity before login, then call identify when the user authenticates to link that anonymous id to a stable user id. The analytics platform stitches the pre- and post-login activity (and activity on other devices, once they log in) into one user. Consistent identity is what makes cross-session funnels, retention cohorts, and multi-touch attribution possible — without it, every session looks like a different person.