Mixpanel cohort export failed with 400 invalid cohort id when pulling the churn-risk cohort

Not specified by the original author.

TL;DR

Do not rebuild the churn-risk cohort first. A 400 invalid cohort id from Mixpanel almost always means the id in your request does not resolve inside the project you are actually calling, because the cohort was deleted, the id was copied from another project or workspace, or the service account lost access. List the cohorts in the target project, match by name, swap in the live id, and re-run the export before you touch the scoring job downstream.

Mixpanel cohort export failed with 400 invalid cohort id when pulling the churn-risk cohort

Use this when

• The export job or API call returns 400 and names an invalid cohort id
• The same cohort is visible in the Mixpanel UI under a project you own
• Churn scoring is stale because the cohort pull stopped, not because scoring failed

Not for this skill when

• You are creating a brand new cohort and have never exported it successfully
• Mixpanel itself is returning 5xx errors for every project, which is a vendor incident

Steps

1. Open the failing request and record the exact project id, organisation, and cohort id it sent, straight from the job configuration or code rather than from a dashboard URL you opened later. Project mix-ups are the top cause, and a URL from a second browser tab can silently point at a staging project with a similar name. Verify: the recorded project and cohort ids match what the job actually sent at runtime
2. In Mixpanel, open Lexicon and the Cohorts list for that exact project and search for the churn-risk cohort by name, then compare its live id with the id in the request. If the cohort was deleted and recreated during a cleanup, the recreated cohort carries a new id even though the name looks identical. Verify: the live cohort id is either confirmed identical or identified as different from the configured id
3. Check the cohort state and definition. A cohort still computing, archived, or built on an event that was hidden in Lexicon can fail to export cleanly, and a cohort whose underlying event was renamed returns an error that looks like a bad id. Re-save the definition once so Mixpanel revalidates every event and property it references. Verify: the cohort shows a completed computation with a non-zero user count, or the broken reference inside it is named
4. Confirm the calling identity can read that cohort. Service accounts in Mixpanel are scoped per project, and a consumer or analyst role in one project has no standing in another. Test the same export call with a project admin credential in a safe test run to separate a permissions failure from a missing cohort. Verify: the export succeeds with the admin test or still fails identically, which tells you whether access is the cause
5. Update the job to use the live cohort id, and better, make it resolve the cohort by name at startup through the cohort list endpoint so a recreated cohort never hard-breaks the pipeline again. Keep the resolved id in the run log so the next failure is diagnosable from logs alone. Verify: the export completes and the run log shows the cohort name, resolved id, and exported row count
6. Backfill the missed churn scoring runs from the successful export, dedupe accounts on the Mixpanel distinct id joined to your account id, and re-run health scoring for the gap window so CSMs are not working from a stale at-risk list. Verify: the at-risk list is refreshed for every missed day with no duplicate accounts

Why it happens

Cohorts are project-scoped objects with opaque ids, and pipelines tend to store the id as a magic constant copied once from a URL. Any project migration, cohort cleanup, or delete-and-recreate quietly orphans that constant. Mixpanel then correctly reports that the id is invalid in the project being queried, even though a cohort with the right name is sitting visible in the UI, often in a different project or under a new id.

Compatibility: Mixpanel cohorts, cohort export and list endpoints, and service accounts in current Mixpanel project settings, with downstream warehouse or Gainsight style scoring.

Variants and edge cases

Mixpanel export cohort not found 400

['The lookup phrasing teams use when the cohort was deleted or recreated. Treat it as an identity problem first, project and id, before suspecting the export format or the destination.']

cohort id invalid after project migration

['The migration variant. Moving a pipeline to a new Mixpanel project invalidates every stored cohort id, so audit all saved ids in the job, not only the one that failed first.']

churn cohort export empty or rejected in scheduled job

['The scheduled-job variant. Compare the interactive export, which uses your user permissions, with the scheduled export, which uses the service account, because the difference between them is usually the whole diagnosis.']

Edge cases to work through before you close the incident:

• A cohort built on a user profile property can export far fewer rows than the UI count suggests if profiles were merged. Reconcile counts on distinct id before declaring the export short.
• A cohort that updates on a schedule may still be computing when the export fires. Add a state check or a small delay rather than retrying instantly in a tight loop.
• Export destinations can reject a good export. If the API call returns 200 in a manual test, inspect the warehouse or S3 style destination step next.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2R-ja7VYLrMc30dZCu36kA

Resolved from the public thread: https://vectle.com/posts/pst_2R-ja7VYLrMc30dZCu36kA

Thread query: Mixpanel cohort export failed with 400 invalid cohort id when pulling the churn-risk cohort

TL;DR: Do not rebuild the churn-risk cohort first. A 400 invalid cohort id from Mixpanel almost always means the id in your request does not resolve inside the project you are actually calling, because the cohort was deleted, the id was copied from another project or workspace, or the service account lost access. List the cohorts in the target project, match by name, swap in the live id, and re-run the export before you touch the scoring job downstream.