What Is Event Tracking? Events, Properties, and a Naming Plan That Lasts

Short answer: an event is a record that something happened: a user did an action at a time, with some details attached. Event tracking is the practice of sending those records to an analytics tool so you can count them, build funnels, and filter sessions. Track the handful of actions that represent progress in your business, name them consistently, and never put personal data in them.

Table of Contents

1. What an Event Is
2. What to Track
3. Naming
4. Properties
5. Common Mistakes
6. Key Takeaways

What an Event Is

An event has three parts.

deepsync("track", "purchase_completed", { value: 1499, currency: "INR", items: 2 });

Page views are events too. Most tools record them automatically.

There are two ways events get recorded:

• Autocapture. The tool records clicks, scrolls, inputs, and page views without code.
• Custom events. You send a named event from your code at a meaningful moment.

Autocapture tells you what was clicked. A custom event tells you what it meant. "Clicked a button with the text Pay" and "payment succeeded" are different facts (autocapture and manual tracking).

What to Track

Start with outcomes, not interactions.

Ten to twenty events cover most businesses. Failures are the most often forgotten and among the most useful: you cannot find sessions with a failed payment unless the failure is recorded.

Things you usually do not need custom events for: clicks on ordinary links, scroll depth, and page visits. Heatmaps and autocapture already hold them.

Naming

Pick one convention and write it down.

The last two matter most. Putting variable values in event names creates hundreds of distinct events that cannot be analysed together.

Keep a short tracking plan: a table with each event's name, when it fires, its properties, and who owns it. It is the document a new team member needs.

Properties

Properties make an event useful for segmentation.

• Keep types consistent. value is always a number, never "1,499".
• Use a fixed set of values where possible: method: "upi" | "card" | "cod".
• Include the currency with any amount.
• Use the same property names across events. Not plan in one and tier in another.

Traits that describe the user, such as plan or role, belong on the user and not on every event:

deepsync("identify", "user_123", { plan: "pro", role: "admin" });

Common Mistakes

1. Tracking everything. Hundreds of events nobody looks at, and nobody trusts.
2. Firing on click instead of on success. A click on "Sign up" is not a signup. Fire the event when the server confirms.
3. Double firing. A re-rendering component or a page reload sends the event twice. Check counts against your database (why numbers do not match).
4. Personal data in properties. Emails, phone numbers, names, and free-text fields should not be sent. Use an internal ID (personal data in URLs is the same problem in another place).
5. Renaming events without a plan, which breaks history.
6. No testing. Verify each event fires once, with the right properties, on mobile and desktop.
7. Events that only fire after consent, with nobody remembering why counts are lower than the backend's. DeepSync records nothing before consent by default, so events from visitors who decline are not sent (consent).
8. Tracking set up once and never reviewed. Features change; events rot.

Once events exist, they become useful in three places: as goals, as funnel steps, and as filters to find the sessions in which they happened. The third is the one teams overlook. An event such as payment_failed turns into a list of recordings you can watch.

Key Takeaways

• An event is a named action with properties and context.
• Track outcomes, steps, value moments, and failures.
• Use one naming convention and keep values out of names.
• Fire on success, test, and reconcile with your database.

Conclusion

Good event tracking is small and deliberate. A dozen well-named events you trust are worth more than a thousand you do not.

Start free with DeepSync.