Data Ingestion Best Practices
This guide covers best practices for implementing scalable, maintainable tracking in Mixpanel. Follow these guidelines to ensure high-quality data and avoid common pitfalls.Create a Tracking Plan
A tracking plan is a centralized document that defines what data you’re collecting and why. It should:- Define your business goals and KPIs
- Outline events, event properties, and user profile properties
- Serve as the source of truth for your implementation
- Be continuously updated as your product evolves
- Be shared across product, marketing, and engineering teams
Tracking Plan Template
Download our tracking plan template to get started
Tracking Plan Methodology
Define KPIs
Start with your top KPIs and metrics that measure success. Don’t try to track everything - prioritize what matters most.
Map User Flows
Map each KPI to the user actions that influence it. Consider different paths users take to achieve outcomes.
Translate to Events
Break down user flows into specific events and properties. Each event should represent a meaningful user action.
Industry-Specific Templates
Mixpanel provides tracking plan templates for different industries:Server-Side Best Practices
Server-side tracking is more reliable than client-side tracking. Follow these practices to get the most value:Track Browser, Device, and OS
Mixpanel’s web and mobile SDKs automatically parse theUser-Agent header. For server-side tracking, you need to do this manually:
Track UTM Parameters and Referrer
Capture marketing attribution data by parsing URL parameters and headers:Track Page Views Consistently
For server-side implementations:- Use a single event name for all page views (e.g., “Page Viewed”)
- Track page name as a property, not as different events
- Fire page view events only on successful responses
- Handle both anonymous and identified users
- Parse headers and URL for analytics properties
Handle Geolocation
By default, Mixpanel uses the IP address of the request. For server-side tracking:Identity Management
Server-Side Identity Management
Server-side SDKs don’t generate IDs automatically. You’re responsible for:- Generating unique IDs for users
- Maintaining ID persistence across requests
- Linking anonymous users to identified users
Best Practices for IDs
Use consistent distinct_id format
Use consistent distinct_id format
- Choose a format and stick with it (e.g., database IDs, UUIDs)
- Never change a user’s distinct_id after it’s set
- Use the same ID across all platforms (web, mobile, server)
Handle anonymous users properly
Handle anonymous users properly
For anonymous users:
- Generate a unique device_id on first visit
- Store it in a cookie or local storage
- Use it as distinct_id until user identifies
- Call $identify to merge when user signs up
Merge identities carefully
Merge identities carefully
When a user signs up or logs in:Only merge once per user to avoid data issues.
Event Design Best Practices
Naming Conventions
Good Examples:- “Video Played”
- “Purchase Completed”
- “Page Viewed”
- “Form Submitted”
- “play_video” (inconsistent format)
- “user clicked the signup button” (too verbose)
- “event_123” (meaningless)
Property Best Practices
Use consistent property names
Use consistent property names
- Choose a naming convention (snake_case or camelCase) and stick with it
- Use the same property name across all events when referring to the same thing
- Document your naming conventions in your tracking plan
Use appropriate data types
Use appropriate data types
- Strings: Names, categories, IDs
- Numbers: Counts, prices, durations
- Booleans: Yes/no flags
- Dates: ISO 8601 format or Unix timestamps
Keep property values consistent
Keep property values consistent
Use consistent values to make filtering and segmentation easier:
Avoid PII in properties
Avoid PII in properties
Don’t send personally identifiable information:
- ❌ Full names, addresses, phone numbers
- ❌ Credit card numbers, SSNs
- ❌ Passwords or tokens
- ✅ User IDs, anonymized identifiers
- ✅ Email (if properly hashed)
Debugging Your Implementation
Create a Test Project
Always create a separate development project to validate your implementation without contaminating production data.Use Events View
The Events view shows a live feed of incoming events:- Fire test events from your own device
- Search by your distinct_id or device_id
- Expand events to inspect all properties
- Verify event and property names are correct
- Check that property values have correct data types
Enable Debug Mode
Most client-side SDKs support debug mode:Check Browser Console (Web)
For web implementations:- Enable debug mode
- Open browser developer console
- Go to Network > Fetch/XHR tab
- Perform actions that trigger events
- Look for requests to Mixpanel API:
- US:
api.mixpanel.com/track - EU:
api-eu.mixpanel.com/track - India:
api-in.mixpanel.com/track
- US:
- Verify the token and payload are correct
Common Issues
Events not appearing
Events not appearing
Possible causes:
- Wrong project token
- Wrong API endpoint for data residency
- Events older than 5 days sent to
/track(use/importinstead) - Ad-blockers (for client-side tracking)
- Events are hidden in Lexicon
- Verify project token in Project Settings
- Check that you’re using the correct API endpoint
- For old events, use the
/importendpoint - Check Lexicon for hidden events
Wrong geolocation
Wrong geolocation
Cause: Server-side tracking uses the server’s IP by defaultSolution: Pass the client’s IP:
Duplicate events
Duplicate events
Cause: Events sent multiple times or from multiple sourcesSolution: Use
$insert_id to deduplicate:Mobile events delayed
Mobile events delayed
Cause: Mobile SDKs batch events and flush periodicallySolution:
- iOS: Flushes every 60 seconds or when app backgrounds
- Android: Flushes every 60 seconds or after 40 events
- Call
flush()manually for important events
Performance & Reliability
Use Batching
Batch multiple events in a single request:Implement Retry Logic
Queue Events
For high-volume applications, queue events and send asynchronously:Security Best Practices
- ✅ Use project token in web/mobile apps
- ✅ Use API secret only on servers
- ❌ Don’t commit API secrets to version control
- ❌ Don’t send sensitive data (PII, passwords, etc.)
Data Quality Checklist
Before launching:- Created a tracking plan
- Tested in a development project
- Verified events appear in Events view
- Checked event and property names follow conventions
- Confirmed property data types are correct
- Tested identity merge for signup/login flows
- Verified geolocation is accurate
- Set up separate dev/staging/production projects
- Documented implementation for team
- No PII or sensitive data in events
Next Steps
ID Management
Learn advanced identity management strategies
Debugging Guide
Detailed debugging and troubleshooting guide