kapa.ai

You're describing a situation where your project now has two copies of the same events — the original exported data (with project timezone timestamps) and the re-imported data (also with project timezone timestamps, unconverted). Even though they share the same $insert_id, the different timestamps make Mixpanel treat them as distinct events, bypassing deduplication.

Mixpanel's deduplication uses a combination of event_name, time, distinct_id, and insert_id together. [Common SQL Queries] If the time value differs between the original and re-imported event, they are treated as different events even with the same $insert_id.

The recommended approach is to delete the problematic imported data and re-import it correctly:

Use Mixpanel's Data Deletion tool to remove the incorrectly imported events. You can target them using event property filters to isolate only the duplicates. [Deleting Problematic Data]

Note the eligibility requirements for Data Deletion:

Data Deletion first performs a soft delete (immediately hidden) before a hard delete (permanently removed from servers). You must wait for the hard delete to complete before re-importing.

When re-importing:

"If you re-import data while the data is soft deleted with the same $insert_id, our deduplication systems may keep the old (deleted) event and toss the new event." [Data Clean-Up]

If your data exceeds the Data Deletion eligibility limits, you may need to contact Mixpanel Support directly for assistance.

You're correct about the issue. For projects created before January 1, 2023, event timestamps are stored in the project's local timezone (not UTC). When you export this data and import it directly into a new project (which stores data in UTC), the timestamps will be misinterpreted, causing events to appear at wrong times — and potentially doubling up counts across day boundaries. Here's how to fix it:

Before importing into the new project, you must convert the exported timestamps from your old project's timezone to UTC.

"When you export raw event data, the timestamps on those events will be in the timezone of your project. Before importing into your new project, convert those timestamps to UTC so that they are correctly transformed to the timezone of the new project." [Merge Projects]

If you're re-importing data that was previously soft-deleted or already partially imported, regenerate the $insert_id for each event. If you reuse the same $insert_id, Mixpanel's deduplication system may discard your new (corrected) events in favor of the old ones. [Data Clean-Up]

When importing, ensure every event has a unique $insert_id. This is Mixpanel's primary mechanism to prevent duplicate events from being stored. [Backfilling Historical Data]

If you're using the open-source mixpanel-utils library, you can specify the timezone offset directly during import to handle the conversion automatically:

mputils.import_events('event_export.txt', timezone_offset=-8)

The timezone_offset parameter should reflect your old project's UTC offset (e.g., -8 for PST). [mixpanel-utils]

I'm sorry, but the knowledge sources provided do not contain enough information about the Cross-product analytics feature mentioned on Mixpanel's pricing page to give you a confident, accurate answer about what it includes or whether it would solve your multi-project reporting needs. I'd recommend:

There are a few approaches depending on your goals:

The most straightforward way to get unified reports is to merge your separate projects into one. This involves:

[Project Migration] [Merge Projects] Once consolidated, you can differentiate app-specific behavior using properties like Operating System or custom app identifiers, rather than needing separate projects. [Multiple Production Projects]

If you consolidate into one project but want each team to see only their app's data, Data Views let you create scoped "mini-projects" within a single Mixpanel project — e.g., one Data View per app. This avoids clutter while enabling cross-app analysis when needed. [Data Views]

If you want to keep separate projects but still get compiled answers across them, Mixpanel's MCP server allows an AI client to query multiple projects in a single prompt. However, this doesn't produce a native Mixpanel report — it's more of an AI-assisted synthesis. [Mixpanel MCP]

The knowledge sources don't explicitly mention a feature called "cross-product analytics" as a standalone product. The closest relevant features are Group Analytics (for B2B account-level analysis, available as an add-on on Growth/Enterprise plans) and Data Views for governance across teams/products. [Group Analytics]

MRR tracking via Revenue Analytics requires a warehouse connector integration and works within a single project. If MRR data lives in your warehouse, you can sync it into a consolidated Mixpanel project. [Revenue Analytics]

Bottom line: The cleanest path to unified DAU/MRR reporting across all apps is to consolidate your projects into one, using Data Views to maintain per-app scoping where needed.

The knowledge sources don't explicitly cover combining URL/landing page data with the "Attributed by" breakdown in a single native report, but here's what can be inferred from the available documentation:

