Event Analytics: Structure, Approaches, and Tracking Parameters
Event analytics for digital products relies on tracking key user interactions. Each event captures the name, timestamp, user_id, and basic parameters: country, platform, device, OS. Additional event properties provide context for the action, while user properties add demographics and identifiers (Amplitude ID, Device ID).
Event structures tie directly to product goals. Without proper tagging, you can't calculate metrics like DAU, MAU, retention rate, or revenue breakdowns. Analysts often inherit events from predecessors, but new projects start from scratch.
Choosing a Tracking Strategy
This determines data volume and analysis complexity. Two basic approaches:
Targeted approach focuses on events for specific business goals. Pros: quick implementation, low storage costs, easy validation. Cons: limited depth, misses behavioral details.
Extensive approach captures all interactions. Pros: maximum flexibility, insights from unexpected data. Cons: database bloat, filtering complexity, accumulation of outdated events.
| Event Category | Targeted | Extensive |
|-------------------------|----------|-----------|
| Registration | ✅ | ✅ |
| Screen Views | ✅ | ✅ |
| Action Buttons | ✅ | ✅ |
| Payment | ✅ | ✅ |
| Technical Errors | ❌ | ✅ |
| Ad Banners | ✅ | ✅ |
| Pop-up Notifications | ❌ | ✅ |
| Scrolling Blocks in Feed| ❌ | ✅ |
| Saves/Sharing | ⚠️ | ✅ |
Real projects combine approaches. Example: testing temporary landing pages with a focus on form conversion. Track only key events (view, click, submit), ignoring intermediate interactions to save resources.
Event Components
An event is more than just a name—it's also parameters. Basic set:
- Event Name: object + action + category (e.g.,
main_screen_shown). - Timestamp: exact capture time.
- User ID: unique identifier.
- User properties: platform, OS, language, country, region, Device ID.
- Event properties: context (type=landing_1, screen_name=home).
Trackers like Amplitude, GA, Segment automatically add up to 2000 properties, but practice shows 50–300 is plenty. For small projects, 100–150 parameters (user + event) suffice. Exceeding limits (e.g., in free Amplitude) causes data loss.
Document properties in Google Sheets: description, type, value examples. This simplifies handoff to the dev team and analysis.
Naming Conventions and Standards
A unified naming structure speeds up database searches. Format: [object]_[action]_[category] in snake_case.
- Objects: screen, button, modal, banner.
- Actions: tap, view, swipe, create, delete.
- Category: home, checkout, promo_landing.
Notation examples:
- snake_case:
page_view. - camelCase:
pageView. - all lowercase:
pageview.
Avoid variations like button_tap / buttons_tap. Pick a standard once per project.
Comparison with tracker events:
| Custom | Amplitude |
|---------------------------------|------------------------------------------------|
| main_screen_shown, type=landing_1 | [Amplitude] Page Viewed, Page URL=https://landing_1.comp.org/ |
Custom events are shorter and more convenient in code. Update documentation with changes.
Building the Event List
Base it on the funnel and unit economics. Methods:
- By main funnel: registration → onboarding → purchase.
- By screens (from Figma): sequential UI breakdown.
- Full dataset: for A/B tests or discovery phase, followed by trimming.
Review prototypes, test user flows. Hand off to dev: events + parameters. After implementation, verify raw data in the DB.
What's Important
- Events must directly support product goals and metrics.
- Balance data volume: targeted for stable features, extensive for experiments.
- Standardize naming conventions for scalability.
- Document all properties, limit parameters to 100–300.
- Regularly clean the DB of outdated events.
Event analytics requires deep product knowledge. Proper event design minimizes noise and maximizes actionable insights.
— Editorial Team
No comments yet.