Making Smart Tradeoffs in Analytics: A Slack Tracking Plan Journey

In this content series - season 1, I create a tracking plan for a typical start-up tool every day for four weeks (I take a break on the weekend), so 20 in total. This is the second one: Slack. Here is the season overview:

Every click, every interaction, every moment of user engagement whispers a story. But what happens when those whispers become a deafening roar of data? Most teams believe that more tracking means more insights. The truth is brutally simple: tracking everything often means understanding nothing.

In this comprehensive guide, we'll deconstruct the mythology of "track everything" and reveal a strategic approach to analytics that prioritizes clarity, impact, and actionable insights. Drawing from real-world experience implementing tracking plans for complex products like Slack, we'll show you how thoughtful, minimalist tracking can unlock deeper understanding of user behavior than mountains of disconnected data points.

Don't miss the upcoming episodes of this series and sign up for free to my newsletter (and support my work):

Why Less Events Lead to Better Analytics: The Core vs. Nice-to-Have Decision

The Paradox of Event Tracking

"Let's track everything - we might need it later."

If you've ever been involved in setting up analytics, you've probably heard this phrase. It seems logical at first: data storage is cheap, and you never know what insights you might want to uncover in the future. Why not capture every click, hover, and interaction just in case?

But here's the paradox: tracking everything often leads to understanding nothing.

Let me illustrate this with a real scenario I encountered.

A product team had diligently tracked every possible interaction in their app - from button hovers to modal closes, resulting in over 200 unique events. When they wanted to understand how users were progressing through their core workflow, they spent days just trying to identify which events were relevant. Some events had similar names but tracked slightly different things. Others were deprecated but still collecting data. The signal was lost in the noise.

This "track everything" approach creates what I call analytics debt. Similar to technical debt, it accumulates silently but impacts your ability to move quickly and make decisions. Here's how:

1. Data Quality Suffers
   When you track everything, you spread your quality assurance thin. Instead of thoroughly validating a core set of events, you end up with hundreds of events that might be tracking incorrectly. I've seen teams spend weeks debugging inconsistencies between similar events, only to realize they could have used a single, well-designed event instead.
2. Analysis Becomes Harder, Not Easier
   More data doesn't automatically mean better insights. When an analyst needs to choose between "MessageSent", "MessageCreated", "MessagePublished", and "MessagePosted", they waste time figuring out which one to use. Even worse, different team members might choose different events for the same analysis, leading to inconsistent results.
3. Implementation Costs Stack Up
   Every event you track needs to be maintained. When your frontend changes, someone needs to update the tracking. When your analytics platform changes, someone needs to migrate the events. When new team members join, someone needs to document what each event means. These costs multiply with every event you add.
4. Actual Money Gets Spent
   Most analytics platforms charge based on event volume or have limits on events per user. When you're tracking everything, costs can spiral quickly. I've seen teams forced to sample their data or switch platforms because their event volume became unsustainable - all while only actively using a small fraction of the events they were tracking.

The solution isn't to track less for the sake of tracking less. Instead, it's about being intentional with what you track. In the next section, we'll look at a framework for making these decisions, using Slack as our example. You'll see how we can get more value from fewer, well-chosen events than from tracking everything that moves.

Remember: The goal of analytics isn't to collect data - it's to drive insights and decisions. Sometimes, less data, thoughtfully collected, gets you there faster.

This work is based on the chapters about event data design in my book Analytics Implementation Workbook. There, you can read more details about the D3L framework.

The Core Entity Test

When designing a tracking plan, the first and most crucial decision is determining what actually matters to your product. Just as architects need to identify load-bearing walls before any renovation, we need to identify our core entities before building our analytics.

Watch the video if you like to watch my decision process in real time:

The Core Entity Test is deceptively simple: "If I remove this entity, would the product still fulfill its core purpose?"

Let's apply this to Slack to see how it works in practice:

Workspace Entity

• Question: Could Slack function without workspaces?
• Answer: No. Workspaces are where all communication happens.
• Decision: Core entity ✅
• Why: Without workspaces, there's no container for channels, messages, or user organization.

Messages Entity

• Question: Could Slack work without messages?
• Answer: Absolutely not. Messages are the primary form of communication.
• Decision: Core entity ✅
• Why: Messages represent the fundamental unit of value in Slack.

Notifications Entity