The Attributed by... computed property works by evaluating UTM parameters (e.g., utm_source, utm_medium, utm_campaign) across touchpoints in a lookback window. It doesn't natively surface the originating URL or landing page as part of that breakdown. [Attribution docs]

1. Track the landing page URL as an event property If you're using the Mixpanel JavaScript SDK, the referrer and current URL are available client-side. You can explicitly track the landing page URL (e.g., $current_url or a custom landing_page property) on your first event or as a super property. For server-side implementations, you'd need to extract this manually from the request. [Server-side best practices] 2. Use $referrer / $referring_domain properties Mixpanel's JS SDK automatically tracks Initial Referrer and Initial Referring Domain — the URL a user came from before arriving at your site. These are stored in the Mixpanel cookie on first visit and appended to events. You could use these as a breakdown in an Insights or Funnels report filtered to your "Funding Application Submitted" event. [Web attribution] 3. Break down by URL/landing page separately from Attribution Since Attributed by... can only be used as a breakdown (not combined with a second breakdown in the same dimension), a practical workaround is:

4. Use Flows to trace the path The Flows report can show you what events (including page views, if tracked) users performed before submitting a Funding Application. If you track page views as events with a URL property, you can filter by your attribution segment and trace back to the originating landing page. [Flows report]

The most robust solution is to ensure your landing page URL is tracked as an event property on every touchpoint event (not just the conversion event). This way, you can use it as a breakdown alongside your UTM-based attribution analysis. If you're using the JS SDK, $current_url may already be captured automatically on page view events.

⚠️ Note: The Attributed by... breakdown itself cannot be combined with a URL breakdown in the same report layer — you'd need to use filters and separate breakdowns as described above.

Yes, this is possible on the Growth plan! Cohort Sync is available to paid plan customers, and you can configure a recurring (dynamic) sync to automatically export your cohort's distinct IDs to an external tool. [Cohort Sync Overview]

First, connect Mixpanel to your destination:

The sync frequency depends on the specific integration. Most integrations (e.g., Appcues, Taplytics, Chameleon, Kameleoon) update every two hours, while some like Iterable and mParticle sync every 15 minutes. [Cohort Sync Integrations] The knowledge sources do not explicitly confirm a daily cadence as a user-selectable option for most integrations — the recurring syncs appear to run more frequently (every 2 hours or 15 minutes) rather than exactly once per day. If a strict daily cadence is required, you may want to verify this with the specific integration's documentation or use a Custom Webhook where you have more control over how you process incoming data. [Cohort Sync Overview]

By default, Cohort Sync exports the following user properties, including $distinct_id:

$distinct_id
$first_name
$last_name
$partner_user_id
$email
$phone

Note that each project is limited to 60 dynamic (recurring) cohort syncs across all destinations, and each cohort is limited to 10 million users. [Cohort Sync Overview]

Cohort Sync is restricted to paid plans only. There are two limitations that apply to Free plan users:

To use Cohort Sync and export cohorts to external destinations like CRMs or marketing tools (e.g., Braze, Mailchimp, Salesforce Marketing Cloud, etc.), you would need to upgrade to a Growth or Enterprise plan. [Cohort Sync Integrations]

Sorry Khayalethu L., I don't have permission to access files in this workspace. Please ask a workspace admin to reinstall the kapa.ai bot to grant the required permission.

You can create this cohort using the Cohort Builder in Mixpanel. Here's how:

This will give you all users who triggered User Created but never submitted an application. [Cohort Builder] Alternatively, you can build this cohort directly from a Funnels report:

Both approaches will produce the same result. The Cohort Builder approach is more flexible if you want to set specific time windows or frequency thresholds.

The difference you're seeing is explained by what each view actually displays. Metric view shows the overall weighted average across all cohorts for Week 1 retention. It averages the Week 1 retention rate across all completed cohort buckets, weighted by cohort size. [Metric view FAQ] Retention Curve view shows the Average row at the bottom of the heatmap table, which is also a weighted average — but it only includes completed buckets (those without an asterisk *). Incomplete buckets, where the time window hasn't fully elapsed yet, are excluded from this calculation. [Average row calculation] The discrepancy likely comes from one or more of these factors:

To reconcile the two, try enabling the Cohortize option under the Advanced menu in the Metric view. This should bring it closer to what you see in the Retention Curve's average row.