Event Design: The Foundation of Product Analytics

Great products measure what matters. Most teams get this backwards - they track everything, hoping insights emerge from chaos. They won't.

Why Most Analytics Fail

Event instrumentation is your product's navigation system. It captures user behavior, highlights friction points, and signals success. Most teams approach this with two fundamentally flawed strategies.

First, there's the "track everything" approach. These teams instrument every click, hover, and scroll. Their data warehouse becomes a landfill. Signal drowns in noise. Engineering teams waste cycles maintaining unused events. The analysis becomes impossible.

Then there's the "surface metrics" trap. These teams track vanity metrics, count page views without context, and measure actions without outcomes. They collect data that tells them nothing about value.

The result? Vast data sets that answer no valuable questions. But there's a better way.

Starting with KPIs: The Only Way Forward

Great analytics start with clarity about what matters. Take Spotify for example. Here's how they could track core actions:

  • Songs played to completion (engagement)
  • Playlists created (investment)
  • Artists followed (long-term retention)
  • Songs skipped (negative signal)

Each event ties directly to user value and business growth. Nothing is tracked without purpose.

This clarity guides every aspect of their analytics. However, you need to understand the fundamental building blocks to implement this approach.

Core Events That Matter

Think of events as your product's vital signs. Each type reveals something crucial about your product's health.

Success Events: Capturing Value

Success events capture moments when users extract real value from your product. Take Uber:

  • Ride completed (core value delivered)
  • Driver successfully matched (key milestone)
  • Payment processed (transaction success)

Unlike vanity metrics, these events represent complete units of value delivery. They answer straightforward questions:

  • Did the user achieve their goal?
  • Was value successfully delivered?
  • Did the key transaction complete?

Each success event should directly relate to a business outcome or user need. For Netflix, it's not just "video played"—it's "show completed." For Spotify, it's not "music started"—it's "song played to completion."

Think of success events as your product's finish lines. They tell you not just that users showed up but that they accomplished what they came to do.

But value doesn't appear from nowhere. Users follow paths to reach these moments.

Intent Events: Understanding the Journey

Intent events map the journey users take before reaching success. While success events show the destination, intent events reveal how users get there.

Take a food delivery app; the user flow might look like this :

  • Restaurant menu opened
  • Item added to cart
  • Delivery address entered
  • Payment method selected

Each step signals clear user intent: exploring options, making selections, and moving toward purchase. By tracking these breadcrumbs, you can:

  • Spot where users drop off
  • Identify friction points
  • Understand decision patterns

For Spotify, intent might look like:

  • Search for artist
  • Browse playlist
  • Click song preview
  • Open album details

These events show progression toward the success event of playing a whole song.

The key is tracking meaningful progression, not every click. Each intent event should represent a clear step toward your success metrics, and each abandonment signals friction. But sometimes, users hit walls.

Failure Events: Spotting Problems Early

Failure Events: Early Warning Signals

Failure events show where users are blocked from achieving their goals. Think of failure events as your product's warning lights—they illuminate problems before they become crises.

Take an e-commerce app, some of the failure events might be:

  • Payment declined
  • Out-of-stock notification
  • Cart abandonment
  • Search with zero results

Each signals a specific type of friction. For a video platform like Netflix:

  • Playback errors
  • Failed downloads
  • Quality downgrades
  • Loading timeouts

The key is identifying failures that prevent value delivery. Not every error is a failure event - focus on those that block key user outcomes.

Good failure tracking requires clear triggers. A user trying multiple payment methods suggests friction and a cart abandoned after repeated errors reveals a problem pattern.

Systematically monitoring these signals allows you to catch issues before they impact your core metrics. But tracking them alone doesn't tell the whole story.

Properties: Making Events Meaningful

Event properties transform isolated data points into meaningful insights about user behavior. They answer critical questions:

The Why Properties reveal underlying patterns:

  • Why do users abandon carts?
  • Why do certain features see higher adoption?
  • Why does engagement vary by segment?

The How Properties show usage patterns:

  • How do users navigate your product?
  • How do different segments behave?
  • How does context affect decisions?