• Question: Could Slack work without notifications?
• Answer: Yes, but with reduced utility.
• Decision: Nice-to-have ❌
• Caveat: This was a close call. While notifications are important for engagement, the core communication function remains intact without them.

Tools/Apps Entity

• Question: Could Slack work without third-party integrations?
• Answer: Yes, the core communication would be unaffected.
• Decision: Nice-to-have ❌
• Why: While tools add value, they're clearly an extension of the core product.

But the Core Entity Test isn't just a yes/no question. Sometimes entities live in a gray area, and that's where additional criteria come into play:

1. Strategic Importance
   Even if something isn't strictly core, it might be strategically crucial. For Slack, integrations might fall into this category if they're a key differentiator from competitors.
2. Current Focus
   If your team is spending the next six months improving notifications, it might make sense to include them as a core entity despite failing the strict test.
3. Analysis Requirements
   Sometimes non-core entities need tracking because they significantly impact core metrics. If notification engagement strongly correlates with workspace activity, you might want to track them anyway.

The Power of Saying No
The real value of the Core Entity Test isn't just in what it includes, but in what it excludes. Every entity you decide not to track:

• Reduces implementation complexity
• Improves data clarity
• Lowers maintenance burden
• Makes analysis more straightforward

The key is to start with a solid foundation of core entities and expand thoughtfully when needed. It's much easier to add tracking later than to remove it once it's embedded in your analytics culture.

Remember: Just because something is valuable doesn't mean it needs to be a core entity. Often, these features can be tracked as properties of core entities or as specific events without elevating them to entity status.

In the next section, we'll look at how to handle important features that don't make the cut as core entities, ensuring we don't lose valuable insights while maintaining our clean, focused tracking plan.

Don't miss the upcoming episodes of this series and sign up for free to my newsletter (and support my work):

Converting Events to Properties

One of the most powerful ways to reduce event sprawl is to recognize when an event should actually be a property. Here's the key principle: If something is a variation or attribute of an existing event, it's probably a property.

Let's look at some real examples from our Slack tracking plan:

Instead of separate events:

Message Sent
Message Edited
Message WithAttachment
Message WithMention

We use a single event with properties:

Message Sent
  properties:
    wasEdited: boolean
    hasAttachment: boolean
    hasMention: boolean

Why this works better:

• Analysis becomes simpler ("Show me all messages where wasEdited = true")
• Event volume stays manageable
• New variations can be added without creating new events
• Easier to maintain and document

A simple rule of thumb: If you find yourself creating events that are variations of the same action (like MessageSent), stop and ask if they should be properties instead.

This approach isn't just about cleaning up your tracking plan - it fundamentally improves your ability to analyze user behavior by making patterns easier to spot and compare.

Real-World Decision Examples

Let's dive into two of our most challenging decisions from the Slack tracking plan. These examples demonstrate how theoretical principles meet real-world constraints and requirements.

The Notifications Decision

Initial instinct: Core entity
Final decision: Nice-to-have
Key metrics impacted: User engagement, response time, workspace activity

This was our closest call. Here's why:

For notifications:

• Critical for user engagement
• Drive return visits
• Key feature for power users
• Important for workspace activity

Against notifications as entity:

• High event volume (cost implications)
• Core messaging works without them
• Can be tracked through other means
• Complex implementation across platforms

The Solution: Instead of creating a notifications entity, we track notification impact through:

• Message read rates
• Response times
• Return visit patterns
• User engagement metrics

This gives us the insights we need without the complexity of a full notification tracking system. But we might would add them later.

The Tools/Apps Decision

Initial instinct: Separate entity
Final decision: Property of workspace
Key metrics impacted: Workspace value, user engagement

This decision was clearer but offers important lessons:

Initial arguments for tools as entity:

• Revenue stream for Slack
• Differentiator from competitors
• Important for workspace stickiness
• Complex usage patterns

Why we changed course:

• Tools extend workspaces, they don't exist independently
• Most tool metrics tie back to workspace activity
• Simpler to analyze as workspace properties
• Easier to maintain and scale

The Solution:

WorkspaceUpdated
  properties:
    installedTools: string[]
    activeTools: string[]
    totalTools: number

Plus tool-specific properties on relevant message events:

MessageSent
  properties:
    sentByTool: boolean
    toolName: string

