🔎 The Problem: Drowning in Data, Starving for Insights

For six months, our event tracking was broken. We had tons of data but no clarity—making even simple analyses painfully slow and unreliable. Teams struggled to get basic product insights, and analysts were stuck in reactive reporting mode, drowning in SQL requests.

Four Major Problems We Faced

1️⃣ Google Analytics Was a Temporary Fix That Became a Problem

• We didn’t have backend tracking for logins or product events, so we defaulted to Google Analytics (GA)—even though it wasn’t built for product analytics.
• Stakeholders couldn’t use GA—funnels were impossible to build, and reports weren’t customizable.
• We were tracking engagement using front-end events with no connection to actual product usage.

2️⃣ Event Tracking Was a Mess—No Strategy, Just Noise

• Events were inconsistent, redundant, and lacked a clear structure.
• The engagement team constantly asked:
  • Which feature drives the most retention?
  • Who are our most engaged demographics?
  • How do we enable cross-feature conversions?
• We couldn’t answer these questions because the tracking was unreliable.

3️⃣ Analysts Were Stuck in a Cycle of Ad-Hoc Requests

• Every team had different, conflicting definitions for key metrics (e.g., “active users” had five different definitions).
• 80% of analyst time was spent pulling SQL queries for the same repeated questions.
• No self-serve dashboards existed, so every data request required manual effort.

4️⃣ No Systematic Way to Implement or Validate Tracking

• Engineers had no way to test events before deploying them.
• Tracking varied across platforms (iOS, Android, Web)—meaning event accuracy was inconsistent.
• Without a structured approach, event bloat made querying slow and difficult.

💡 We knew we had to fix this—or stay stuck in reactive mode forever.

👥 The Cross-Functional Team That Made It Happen

Fixing analytics wasn’t a solo effort. This was a cross-functional collaboration between analytics, product, and engineering.

Core Analytics Team

✅ 3 Analysts—designed the event framework, validated tracking.
✅ 1 Data PM—aligned stakeholders, managed execution.
✅ 1 Engineering Manager—ensured engineering feasibility & observability.

Product Teams Involved (10 teams)

✅ PMs—helped define key product interactions and business questions.
✅ Engineering Managers—oversaw roadmap integration.
✅ Frontend Engineers (iOS, Android, Web)—implemented & tested tracking.

Together, we rebuilt event tracking from scratch, aligned 10 product teams, and implemented a scalable framework.

🔑 Key Outcomes

✅ 100+ high-value events instrumented with a structured, scalable tracking framework.
✅ 40% reduction in ad-hoc data requests, freeing up analysts for strategic work.
✅ 10X faster insights delivery, enabling teams to make data-driven decisions without delays.
✅ 3X increase in Amplitude adoption, empowering PMs and engineers with self-serve analytics.
✅ Cross-functional collaboration across 10 product teams and engineering for seamless implementation.

‍

🔨 The Fix: A 6-Phase Plan to Build Scalable Event Analytics

🛑 Phase 1: Stop the Chaos (Weeks 1-2)

What We Did

• Paused all non-critical data requests—only critical business metrics were allowed.
• Told stakeholders that our #1 priority was fixing product analytics—no more ad-hoc reports.
• VP approval required for any new data request, forcing teams to articulate their needs.
• Redirected analysts to work on designing event tracking instead of SQL requests.
• Forced structured data requests—no more last-minute, vague, or rushed asks.

✅ Outcomes

📉 40% reduction in data requests within a month.
⏳ Analysts fully focused on setting up scalable event tracking.
💡 Teams learned to prioritize and structure their data needs.

🤝 Phase 2: Stakeholder Alignment (Weeks 3-4)

What We Did

• Interviewed PMs, Engineers, and Growth teams to understand their pain points.
• Identified the five key product questions analytics needed to answer.
• Standardized key metrics—so “active users” meant the same thing for everyone.
• Created a roadmap for fixing analytics and aligning teams.

✅ Outcomes

📊 One single source of truth for core KPIs.
🎯 Clear alignment across teams on what data mattered most.
🚀 Analytics roadmap approved & prioritized across product and engineering.

🔍 Phase 3: Vendor Evaluation & Selection (Month 2)

What We Needed in a Solution

• Observability—Engineers needed to test tracking before deployment.
• Multi-destination streaming—Send data to Amplitude, Redshift, and other platforms.
• Ease of use for stakeholders—PMs, engineers, and analysts should own and use the tool.
• Self-serve behavioral insights—Easy funnel building, user journeys, and cohort analysis without analysts.

What We Did

• Evaluated multiple vendors (Mixpanel, Amplitude, Heap, PostHog).
• Chose Segment + Amplitude for event tracking & behavioral analytics.
• Set up a scalable data pipeline with proper validation & monitoring.

✅ Outcomes

⚡ 3X faster insights with Amplitude vs. SQL queries.
📊 Self-serve dashboards enabled teams to answer their own questions.
📉 Eliminated Google Analytics as a crutch.

🎨 Phase 4: Event Design (Month 3)

What We Did

• Analyzed the entire app and identified core user interactions.
• Designed a simple, scalable event structure with only two event types:
  • Screen Loaded
  • Button Clicked
• Mapped all existing GA events to this format to reduce event overload.
• Standardized event properties:
  • Introduced hierarchical properties (product_area, screen_name).
  • Made these properties mandatory for every event.

✅ Outcomes

📌 One unified event framework across the app.
📝 Clear implementation guidelines for PMs and engineers.
📊 Fewer events, more actionable insights.

🚀 Phase 5: Implementation (Months 4-6)

What We Did

• Met with teams feature-wise (PMs, Engineers, EMs)—explained the scope & framework.
• Got commitment by adding tracking implementation to their roadmaps.
• Split 10 product areas across 3 analysts—each analyst designed events for their area.
• Engineers implemented & unit-tested events, analysts did end-to-end testing across platforms.
• Built charts in Amplitude, and PMs validated them.

✅ Outcomes

📊 100+ events instrumented successfully.
🔍 PMs & engineers became self-sufficient in tracking.
🚀 Product teams gained visibility into real user behavior for the first time.

📚 Phase 6: Training & Adoption (Month 6)

What We Did

• Built a Metric Catalog documenting every KPI, event, and owner.
• Trained PMs, Engineers, and Analysts on using Amplitude.
• Held bi-weekly office hours & created a Slack support channel.

✅ Outcomes

📈 Amplitude adoption increased 2X in two months.
🎯 PMs started using data independently in product reviews.
📉 Ad-hoc SQL requests dropped by 40% as teams relied more on self-serve analytics.

Final Results: Event Analytics That Actually Works

✅ 40% reduction in ad-hoc SQL requests.
✅ 100+ structured, high-value events implemented.
✅ 10X faster insights delivery.

📩 Struggling with messy event tracking? Let’s fix it.

‍