suggest a template to update an existing event to add a new event property to the event payload to give us another dimension of user activities done with that key action make it easy to understand and break it down in to layers eg event name, event description, fire when:
Hi event, Please stand by as I search the Mixpanel knowledge base for an AI-powered answer. I normally take about 15 seconds or so. In case AI cannot answer your question, feel free to reach out to Mixpanel support at mixpanel.com/get-support. If you have follow-up questions for this thread, please tag me again with your question: @kapa.ai <follow-up question> 👋
Feel free to ask a follow-up question once I've answered by mentioning me with @kapa.ai
Here’s a lightweight, layered template you can copy into your tracking plan (Lexicon or docs) when you add a new event property to an existing event. It keeps the event action stable while adding context via properties, which aligns with Mixpanel best practices to use properties for detail instead of spawning new events.Layer 1 — Event - Event name (database): start_signup - Display name (UI): Start Signup - Event description: Fired when a user initiates the signup flow. - Fire when: User clicks any “Sign up” CTA on web or app. - Distinct ID: Required. Identifies the user performing the action. - Timestamp: Required. Time the action occurred. - Existing properties (unchanged): page_url, page_name, platform, referrer - New property being added: signup_platform - Notes: Keep one event for the action and use properties to describe variants (origin page, platform, etc.). [Best Practices; Tracking Plan]Layer 2 — New Property Definition - Property key (database): signup_platform - Display name: Signup Platform - Description: Indicates the authentication method or channel used to start signup. - Type: String (enumerated) - Allowed values: email, google_oauth, apple_oauth, github_oauth - Example values: google_oauth - Applies to events: start_signup - Why we’re adding it: To break down “Start Signup” by platform and compare performance across auth methods without creating multiple events. [Tracking Strategy; Event Analytics]Layer 3 — Instrumentation Notes - JavaScript SDK example:
mixpanel.track('Start Signup', {
page_name: 'pricing',
page_url: window.location.pathname,
platform: 'web',
referrer: document.referrer || '(direct)',
signup_platform: 'google_oauth' // NEW property
});
```LBKS Avoid using names with $ or mp prefixes, which are reserved. [[JS SDK: Sending events](https://docs.mixpanel.com/docs/tracking-methods/sdks/javascript#sending-events)]
- Timing (optional): If you want to time the signup start-to-complete flow, use time_event at start and track on completion to populate Duration. [[JS timing](https://docs.mixpanel.com/docs/tracking-methods/sdks/javascript#sending-events)]
- Super properties (optional): If a property should be on every event (e.g., user_tier), register as a super property—don’t duplicate into event names. [[Best Practices](https://docs.mixpanel.com/docs/data-structure/events-and-properties#best-practices)]LBKSLayer 4 — Governance (Lexicon)
- Update Lexicon:
- Event “Start Signup”: add Display Name, Description, Platforms, Tags (e.g., onboarding), Owners, and an image if helpful. [Lexicon Overview; Event details] - Property “Signup Platform”: add Description, Example Value, Status = Visible. [Lexicon Overview] - Naming: Use snake_case for database names; keep (Object Verb) format for events. [Best Practices]Layer 5 — Analysis Examples - Breakdown: Start Signup by Signup Platform to see which method is most used. - Funnel: Start Signup → Signed Up, broken down by Signup Platform. - Cohorts: Users who started signup with signup_platform = apple_oauth.Layer 6 — Change Management - Backward compatibility: The event name and existing properties remain unchanged; analytics using prior definitions continue to work. - Rollout plan: Add property in code, validate in a test environment, then monitor in Events and Lexicon for correct values and volume.Why this structure? - Keeps events as actions and uses properties for context, preventing data sprawl and making queries simpler. [Best Practices; Data democratization blog] - Aligns with the Mixpanel data model for clean, analysis-ready data. [Data Model; Events overview]
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Let me check the knowledge base for you again. One moment! 📚
Got it—you want a clear, reusable structure to document an analytics requirement (not code), so teams can align on what to track and why. Below is a concise template you can copy into your tracking plan or ARD. It follows Mixpanel guidance on creating a tracking plan, naming, and using properties for context. Citations included inline.Analytics Requirement Template1) Summary - Requirement name: - Owner/team: - Date/version: - Status: Proposed | In progress | Shipped - Related KPI/metric: - North Star/Framework link (if any): Why: Tie each requirement to a KPI and your analytics strategy before defining events. [Tracking plan; Best practices]2) Business Context - Problem/opportunity: - Decision this data will inform: - Success criteria (what will change if we learn X?): Why: Start from business goals and metrics, not just the app surface. [From metrics to events]3) User Flow Scope - User journey(s) impacted: - Key steps in flow: - Platforms: Web | iOS | Android | Backend | Other - Assumptions and out of scope: Why: Map KPIs to user flows and identify key actions in those flows. [Tracking plan methodology; Build strategy]4) Event Specification Document events as actions, using properties for context to avoid data sprawl.For each event: - Event name (database): snake_case, Object Verb (e.g., start_signup) - Display name (UI): - Event description: - Fire when: precise trigger (include edge cases) - Required fields: distinct_id, timestamp - Event properties (new or existing): - property_key: type, description, allowed values/examples - User properties (if needed): - Notes: super properties to include; identity considerationsWhy: Keep events at the right granularity and use properties for variants like page, platform, or type. [Events: best practices; Events overview]5) Identity & Session Handling - How to set distinct_id (anonymous vs logged-in) - When to alias/identify - Cross-device expectationsWhy: Proper ID management ensures events across devices roll up to the same user. [Identity guidance]6) Governance & Naming - Naming convention: snake_case; Object Verb for events - Data types and enums: define allowed values; avoid dynamic names - Null/empty rules: when to omit property vs send empty
- Privacy notes: any PI/PD to exclude or hashWhy: Consistency and data quality build trust and usability over time. [Methodology; Best practices]7) Analysis Expectations - Primary reports: Funnels, Retention, Insights, Cohorts - Breakdowns: which properties (e.g., source, platform) - Segmentation examples: - Cohort definitions needed: Why: Defining “how we’ll analyze it” ensures you collect the right properties. [What to track; Data model use cases]8) Instrumentation Plan - Tracking method: client | server | CDP | GTM | warehouse - SDKs/integrations involved: - Environments: dev/stage/prod - Rollout plan: test cases, sample payloads, validation stepsWhy: Choose tracking method early; server-side preferred for accuracy. [Choosing method; What to track]9) QA & Validation - Test scenarios and expected payloads - Event/property visibility in Lexicon - Data checks: volumes, value distributions, enum coverageWhy: Governance and maintenance keep data clean and usable. [Governance; Lexicon/data dictionary]10) Documentation & Lexicon Entries - Add/Update Lexicon: event display names, descriptions, property definitions, owners, tags - Link to tracking plan row(s) or sheetWhy: Keep a central, browseable data dictionary for self-serve analytics. [Lexicon; Data democratization tips]Optional: Quick example entry- Event: start_signup - Fire when: user clicks any signup CTA - Properties: - page_name (string): “/pricing”, “/home” - source (enum): organic, paid, referral - signup_platform (enum): email, google_oauth, apple_oauth - KPI linkage: Reach → new users acquired; Activation → signup completion rate - Primary analyses: Funnel start_signup → sign_up_completed by signup_platform - Identity: identify on login; persist distinct_id across devices - Naming: snake_case; no $ or mp_ prefixes
This structure mirrors Mixpanel’s recommended approach: define KPIs, map to flows, translate into events and properties, standardize naming, and document in a living tracking plan with Lexicon support. [Tracking-best-practices; Plan strategy; Events best practices]
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Let me check the knowledge base for you again. One moment! 📚
Short answer: No—Mixpanel’s Insights (and other) reports are powered by Mixpanel’s own event-analytics engine, not by running SQL in the background.Details: - Mixpanel uses a purpose-built event stream database called Arb to execute complex queries quickly and cheaply for interactive analysis, which is distinct from warehouse SQL. [Product vision; No trade-offs] - This design is why queries like funnels, retention, and segmentations load fast and scale to trillions of events without requiring users (or the system) to write SQL. [How we’re building] - When you need programmatic access to the same computed results you see in reports, Mixpanel provides a Query API rather than SQL. [Query API]If you connect warehouse data to Mixpanel via Warehouse Connectors, Mixpanel still analyzes it inside Arb—so you get the Mixpanel UI and speed without running SQL against your warehouse at query time. [Warehouse 2.0]
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Let me check the knowledge base for you again. One moment! 📚
Short answer: Mixpanel does not use SQL behind Insights reports. It runs queries on its own purpose-built event analytics engine (Arb) that powers Insights, Funnels, Retention, etc., enabling interactive speed without SQL. [How we’re building; Warehouse 2.0]Details: - Mixpanel’s architecture executes complex event queries on Arb rather than a warehouse SQL engine, which is why analyses like funnels and retention return quickly at large scale. [Product analytics vision; How we’re building] - If you need programmatic access to the same computed results you see in Insights, you use Mixpanel’s Query API endpoints (e.g., Insights, Funnels, Retention)—not SQL. [Exporting reports; Insights API] - Even when analyzing warehouse data via Warehouse Connectors, Mixpanel ingests and analyzes it in Mixpanel so you still get the same fast, self-serve experience without running SQL against your warehouse at query time. [Warehouse Connectors 2.0; Unlock all your data]
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Let me check the knowledge base for you again. One moment! 📚
Mixpanel is a product analytics platform that helps you track user interactions (events) in your web and mobile apps, analyze behavior with interactive reports, and visualize results to answer product questions quickly. It’s built around events, users, and properties, and offers core reports like Insights, Funnels, Retention, and Flows. [What is Mixpanel?; Reports overview]To extract data from the Insights report: - From the UI (all plans): export a report as CSV, PNG, or PDF via the report’s “…” menu → Export. CSV exports support up to 50,000 rows for certain chart types. [Exporting reports] - Via API (Growth/Enterprise): use the Query API to programmatically fetch the same formatted results you see in the app. For Insights, call the Insights Query endpoint and provide your project_id and the report’s bookmark_id found in the report URL. [Exporting reports; Insights API]You can also sync Insights (and other supported reports) into Google Sheets by pasting the report URL; the add-on parses required parameters and fetches the CSV using a service account. [Google Sheets export]
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.