Key Takeaway: Both decisions prioritized simplicity and maintainability while preserving our ability to answer key business questions. They demonstrate that good tracking plan design isn't about tracking everything possible, but about tracking the right things in the right way.

Remember: The goal isn't to capture every possible data point, but to create a sustainable system that provides actionable insights while remaining manageable and cost-effective.

Don't miss the upcoming episodes of this series and sign up for free to my newsletter (and support my work):

Benefits of Starting Small

The natural instinct in analytics is to cast a wide net. But after years of implementing tracking plans, I've consistently seen better outcomes from teams that start small and grow thoughtfully.

Better Data Quality

• Fewer events mean more attention per event
• Higher confidence in analysis results
• Less time spent debugging tracking issues

Faster Time to Insight

Instead of:
Searching through 150+ events → Asking developers about differences → Finally starting analysis

You get:
Find relevant event from 30 clear options → Begin analysis immediately

Easier Team Adoption

• New team members understand the system quickly
• Clear, manageable documentation
• Consistent analysis across the team

The Compound Effect
Starting small doesn't mean staying small forever. It means building a solid foundation that you can confidently build upon. When you do need to expand, you'll do so with clear understanding and proven needs, not theoretical possibilities.

Remember: You can always add more tracking later, but removing or fixing problematic tracking is much harder. Start with what you know you need, not what you think you might need.

The Final Blueprint: A Production-Ready Tracking Plan for Slack

Understanding the Double Three-Layer Framework

Analytics isn't just about collecting data—it's about collecting the right data that tells a meaningful story about your product's success. The double three-layer framework is a strategic approach to tracking that transforms raw data into actionable insights.

What is the Double Three-Layer Framework?

Think of this framework as a carefully designed lens for understanding your product's performance. It consists of three distinct layers:

1. Product Layer: The foundational level that captures the core mechanics of your product
2. Customer Layer: A strategic view of how users progress through your product
3. Interaction Layer: A flexible catch-all for granular user interactions

Why Layers Matter

Traditional analytics often fall into a common trap: tracking everything possible. The result? A complex, noisy dataset that obscures more than it reveals. The three-layer framework solves this by focusing on meaningful, strategic tracking.

Product Layer: The Building Blocks Here, you define the core entities and activities that make your product unique. In Slack's case, this means tracking workspaces, channels, messages, and users—but only in ways that truly matter to understanding product usage.

Customer Layer: User Journeys This layer transforms product events into meaningful user progression. Instead of raw clicks, you're measuring meaningful milestones like "initial value achieved" or "risk of churn."

Interaction Layer: Flexible Insights A safety valve for those specific UX questions without cluttering your primary tracking. Want to know how often users click a specific icon? The interaction layer provides a clean, minimal way to capture these insights.

The Philosophy Behind the Framework

The goal isn't to track everything, but to track what matters. Each layer serves a specific purpose:

• Understand product mechanics
• Map user success
• Provide flexible insights

By treating your tracking plan as a thoughtful design process rather than a technical checklist, you create an analytics infrastructure that truly serves your business strategy.

Product Layer Deep Dive

The product layer is where we translate product mechanics into trackable, meaningful data. Here's a comprehensive look at how we approach tracking Slack's core product entities.

Workspace: The Foundation

A workspace isn't just a container—it's the primary unit of collaboration. Key tracking considerations:

• Essential Properties:
  • Workspace ID (always track)
  • Creation date
  • Status (active/inactive)
  • Domain (for account-based insights)
• Lifecycle Activities:
  • Workspace created
  • Workspace deleted

The critical decision: Skip "workspace updated" unless there's a compelling reason. Sometimes, the absence of an event is a strategic choice.

Channels: Collaboration Containers

Channels represent specific collaboration spaces within a workspace:

• Key Properties:
  • Channel ID
  • Type (public/private)
  • Associated workspace ID
• Lifecycle Tracking:
  • Channel created
  • Channel joined
  • Channel left
  • Channel archived

Messages: The Heartbeat of Communication

Messages are the most voluminous event—choose wisely:

• Critical Properties:
  • Message ID
  • Sender ID
  • Channel ID
  • Workspace ID
  • Message type (regular/thread/reply)
• Strategic Activities:
  • Message sent
  • Message read (with caution)
  • Message replied

User: Beyond Simple Identification

Users are more than just accounts:

