You're on Mixpanel: It Shows What Users Do in Your Product. Data Workers Owns Whether the Warehouse Data Synced Into It Is Right
Already on Mixpanel? Data Workers checks the warehouse tables your Mirror syncs read, traces a broken Board to the dbt change behind it, routes the fix to a named approver and verifies the number, with a receipt.
Your product team lives in Mixpanel. PMs build Insights, Funnels, Retention and Flows reports, pin them to Boards, and run Experiments and Feature Flags from the same place. Lexicon holds the event and property definitions, Verified Data marks what to trust, and Business Context tells Mixpanel Agent (introduced June 25, 2026 as the next evolution of Spark) what your words mean. When a metric moves, the Agent runs Root Cause Analysis and hands back a Board of ranked segments. More of the events now come from the warehouse, not the SDK: billing, CRM and account events modelled in dbt and synced through Warehouse Connectors, often in Mirror mode so updates and deletes flow too. Mixpanel shows what users do in your product. Data Workers owns whether the warehouse data synced into it is right: it watches the tables your syncs read, traces a broken Board to the dbt change behind it, routes the fix to a named approver and verifies the number with a receipt.
Key takeaways
- •Mixpanel keeps its job. Reports, Boards, Lexicon, Experiments, Mixpanel Agent and Root Cause Analysis stay with the product and growth teams who own them.
- •Mirror copies the warehouse faithfully, deletes included. Mixpanel's docs say Mirror keeps Mixpanel "perfectly in sync" with the warehouse, including "deleting data that was removed from the warehouse." When a dbt change drops rows, history in Mixpanel goes with them on the next sync.
- •Data Workers watches the tables your syncs read. It holds each table's row count to a baseline your team records after every build, checks nulls and duplicate keys, knows which tables feed a Mirror sync, and raises the alarm before the next sync runs.
- •The fix lands where the cause is. Data Workers proposes the change to the dbt model as a diff for its owner, behind a named approval, and queues the rerun. Mixpanel's next sync brings the rows back.
- •Nothing written to Mixpanel, by design. Data Workers connects to Mixpanel over its API or MCP server today and changes nothing in it; its agents never call the Mixpanel MCP server.
Mixpanel shows what users do in your product. Data Workers owns whether the warehouse data synced into it is right.
Warehouse Connectors made Mixpanel a mirror of your modelled data. That is the point: one definition of "Plan Upgraded" in dbt, the same number in Mixpanel and in finance. It also means a mistake in a dbt model is now a mistake in Mixpanel, and in Mirror mode it can rewrite last year as easily as last night.
Here is a Monday night at a B2B software company running Mixpanel on BigQuery, with the app's PostgreSQL database replicated by Datastream and dbt Core run as Dagster assets (times ET). Account events (Trial Started, Plan Upgraded, Seat Added, Invoice Paid) are modelled in analytics.fct_account_events and reach Mixpanel through an hourly BigQuery Mirror sync. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Mon Sep 28, 16:20 | GitHub, dbt Core | To stop test accounts inflating activation, an analytics engineer merges a pull request that adds where not a.is_internal to fct_account_events, joined from stg_app__accounts. |
| (background) | PostgreSQL, Datastream, BigQuery | accounts.is_internal was added in a March 2025 migration with no backfill. The 3,912 accounts created before then carry NULL, and Datastream replicates the column as it is. not NULL is NULL, so the filter drops them too. |
| Tue 01:00 | Dagster, dbt Core, BigQuery | The nightly Dagster job materializes the dbt assets. fct_account_events rebuilds with 4.49M rows instead of 10.95M. The run is green. |
| 01:12 | Data Workers | monitor_metrics flags the row count the team records after each build: 4.49M against a baseline near 10.95M. run_quality_check, running on BigQuery with a service-account key, passes nulls and uniqueness on event_id: the rows left are clean, just far fewer. |
| 01:13 | Data Workers, Slack | blast_radius_analysis follows the table to two context-graph notes the team recorded: the reader "Mixpanel warehouse connector: account events" and "Mirror sync, hourly; rows removed here are removed from Mixpanel." It opens an incident, posts it to #data-incidents with send_slack_alert and asks the sync owner to pause the sync. The owner is asleep. |
| 02:00 | Mixpanel | The Mirror sync compares the table with its last snapshot and removes the 6.46M missing rows. Events for every account created before March 2025 disappear from reports back to 2023. |
| 07:45 | Mixpanel Board | The growth PM opens the Activation & Expansion Board. Q3 Plan Upgraded reads 541, down 58%; earlier quarters' trial-to-paid funnel has been rewritten. |
| 07:52 | Mixpanel Agent, Slack | Root Cause Analysis ranks accounts created before March 2025 as nearly the whole change, with high confidence, and suggests checking data quality: the right segment. The PM posts the RCA Board in #data; the on-call analytics engineer replies with the open incident, which already lists the sync and the Board. |
| 08:10 | Data Workers | diagnose_incident with trace_cross_platform_lineage walks the table back to stg_app__accounts. The dbt manifest diff against the previous build shows the new filter in the model. run_quality_check on stg_app__accounts.is_internal finds 3,912 nulls. get_incident_history finds no earlier case. |
| 08:25 | Data Workers, Spellbook | One plan: a diff that writes the filter as coalesce(a.is_internal, false) = false, defaults is_internal to false for legacy accounts in staging and adds a not_null test, then a Dagster rerun of the table and everything downstream. A note for the Mixpanel admin: the next sync re-inserts the rows, and Mixpanel bills Mirror inserts, updates and deletes. The blast radius and undo (revert the merge, rerun) travel with it. |
| 08:52 | Slack, Spellbook, Dagster | The analytics engineering lead gets the request in Slack, reviews it in Spellbook and approves; the dbt owner merges. Data Workers queues the approved Dagster run. |
| 09:20 | BigQuery, Data Workers | The run finishes. The recorded row count, 10.93M, sits inside the baseline; 22,000 events from real internal accounts stay out, as intended. run_quality_check finds no null is_internal. The team records Q3 Plan Upgraded at 1,284 in monitor_metrics as the source value. |
| 10:00 | Mixpanel | The next Mirror sync brings 6.44M rows back. |
| 10:15 | Mixpanel MCP, Claude | The PM asks Claude, connected to the Mixpanel MCP server in her own client, to rerun the Plan Upgraded report: 1,284, matching the recorded value. Data Workers closes the incident with the receipt (cause, diff, approver, rerun, checks). |
No tool failed. Datastream replicated what it was given, dbt built what the model said, Mirror did what Mirror promises, and Root Cause Analysis named the right segment. The break sat in a handoff nobody owned: a null nobody backfilled, and a filter that read "unknown" as "internal". Data Workers flagged it before the 02:00 sync, a named person approved the fix, and the Board matched the warehouse by mid-morning.
Afterwards the team moved the sync to Mixpanel's Trigger via API option, called by a Dagster step after the build and its tests, and put dbt pull requests touching fct_account_events through Data Workers' review, so the next change shows the Mixpanel sync in its blast radius before merge.
| Job | What Mixpanel does | What Data Workers does |
|---|---|---|
| The question | Reports, Boards, Experiments and Mixpanel Agent let PMs and analysts ask how the product is used | Gives the agents your team uses one governed view of each warehouse table: definition, lineage, owners and trust score |
| The definitions | Lexicon, Verified Data and Business Context say which events and metrics to trust | Holds the warehouse tables behind those events to the checks your team registers and the values it records |
| The sync | Warehouse Connectors replicate the table: Mirror carries inserts, updates and deletes | Knows which tables feed a sync and in what mode, and flags a drop against its baseline before the next sync runs |
| The break | Root Cause Analysis ranks the segments that moved and explains the change | Traces the change through lineage and the dbt manifest diff to the model that caused it, and lists everything it reaches |
| The fix | Owners edit reports, Boards and Lexicon | Proposes the upstream fix as a diff for its owner, routes it to a named approver and queues the approved rerun |
| The proof | The next sync and the Board show the new number | Re-checks the table, compares the recorded value and writes a receipt with cause, diff, approver and undo |
Why doesn't Mixpanel just do this itself?
Mixpanel made a clear bet: be the fastest way for a product team to understand behavior, and meet the data where it lives. Mirror is meant to replicate the warehouse exactly, so Mixpanel never second-guesses your dbt model; a connector that refused deletes would break every team that needs them. Root Cause Analysis ranks segments inside Mixpanel. Agentic Automations send a KPI digest, and the docs say the agent "cannot run additional queries, pull in other metrics, or take actions." The MCP server, launched March 24, 2026, reads and writes Mixpanel content under each user's own permissions and records every change in the audit log.
All of that protects Mixpanel. Tuesday's break never started there. It came from a Postgres migration, a dbt filter and a Dagster run, and the fix meant a dbt change, an approval and a rerun in systems Mixpanel does not own. That is a different product with different liability: cross-system context, blast radius, approvals, rollback and receipts across vendors. It is the product Data Workers is, built on the Mixpanel your product team already uses.
Every tool owns a slice. Data Workers covers the whole lifecycle
Mixpanel owns one slice outright: showing what users do in your product. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | Mixpanel | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Lexicon, Verified Data and Business Context describe events, properties and metrics for people and Mixpanel's AI. Data Workers keeps one governed context graph across every platform, joined to lineage, quality and owners. |
| Analytics & Insights | 8 | 9 | Mixpanel's home stage: Insights, Funnels, Retention, Flows, Boards, Experiments and Mixpanel Agent put behavior data in front of every PM. Data Workers answers through governed definitions and makes sure the tables under them are right. |
| Data Quality | 8 | 5 | Lexicon flags data quality issues, Drop Filters keep unwanted events out and AI merge suggestions clean up duplicates. Data Workers checks the tables behind your syncs for nulls and duplicate keys and holds row counts and headline values to a baseline. |
| Observability & Incidents | 8.5 | 4 | Alerts, anomaly detection and Root Cause Analysis explain a metric change by segment. Data Workers traces it to the system that caused it, proposes the fix and verifies it. |
| Pipelines & Ingestion | 8.5 | 5 | Warehouse Connectors sync from Snowflake, BigQuery, Databricks, Redshift and Postgres, and Data Pipelines export back out. Data Workers queues approved orchestrator reruns of the models those syncs read. |
| Schema & Migration | 8 | 3 | Mixpanel's docs advise against most schema changes on Mirror tables beyond adding nullable columns. Data Workers reviews dbt changes and their manifest diff and scopes the blast radius before merge. |
| Governance & Access | 8.5 | 5 | Project roles, Custom Roles and Data Views govern who sees what in Mixpanel. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 5 | SSO, PII classification in Lexicon and the audit log, now streamable to your own bucket, protect Mixpanel itself. Data Workers leaves a receipt on every data change and proposes masking for the owner to apply. |
| Cost / FinOps | 8 | 2 | The billing page itemizes Mirror updates and deletes. Data Workers reads Snowflake spend down to the dbt model and BigQuery spend as an account total from the Jobs API. |
| MLOps & Models | 7.5 | 3 | Agent Intelligence (beta) measures AI agents in production as product data. Data Workers checks the training and feature tables models read; their owners retrain. |
How Mixpanel and Data Workers work together
Your people stay where they are: Boards and Mixpanel Agent for product and growth, Claude Code or Cursor for engineers, Slack for alerts and approval requests. Spellbook Data Catalog (in preview) is where the data team looks: each proposed fix, its blast radius, approver and rollback. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm's 20+ specialist agents do the work, and the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember).
How Mixpanel enters the picture. Data Workers connects to Mixpanel over its API or MCP server today. Each sync enters the blast radius as a context-graph note on the table it reads, recording its mode and schedule; when a fix goes through a pull request, change review's lineage diff also reads any dbt exposures you declare. Data Workers writes nothing to Mixpanel: syncs, Lexicon, reports and Boards stay with their owners, and only the sync owner pauses or reruns a sync.
What Data Workers checks under each sync. run_quality_check covers nulls and uniqueness on id columns on BigQuery with a service-account key, and on Snowflake and Postgres; get_quality_score rolls them up. Uniqueness on event_id matters twice: Mixpanel's BigQuery docs warn that identical rows collapse into one in Mirror. A drop is caught by monitor_metrics, which holds the values your team records, such as rows per build or Q3 Plan Upgraded, against their baseline. explain_table returns a table's definition, lineage, documentation and trust score; trace_cross_platform_lineage and blast_radius_analysis follow it to its sources and every model and declared sync. Your data stays in your systems: the agents, warehouse credentials and model key run in your infrastructure, and the hosted Conductor sees workflow metadata only.
Setup over MCP today. Clone the open-source repository and add start-agent.sh entries to your client's MCP config, as the client setup docs show. On BigQuery, give Data Workers a service-account key so the table checks run live. The Mixpanel MCP server can sit next to it for your own work, with your client's tool approval on for its write tools; Data Workers' agents never call it.
// Example: .mcp.json for Claude Code. The mixpanel entry is your team's own
// connection to the hosted Mixpanel MCP server (OAuth via /mcp); Data Workers does not call it.
{
"mcpServers": {
"mixpanel": {
"type": "http",
"url": "https://mcp.mixpanel.com/mcp"
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
}
}
}List the tools with your client's own command (for example /mcp in Claude Code). A PM can then ask why Plan Upgraded fell and get the report from Mixpanel and the lineage, checks and open incident from Data Workers.
Where fixes go. Data Workers proposes the change as a diff for the owner to merge, usually a dbt model or staging fix, with its blast radius and undo step; it opens the pull request itself only when your team turns on the dbt GitHub pull-request target. After approval it queues the rerun through Dagster, Airflow or Prefect; Mixpanel syncs and Datastream replication stay with their owners.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Connected, not acting. PMs find broken Boards and ask in Slack.
- •L1 observe. Data Workers checks the tables behind your syncs and logs what it would do.
- •L2 propose. It drafts the upstream fix with its blast radius; a named owner approves in Spellbook before anything runs.
- •L3 act reversibly. For proven classes, such as queuing the downstream rerun after an approved staging fix, it acts, verifies and records the undo.
- •L4 autonomous. For a narrow class in one domain, it fixes, verifies and posts the receipt.
Approvals go to a named person; a request nobody answers expires and escalates, and never grants itself. No agent can promote its own work. See how approvals work, autonomy levels L0 to L4, is it safe to let AI agents change production data and where does our data go.
Around Mixpanel, see You're on Amplitude, You're on Segment for event collection, You're on Dagster for the orchestrator here and You're on Hex for your analysts' notebooks.
What changes for your team
Product teams on Mixpanel lose real time asking whether a moved metric is behavior, tracking or the warehouse. With Data Workers next to Mixpanel, six jobs run on autopilot at the level you set: incidents arrive with the cause, blast radius and a fix ready to approve; the tables behind every sync are held to their baselines after each build; BigQuery spend is read as an account total and Snowflake spend down to the dbt model; access requests become scoped, time-boxed grant proposals; every change behind a Mixpanel number carries its approver, diff, checks and undo; and warehouse moves under your syncs run in approved waves. Fewer "why did this Board change?" threads reach your data team, and the ones that do arrive with a cause.
Keep Mixpanel, or consolidate?
Keep Mixpanel if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most teams the answer is to keep Mixpanel: the reports, Boards, experiments and the Agent belong there. What teams consolidate is the tooling around it: a separate data-quality tool on the warehouse, a "check the Mixpanel sync" runbook nobody owns, and a spreadsheet of which table feeds which sync. If you are weighing building this yourself on the Mixpanel MCP server and your warehouse's, read build it ourselves with Claude Code and MCP servers: connecting servers is the easy part; cross-system context, approvals and rollback are the work. Data Workers vs data observability covers why an alert alone would not have fixed Tuesday.
The case for your CFO
The outcome: the numbers product and growth leaders read in Mixpanel match the warehouse and finance, and when an upstream change breaks them, the fix is approved by mid-morning.
The risk story: Data Workers changes nothing in Mixpanel. It checks the tables your syncs read and proposes upstream fixes as diffs; nothing runs until the named owner approves. Every change is verified and leaves a receipt: what broke, what changed, who approved it and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous, and an org-wide stop halts all autonomous dispatch. There is zero migration.
Why now: Mirror mode puts your dbt models directly behind Mixpanel, and Mixpanel Agent and the MCP server put those numbers in front of every PM in plain language. A wrong table now rewrites history in the product team's main tool.
The first win: the warehouse tables behind your Mixpanel syncs, each with a row-count baseline and declared with its sync mode, so a drop is caught before the next sync. What stays the same: your Mixpanel project, Lexicon and Boards, your BigQuery, dbt and Dagster, and your review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Mixpanel stays where product decisions get made; Data Workers makes sure what our warehouse syncs into it is right, and a named owner approves every fix with a receipt."
Getting started
Start with a pilot. Pick the Mixpanel sync behind a number people act on, connect Data Workers read-only to the warehouse (a service-account key on BigQuery), dbt and your orchestrator, record the sync in the context graph, and let Data Workers watch the tables behind it for a few weeks before the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers pause or rerun our Mixpanel syncs? No. Syncs stay with their Mixpanel owner. Data Workers flags the problem and routes a pause request to that owner.
We use Mirror mode. How do we keep a bad build from deleting history? Record each Mirror sync in the context graph so its table's blast radius includes Mixpanel, keep a row-count baseline in monitor_metrics, and consider Trigger via API so your orchestrator starts the sync only after the build and its tests pass. Mirror brings deleted rows back once the table is fixed; Mixpanel bills Mirror inserts, updates and deletes, and a workflow that drops and recreates a table counts every row.
Root Cause Analysis already explains metric changes. Why add this? Keep it. RCA tells you which segment moved. Data Workers tells you why the warehouse changed, proposes the fix where it lives and checks the result.
Do Data Workers' agents use the Mixpanel MCP server? No. Your team can run it side by side in the same client. Data Workers relies on its own warehouse, dbt and orchestrator connections.
What about events we send through the SDK, not the warehouse? Lexicon, Drop Filters and data quality issues govern those inside Mixpanel. Data Workers covers the warehouse side: the tables your syncs read and the models that build them.
Which warehouses does this cover? The table checks run natively on Snowflake and Postgres, and on BigQuery with a service-account key. Across 50+ connectors, Data Workers also works natively with dbt, Airflow, Dagster and Prefect; what integrations Data Workers supports lists what each one reads and changes.
Sources
- •Mixpanel, Warehouse Connectors (Mirror, Append, Full and One-Time modes; Mirror syncs updates and deletes; Mirror on Snowflake, BigQuery, Databricks and Redshift, connectors also for Postgres; hourly, daily, weekly or Trigger via API; Mirror bills inserts, updates and deletes, drop-and-recreate counts every row), https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors (checked Oct 3, 2026)
- •Mixpanel, BigQuery warehouse connector (Mirror via table snapshots and row checksums; tables, no views; identical rows collapse; schema change guidance), https://docs.mixpanel.com/docs/tracking-methods/warehouse-connectors/bigquery (checked Oct 3, 2026)
- •Mixpanel, MCP Server (hosted US, EU and IN endpoints; OAuth and service accounts in beta; read and write tools; Experiments and Feature Flags in beta; audit log), https://docs.mixpanel.com/docs/features/mcp (checked Oct 3, 2026)
- •Mixpanel, Mixpanel Agent (capabilities, Verified Mode, Business Context, next evolution of Spark), https://docs.mixpanel.com/docs/mixpanel-agent (checked Oct 3, 2026)
- •Mixpanel, Root Cause Analysis, https://docs.mixpanel.com/docs/root-cause-analysis (checked Oct 3, 2026)
- •Mixpanel, Agentic Automations (KPI Monitoring; the agent cannot take actions), https://docs.mixpanel.com/docs/agentic-automations (checked Oct 3, 2026)
- •Mixpanel, Lexicon (Verified Data, data governance), https://docs.mixpanel.com/docs/data-governance/lexicon (checked Oct 3, 2026)
- •Mixpanel, Changelog (Custom Roles Apr 14, 2026; Mixpanel MCP Mar 24, 2026; Postgres Connector GA Apr 10; Drop Filters and Verified Cohorts May 11; Mixpanel Agent Jun 25; new MCP tools GA Jul 20; AI merge suggestions Jul 28; Claude Code plugin Aug 24; Agent Board editing Sep 9; Audit Log Streaming Sep 28; Agent Intelligence beta Oct 1), https://docs.mixpanel.com/changelogs (checked Oct 3, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)