What is event tracking for a product team?

Event tracking is naming the actions you will look at on Monday and recording those. I use object_action names such as project_created. UI conversions sit on the button as an HTML goal. If a property will never appear in a chart, I do not send it. The weekly check is which outcome fired, on which button, and whether the funnel still completes.

How should I name events?

For event tracking, pick object_action and stay there. project_created, report_shared, billing_updated. A name like clicked is useless a month later because you cannot tell which control it was. I write the name down before I ship the button, then I check staging to see that exact string arrive.

Do I need a property on every event?

No. Most events need nothing extra. Add a property only when you will group by it in a chart, such as plan or role. Leave names, emails, and tokens out. EventDash filters PII on the tracker path. Event tracking still works without those fields.

How do I check event tracking before release?

I look at four things in staging before I merge. The name matches object_action. The payload has no personal data. The event shows up in the dashboard. The funnel that depends on it still completes. I run that check once a sprint. Free includes 100k events a month, which is enough to see the event arrive.

← Back to Blog

Event Tracking Basics for Product Teams

Jan 21, 2026•Updated Oct 9, 2026•Wlad

Event tracking goes wrong when a feature ships and nobody agrees what "conversion" means. I have done that. The button was live, the chart was empty, and two of us had different names for the same click. We wrote the name down before the next button shipped, and that row showed up.

For a product team, event tracking is the minimum that still answers a weekly question: which outcome fired, on which button, and whether the funnel still completes. I used to log every click "in case we need it." We never charted those events, and the names drifted. Now I keep the ones tied to activation, a repeat action, or a return visit, and I drop the rest.

The one-sentence definition of a conversion funnel stays on the glossary. The setup for the steps is cookieless conversion funnels.

Start with outcomes, not clicks

Before I list events, I write the outcomes I will actually review:

Activation: the moment someone first sees value
Engagement: the behavior that means they came back to the product, not just the site
Retention: what brings them back after a week

Then I map events to those outcomes. The highest-value path becomes a conversion funnel.

Use one naming convention

I use object_action.

project_created
report_shared
billing_updated

Name	A month later
`clicked`	You cannot tell which button it was.
`project_created`	Someone created a project.

clicked without the object is how you lose a month.

Send only properties you will chart

An event can carry properties. Most of mine do not.

Required: something you will group by, such as plan or role
Sometimes: a detail that explains the behavior, such as a variant
Never: a name, an email, a token

If I will not open the property in a chart, I do not send it. The tracker filter still means you leave email out of the payload. How that filter works is in privacy-first analytics.

Put goals on the button

For a UI conversion, the button can carry the goal.

<button data-ed-goal="signup_clicked">
  Create account
</button>

The tracking sits next to the control, so a redesign is less likely to drop the event quietly. The reference is HTML attributes. Install starts at the quickstart.

Check the event before you merge

For every new event I look at staging:

The name matches object_action
The payload has no personal data
A sample looks right
The event shows up in the dashboard
The funnel that depends on it still completes

I run that list once a sprint.

Keep it small

The tracker is about 11 KB, cookieless, and aimed at funnels, goals, and events. The tag-manager project notes are on their own page. If you are leaving GA4, the comparison is EventDash vs Google Analytics. Free is 100k events/month. Sign up and put the name on the button before you ship it.

Sources

HTML data-* attributes, which data-ed-goal uses, are documented in MDN's Use data attributes. What the tracker stores is in the privacy feature docs.

Key takeaways

Map events to activation, engagement, and retention, and skip the clicks you will never chart.
Name events object_action, like project_created, and send only properties you will actually chart.
Ship UI conversions as HTML goals. Check the name and the payload in staging before merge.
The tracker is about 11 KB and cookieless. Free is 100k events/month, enough to check a new name after signup.

FAQ

What is event tracking for a product team?: Event tracking is naming the actions you will look at on Monday and recording those. I use object_action names such as project_created. UI conversions sit on the button as an HTML goal. If a property will never appear in a chart, I do not send it. The weekly check is which outcome fired, on which button, and whether the funnel still completes.
How should I name events?: For event tracking, pick object_action and stay there. project_created, report_shared, billing_updated. A name like clicked is useless a month later because you cannot tell which control it was. I write the name down before I ship the button, then I check staging to see that exact string arrive.
Do I need a property on every event?: No. Most events need nothing extra. Add a property only when you will group by it in a chart, such as plan or role. Leave names, emails, and tokens out. EventDash filters PII on the tracker path. Event tracking still works without those fields.
How do I check event tracking before release?: I look at four things in staging before I merge. The name matches object_action. The payload has no personal data. The event shows up in the dashboard. The funnel that depends on it still completes. I run that check once a sprint. Free includes 100k events a month, which is enough to see the event arrive.