• Meaningful Properties:
  • User ID
  • Email domain
  • Last active timestamp
  • Number of workspaces joined
• Key Activities:
  • User created
  • User invited
  • User joined
  • User removed

Subscription: The Revenue Perspective

Track what matters for business insights:

• Core Properties:
  • Subscription ID
  • Type
  • Member count
• Critical Activities:
  • Subscription created
  • Subscription renewed
  • Subscription cancelled

The Tracking Philosophy

Remember: Less is more. Each event and property should answer a specific business question. Avoid tracking for tracking's sake.

Key principles:

• Prioritize business impact
• Minimize event volume
• Ensure data usability
• Plan for future iterations

By carefully selecting what to track, you create an analytics foundation that grows with your product—not against it.

You can check out the complete design on the Miro Board:

If you want the nerdy version, you can check out the JSON schemas here:

Customer Layer: Mapping User Journeys

The customer layer transforms raw product events into meaningful narratives about user progression. It's where we move beyond technical interactions to understand how users truly experience and derive value from the product.

At its core, the customer layer sits atop the product layer, synthesizing product events into strategic insights about user behavior and product success. Unlike the granular product layer, this layer focuses on broader user journeys and meaningful milestones.

First Workspace Experience

The initial interaction is critical. For Slack, this could mean:

• Creating a new workspace
• Inviting the first team members
• Sending initial messages
• Achieving first team collaboration

The key is capturing that moment when a user transitions from a curious newcomer to an engaged participant.

Defining "Initial Value Achieved"

Initial value isn't a single, universal metric. In Slack's context, it might look like:

• Setting up a workspace
• Inviting at least 3 team members
• Sending 20+ messages within the first seven days
• Receiving responses from multiple team members

This multifaceted approach ensures we're measuring meaningful engagement, not just surface-level activity.

Value Repetition and User Progression

Sustained value is about consistent engagement. We track this by looking at:

• Repeated activities within a specific time window (e.g., 7 days)
• Consistent message volume
• Cross-channel interactions
• Sustained team collaboration

Churn and Risk Detection

The customer layer also helps identify potential dropoff points:

• Tracking periods of inactivity
• Monitoring workspace engagement trends
• Identifying users at risk of disengagement

By understanding these patterns, teams can proactively address user retention challenges.

The Strategic Perspective

The customer layer isn't just about tracking—it's about understanding user success. It provides a holistic view of how users progress, derive value, and potentially churn, transforming raw data into actionable insights.

Interaction Layer: The Catch-All Solution

The interaction layer is the Swiss Army knife of tracking—a flexible, lightweight approach to capturing granular user interactions without overwhelming your analytics infrastructure.

Product managers and UX designers often crave detailed insights into user behavior. How do users interact with specific buttons? Which icons do they click most? These questions can quickly lead to event tracking bloat if not managed carefully.

The Challenge of Granular Tracking

Traditional tracking approaches might create an event for every possible interaction:

• "Message Options Icon Clicked"
• "Emoji Button Pressed"
• "Thread Reply Button Touched"

The result? A massive, unmanageable collection of events that obscures more than it reveals.

The Elegant Solution

Enter the interaction layer—a single, flexible event type with rich properties:

• Event Name: "Element Clicked"
• Key Properties:
  • Element ID
  • Element Type
  • Location
  • Context Tags

This approach allows for comprehensive tracking with minimal complexity.

How It Works in Practice

Imagine a UX designer wants to understand icon usage in Slack. Instead of creating dozens of specific events, they can now:

• Track all icon interactions through a single event
• Add contextual properties
• Filter and analyze with surgical precision

The Philosophy of Restraint

The interaction layer embodies a core tracking principle: capture insights without creating noise. It provides flexibility without sacrificing data clarity.

Strategic Flexibility

By treating interactions as a catch-all layer with intelligent properties, teams can:

• Maintain a clean, minimal tracking plan
• Support ad-hoc analysis requests
• Keep the primary tracking layers focused on core product insights

The interaction layer isn't about tracking everything—it's about tracking what matters, when it matters.

Don't miss the upcoming episodes of this series and sign up for free to my newsletter (and support my work):

Building a Sustainable Foundation: Cost, Scale, and Evolution

Cost Considerations in Analytics

Analytics isn't free. Beyond the apparent subscription costs, there's a hidden economy of data tracking that can quickly escalate if you're not strategic.