Take Netflix, for example:

  • Content category: preferences such as Comedy, Romance etc
  • Content Id: Unique identifier for each show/movie
  • Content Name: Name of the TV show or movie

Properties enable you to:

  • Segment users meaningfully
  • Spot behavior patterns
  • Identify optimization opportunities
  • Understand feature effectiveness

Different Types Of Event Properties

Event properties can generally be categorized into three main types:

  1. Action Properties
  2. Contextual Properties
  3. User Properties

Action Properties: Understanding User Choices

Action properties reveal the specific choices users make while using your product. While events tell you what users do, action properties tell you how they do it.

Take a ride-sharing app for example. When tracking a "Ride Ordered" event, action properties might include:

  • Car type selected
  • Route preference chosen
  • Payment option picked

These details transform basic metrics into meaningful insights.

Why action properties matter:

  1. They reveal user preferences:
    • Popular car types by location
    • Preferred payment methods by user segment
    • Common route choices at different times
  2. They expose usage patterns:
    • Weekend vs weekday preferences
    • Business vs personal ride choices
    • Peak time behavior differences
  3. They highlight improvement opportunities:
    • Under-utilized options
    • Feature adoption gaps
    • User experience friction points

Good action properties don't just collect data - they tell stories about how users interact with your product.

Contextual Properties: Understanding the When and Where

Contextual properties show the conditions when users interact with your product. They capture the situation around each user action.

Take Uber for example:

  • Number of drivers nearby
  • Current surge pricing
  • Local weather conditions
  • Time of request

Why contextual properties matter:

  1. They reveal situational impact:
    • How availability affects booking decisions
    • When surge pricing deters rides
    • Which conditions drive demand
    • What times show highest activity
  2. They help spot friction points:
    • High abandonment during surge
    • Drop-offs when drivers are scarce
    • Patterns in failed bookings
    • Peak time behaviors
  3. They guide product decisions:
    • When to incentivize drivers
    • Where to focus availability
    • How to adjust pricing
    • What features need attention

Important note: Contextual properties can only capture the present moment. They can't predict or record future states. For example:

  • Can track: Number of drivers available when ride requested
  • Can't track: How long it took to find a driver

You'll need new events for future states. Instead of cramming everything into one property, create specific events like "Driver Assigned" or "Ride Completed" to capture the full journey.

Good contextual properties don't just describe situations - they help explain user decisions.

User Properties: The Core of User Understanding

User properties are more than just data points - they build a comprehensive picture of who your users are. These properties fall into four key categories:

  1. Demographics:
    • Age
    • Gender
    • Location
    • Language
    • Time zone
  2. Account Information:
    • Account type (free/premium)
    • Subscription status
    • Signup date
    • Account age
    • Role/permissions
  3. Behavioral Data:
    • Purchase history
    • Browsing patterns
    • App usage frequency
    • Feature adoption level
    • Engagement scores
  4. User-Defined Attributes:
    • Preferences
    • Interests
    • Self-selected categories
    • Custom settings
    • Personal goals

Now, let's see how different products use these:

For streaming platforms like Netflix:

  • Demographics: Country, language
  • Account: Subscription tier, join date
  • Behavioral: Viewing habits, completion rates
  • User-defined: Genre preferences, ratings

For fitness apps like Strava:

  • Demographics: Age, location
  • Account: Premium status
  • Behavioral: Workout frequency
  • User-defined: Training goals

The key is combining these properties to understand users in context. Don't just collect data - build user stories.

Naming Events & Properties: A Guide to Clear Analytics

How you name your events and properties shapes your entire analytics system. Get it right, and your data tells clear stories. Get it wrong, and you'll spend hours decoding your own tracking.

Here's how to do it right:

Event Names: The Building Blocks

Bad naming turns analytics into chaos. Good naming makes insights obvious.

Here's how to build a naming system that makes sense.

Why Names Matter

Think of analytics like a library. Without proper naming:

  • "Signup", "User Signed Up", and "Sign up" mean the same thing
  • Analysts waste time decoding events
  • Teams misinterpret data
  • Future tracking becomes inconsistent

