What Is Event Tracking? Events, Properties, Naming

Event tracking records actions rather than visits: the signup, the upgrade click, the file download, the search. Where pageviews answer 'where did people go?', events answer 'what did people do?' — and every business question worth asking eventually needs the second kind.

Anatomy of an event

window.webanalytics.track('plan_selected', {
  plan: 'pro',          // string property
  seats: 5,             // numeric property
  period: 'annual',
});

• Name: the action, past tense or noun_verb — what happened.
• Properties: the context — which plan, which position, how much. Properties are what make events queryable; an event without them is just a counter.

Naming conventions that survive growth

1. snake_case, lowercase, forever. signup_completed, not SignupCompleted-then-signUp_done. Case drift splits reports irreparably.
2. Few names, rich properties. cta_clicked with a position property beats hero_cta_clicked + footer_cta_clicked + nav_cta_clicked. The CTA guide and feature-adoption pattern both run on this rule — a dozen event names cover most products.
3. Name the business moment, not the UI. trial_started survives a redesign; blue_button_clicked does not.
4. Write the dictionary down. A 20-line doc of names and properties prevents the taxonomy graveyard that kills heavyweight analytics deployments.

Automatic vs explicit — the layering

Modern trackers capture the universal layer automatically (pageviews, clicks, performance, errors); explicit track() calls are reserved for the moments with business meaning. The division of labor matters: autocapture means you never miss the basics, explicit events mean your reports speak your business's language. Events with no PII in properties, joined on one visitor record, segmented by first-touch source — that is the entire grammar of product analytics, learnable in an afternoon.