Most teams underestimate the financial implications of their tracking approach. Event volume isn't just a technical challenge—it's a direct cost driver that can significantly impact your analytics budget.

The Hidden Price of Tracking

Consider the common culprits of ballooning analytics costs:

• Heartbeat events tracking user time in-app
• Automatic page view tracking
• Granular interaction events
• High-frequency data collection

A simple heartbeat event sent every 10 seconds can generate thousands of events per user monthly, dramatically increasing your tracking expenses.

Understanding Pricing Models

Analytics platforms typically charge based on:

• Monthly tracked users
• Total event volume
• Event quota limitations
• Data retention periods

The complexity lies in the nuanced ways these platforms meter and bill your usage.

Strategic Tracking Cost Management

Smart teams don't just track—they track strategically:

• Prioritize high-value events
• Implement sampling for high-frequency interactions
• Create explicit, meaningful events instead of generic tracking
• Regularly audit and prune unnecessary event collection

The Cost-Insight Balance

The goal isn't to minimize tracking, but to maximize meaningful insights while controlling infrastructure expenses. Every event should answer a specific business question.

Practical Considerations

Before implementing any tracking, consider:

• Projected event volume
• Potential cost implications
• Business value of collected insights
• Scalability of the tracking approach

By treating analytics as a strategic investment rather than an unlimited resource, teams can create powerful, cost-effective tracking infrastructures.

Scaling Your Tracking Plan

As products grow and evolve, tracking plans must become living, adaptable systems. What works for a startup of 10 users won't necessarily scale to an organization of 10,000.

Scaling isn't just about handling more data—it's about maintaining clarity, performance, and strategic insight as your product becomes more complex.

The Challenges of Growth

Product complexity increases exponentially. New features, user roles, and interaction patterns emerge, threatening to overwhelm your carefully designed tracking infrastructure.

The risk? Uncontrolled event proliferation that creates more confusion than insight. Each new feature can potentially multiply your tracking complexity geometrically.

Designing for Flexibility

A robust tracking plan anticipates growth by:

• Creating extensible entity frameworks (only pick new entities after serious considerations)
• Implementing consistent property patterns (but think about properties first when you need more data)
• Maintaining a clear, minimal core tracking approach

The goal is a tracking plan that can accommodate innovation without becoming a tangled mess of events.

Avoiding Tracking Debt

Technical debt has a tracking equivalent. Each hastily added event, each poorly defined property creates future complexity that becomes increasingly difficult to untangle.

Sustainable scaling requires discipline:

• Regular tracking plan reviews - this also means to check for events that can be sunset
• Clear governance processes
• Cross-functional collaboration

The Long-Term Perspective

Scaling isn't about tracking everything—it's about tracking what matters, in a way that remains coherent and valuable as your product transforms.

By treating your tracking plan as a strategic asset rather than a technical checklist, you create an analytics foundation that grows alongside your product's ambitions.

Analytics isn't a destination—it's a continuous journey of discovery. The tracking plan you build today is just the first step in understanding your product's true potential. By embracing a strategic, intentional approach to data collection, you transform analytics from a technical requirement into a powerful lens for product innovation.

Remember, the most valuable insights often come not from tracking everything, but from tracking what truly matters. Your data should tell a story, not create noise. Start small, think strategically, and let your tracking plan evolve as thoughtfully as your product itself.

The path to meaningful analytics begins with the courage to say no—to complexity, to unnecessary events, and to the myth that more data automatically means better insights.

This was part 1 in our series "One tracking plan a day" Season 1 - startup tools. Make sure you visit all other parts of the series:

• Notion - 27.01.25
• Superhuman - 29.01.25
• VimCal - 30.01.25
• Asana - 31.01.25
• Canva - 03.02.25
• Loom - 04.02.25
• Miro - 05.02.25
• Grammarly - 06.02.25
• Replit - 07.02.25
• Hubspot - 10.02.25
• Stripe - 11.02.25
• Zoom - 12.02.25
• Ghost - 13.02.25
• Amplitude - 17.02.25
• GSheets - 18.02.25
• Lightdash - 19.02.25
• Claude - 20.02.25
• Reconfigured - 21.02.25

If you like to generate your own tracking plans by using my book with Claude AI, get your copy here:

This work is based on the chapters about event data design in my book Analytics Implementation Workbook. There, you can read more details about the D3L framework.