The Object-Action Framework

A simple framework to name events is to follow the object action framework ( recommended in Segment's documentation).

  1. Objects (What users interact with):
    • Product
    • Account
    • Playlist
    • Document
    • Message
  2. Actions (What users do):
    • Viewed
    • Created
    • Shared
    • Added
    • Downloaded

Pro Tips

  1. Use Noun + Verb in Title Case:
    • ✅ "Video Played"
    • ✅ "Order Completed"
    • ❌ "play_video"
    • ❌ "OrderedProduct"
  2. Use Clear Language:
    • ✅ "Payment Failed"
    • ✅ "Search Completed"
    • ❌ "Txn_Error"
    • ❌ "QueryEndpoint_Hit"

Property Names: Adding Detail

Properties need different rules:

  1. Use snake_case or camelCase (pick one):
    • snake_case: payment_method, user_type
    • camelCase: paymentMethod, userType
  2. Be Specific:
    • ✅ duration_seconds
    • ✅ payment_method_type
    • ❌ duration
    • ❌ type

Property Values

Define them clearly:

  1. For Finite Options:
    • payment_method: ["credit_card", "paypal", "apple_pay"]
    • user_type: ["free", "premium", "enterprise"]
  2. For Open Values:
    • search_term: Any string
    • view_duration: Integer in seconds

Remember: Good names make data useful. Bad names make data confusing.

Additional Tips

  • Document Everything: Create and maintain a comprehensive event dictionary that serves as the single source of truth for all event and property names.
  • Think About Future Analysis: Consider what questions you want to answer with your data and ensure your events and properties are structured to enable those analyses.
  • Start Small and Iterate: Don't try to track everything at once. Start with a core set of events and properties, and add more as needed
  • Always Test: Thoroughly test your instrumentation to ensure events are firing correctly and data is being collected accurately

Best Practices: Smart Property Design

Here's the hard truth about client-side tracking: just because you can track something doesn't mean you should.

Rule #1: Revenue Events Go Server-Side

Never trust client-side tracking for revenue. Ever. Here's why:

  • Ad blockers can block tracking
  • Network issues can lose events
  • Users can tamper with client data

Instead:

  • Track all money server-side
  • Double-verify every transaction
  • Log both attempts and successes
  • Keep audit trails clean

Rule #2: Be Strategic About Client-Side Properties

Here's the hard truth about client-side tracking: just because you can track something doesn't mean you should.

Keep your properties lean and purposeful:

  1. Always include:
    • Unique identifiers (playlist_id, user_id)
    • Key join keys for data warehouse
    • Critical analysis properties
  2. Skip what you can calculate:
    • Duration (calculate in Looker)
    • Derived metrics
    • Aggregated data
  3. Ask before adding properties:
    • Can we join this data later?
    • Can we derive this in our BI tools?
    • Is this truly needed for analysis?
    • Will this property drive decisions?

Remember: Every property adds payload weight and complexity. Keep them light, keep them valuable.

Rule #3: Document Changes

Tools might version automatically, but documentation matters:

  • Keep a clear event changelog
  • Note why changes happened
  • Track impact on dashboards
  • Alert relevant teams

Remember: In the future, you (or your replacement) will need to understand why decisions were made.

Rule #4: Test Religiously

Bad data is worse than no data. Test everything:

  • Verify event firing
  • Validate all properties
  • Check for duplicates
  • Monitor volumes daily

Set up alerts for:

  • Sudden volume changes
  • Missing properties
  • Unusual patterns
  • Failed events

Remember: Implementation isn't just coding. It's building a reliable system for understanding your product.

Building a System of Understanding

Analytics isn't about data collection. It's about building a lens through which we understand our users.

Your event design should be:

  • Purposeful, not comprehensive
  • Focused, not scattered
  • Insightful, not just informative

Start with what matters. Track what drives value. Ignore the rest.

Remember: You're not building a data warehouse. You're building a system of understanding. That's how great products are built.