Concepts
Heavy events vs. micro events
Why state-changing events and UI-state events behave differently, and how conflating them confuses your data.
The previous chapter introduced one type of event — actions that change state. There's another type: UI state changes that don't touch the database. Both are events, but they behave differently, and conflating them causes a specific kind of data confusion.
The two types
A heavy event represents a change in your database. The user did something with consequences: an invoice was created, a customer was edited, a subscription was canceled, a file was uploaded. Heavy events should always wait for server confirmation before firing (see Tracking on successful states).
A micro event represents UI state changing. A dropdown opened. A modal was dismissed. A tab was selected. A search box was focused. These are immediate — the UI state itself is the source of truth, so the event fires the moment the state changes, without waiting on a server.
Examples
| Action | Type | Why |
|---|---|---|
| User clicks "Create invoice", server creates row, UI shows new invoice | Heavy | State changed in DB |
| User opens the customer dropdown to start selecting a customer | Micro | Just UI state |
| User selects a customer from the dropdown | Micro | UI state change |
| User submits the invoice form, server creates the invoice | Heavy | DB change |
| User clicks the "?" icon to open a help modal | Micro | UI state |
| User changes the date range filter on a dashboard | Micro | UI state, no DB change |
Why the distinction matters
If you track everything as heavy events, you wait for server confirmation on actions that don't need it — but worse, you fail to track some actions at all (because there's no server confirmation to wait for). Your funnel between "opened the dropdown" and "selected a customer" doesn't exist.
If you track everything as micro events, your heavy event counts get inflated by failures (see Tracking on successful states) and you lose the ability to trust state-change metrics.
When you separate them, you get both: clean state-change data and rich engagement data side by side.
How they get used
Heavy events power "what did users actually do" analyses:
- Number of invoices created this week
- Conversion rate from sign-up to first invoice
- Revenue events (these are always heavy)
Micro events power "where do users get stuck" analyses:
- Funnel from "opened the customer dropdown" → "selected a customer" → "completed the invoice form" → "invoice created"
- Heat map of which UI elements get the most interaction
- Drop-off analysis in multi-step flows
The funnel example is the best reason to track micro events. Without them, you can only see who made it through the entire flow. With them, you see exactly where people stop — which is what tells you what to fix.
Don't overtrack
Micro events are useful, but easy to overdo. If you track every checkbox toggle, every accordion expand, every tab click, you'll drown in events that don't answer any actual question.
The rule of thumb: track micro events when you're measuring drop-off in a known flow, or when you have a specific question about a specific UI interaction. Don't track them as general telemetry just because they're free to capture.
If you find yourself tracking 20 micro events on a single screen, you're tracking too much. Pick the 2–3 that matter for the flow you're trying to understand.
What about clicks on internal links?
A nav link click is a micro event in principle, but you usually don't need to track it explicitly — the resulting page view captures the navigation. Tracking the click as a separate event creates duplicate data without adding insight.
Exception: when the click leads somewhere the page view won't catch (an external link, a download, a modal). Then the click is the only signal you have, and it's worth tracking.
Naming convention
Heavy events use the past-participle convention: Invoice created, Customer added, Subscription canceled.
Micro events tend to use action verbs in past tense too, but describe UI state: Dropdown opened, Modal dismissed, Tab selected, Filter applied. Same convention, different semantics.
If you want to distinguish them at a glance in the event taxonomy, you can prefix micro events with the surface (Customer dropdown opened instead of just Dropdown opened) — both for clarity and because you'll likely have multiple dropdowns and need to differentiate.