Every analytics team I’ve worked with has the same recurring problem. Someone is supposed to check the key metrics every Monday morning. Sometimes they do, sometimes they’re in meetings, sometimes they’re on leave. The check slips. A metric that started drifting on Wednesday gets noticed the following Monday — a full week later. By then, whatever caused the shift has been running for seven days and untangling it takes three times as long as it would have if someone had caught it on Thursday.
The solution most teams reach for is a manual dashboard they bookmark and check inconsistently, or an alert that fires too often until everyone starts ignoring it, or a weekly Slack message that someone writes manually until they stop writing it.
Mixpanel’s Agentic Automations take a different approach. Instead of showing you a chart and expecting you to interpret it, or firing an alert and leaving you to figure out what it means, a KPI Monitor watches a metric on a schedule you define and delivers a digest — a short summary of what changed, what the agent considers notable, and why — directly to Slack or email. The monitoring and the first layer of interpretation both happen automatically.
Here’s how to set one up and how to think about using it well.
What Agentic Automations Actually Are
Agentic Automations are sub-agents of Mixpanel’s AI layer that you configure once and that then run recurring analysis on your behalf. The first and currently available type is KPI Monitoring. Research, event-triggered, and data governance automations are in development — reach out to your account manager if you want early access to those.
A KPI Monitor does three things on a schedule: runs a query against a metric you’ve defined, compares the result against baseline, and delivers a written digest summarizing what happened and what looks significant. You don’t pull the report. It comes to you.
The limits by plan are worth knowing before you start building: Free accounts get 5 automations per user per project, Growth accounts get 10, and Enterprise accounts get 20. KPI Monitors currently support Insights-style event metrics only — funnel and retention metrics aren’t supported yet. Delivery goes to Slack or email.
Before You Start: Check That Mixpanel AI Is Enabled
The Automation button appears in the side navigation under the Create New flow. If you don’t see it, your organization may not have Mixpanel AI features enabled. The Mixpanel Agent FAQ in the documentation covers how to enable AI features in your organization settings — check there first before assuming the feature isn’t available on your plan.
If you’re on a plan that supports automations and AI is enabled, you’ll see the option. If it’s still missing after enabling AI, contact your account manager.
Step 1: Launch the Automation Creation Workflow
Click the + Create New button in your side navigation bar. At the bottom of the Analysis section, click Automation. This opens the KPI Monitor configuration flow.
Step 2: Choose Your Delivery Cadence
The first configuration decision is how often the agent runs and delivers a digest. The options are daily, weekly, or monthly.
Weekly is the right default for most teams and most metrics. It gives you enough frequency to catch meaningful shifts before they compound, without creating digest fatigue. If you set everything to daily, people stop reading the digests within two weeks — the same thing that happens to alert systems that fire too often.
Daily makes sense for a small number of genuinely time-sensitive metrics — something like active sessions or payment failures where a 24-hour delay in noticing a problem has real consequences. Monthly makes sense for metrics where the meaningful signal only emerges over longer periods — something like feature adoption rates or cohort retention where weekly noise obscures the trend.
The rule I use: if you wouldn’t manually check this metric more than once a week, don’t set it to daily. Match the cadence to how often the metric actually changes in meaningful ways, not how often you feel anxious about it.
Step 3: Pick the Metric to Monitor
Select any Insights-style event metric — sum, count, or unique count over an event you’ve already instrumented. The agent uses the metric’s existing definition as its source of truth. Whatever filters, breakdowns, or conditions you’ve defined on that metric are what the agent monitors.
This means the quality of your KPI Monitor is directly tied to the quality of your metric definition. A metric that’s already well-defined in Insights — with the right event, the right filters to exclude internal users or test events, and the right counting method — translates directly into a reliable monitor. A metric built on a messy event or with no filtering will produce a noisy digest.
A few things worth knowing about what the agent can and can’t do with the metric:
The agent runs a single, fixed query based on the metric you selected. It cannot run additional queries, pull in other metrics, or take actions based on what it finds. It reads the metric you gave it and interprets what it sees. This is intentional — it keeps the monitor’s behavior predictable and its results auditable.
If you want to monitor multiple metrics, create multiple automations. They run independently and each digest covers exactly one metric.
Step 4: Write Your Instructions
The Instructions field is where most of the value gets configured, and it’s also where most people either skip too quickly or overcomplicate things.
Instructions tell the agent how to interpret results and what to call out in the digest. They shape the commentary, not the underlying query. The agent isn’t running a different analysis based on your instructions — it’s deciding how to frame and describe what it found.
Some examples of instructions that work well in practice:
“Flag anything that deviates more than 2 standard deviations from the 30-day average.” This is a statistical threshold that gives the agent a clear benchmark for what counts as notable versus normal variation.
“Focus on week-over-week change, not absolute values.” This is useful for metrics that are growing — you care whether the growth rate changed, not whether the absolute number went up.
“Ignore weekends when assessing daily patterns. Our product sees significantly lower usage on Saturday and Sunday.” This prevents the agent from flagging a normal weekend dip as an anomaly worth investigating.
“If the metric drops more than 15% from last week, treat that as high priority and say so explicitly.” This encodes a business-specific threshold that the agent can use when framing significance.
“This metric tracks paid conversions. An upward spike can indicate a tracking error as much as genuine improvement — flag large increases as worth verifying, not just celebrating.” This gives the agent context about how to interpret direction.
Instructions that don’t work as well: vague directions like “tell me what’s interesting” give the agent no framework to work with. Very long, detailed instructions with multiple conflicting priorities can produce inconsistent digests. Instructions that ask the agent to do things it can’t do — like “compare this to our Salesforce pipeline” or “check if the funnel also dropped” — will simply be ignored since the agent can only read the single metric it was given.
Write instructions the way you’d brief a thoughtful junior analyst who’s going to send you a weekly message about this metric. Tell them what you care about, what thresholds matter, what context they should factor in, and what you want them to flag explicitly versus mention in passing.
Step 5: Choose Your Delivery Channel
Digests can be delivered to Slack or email. Choose where your team actually pays attention.
For most teams, Slack is the better choice. A digest landing in a shared #metrics or #kpi-monitoring channel means the whole team sees it, can discuss it in thread, and can reference it later. Nobody has to remember to forward an email. The signal goes where the conversation already happens.
Email works better when the digest is meant for a specific individual — an exec who monitors one metric and doesn’t need to be in the team Slack channel, or a stakeholder outside your organization who should receive regular updates.
For Slack delivery, the Slack integration needs to be configured for your project before you can use it as a delivery channel. If you haven’t set that up, the Slack integration documentation covers the configuration steps. It’s a one-time setup and it enables Slack delivery across all automations in the project, not just this one.
Step 6: Save and Let It Run
Once you’ve configured cadence, metric, instructions, and delivery channel, save the automation. The first digest arrives at the next cadence boundary — meaning if you set it to weekly on a Thursday, you’ll get the first digest at the start of the following week’s window, not immediately.
After that, the agent runs on schedule without any action required from you. You can pause it, edit any of the configuration, or delete it at any time from the automations management view.
What You’ll Actually Receive
Each digest contains two things: a short summary of what the metric did in the last window compared to baseline, and a callout of any shifts the agent considers notable with its reasoning for flagging them.
The digest is written, not just a number. The agent explains what it saw — “Weekly active users dropped 12% week-over-week, from 8,400 to 7,380, which is the largest single-week decline in the last 90 days” — rather than delivering a raw percentage you then have to interpret yourself.
The notable shifts section applies the threshold and framing from your instructions. If you told it to focus on week-over-week change and flag anything above 2 standard deviations, that’s what shows up there. If nothing is notable in a given period, the digest says so rather than manufacturing significance.
Each digest also includes a mechanism to give feedback — rating whether the digest was useful, whether the agent flagged the right things, whether the framing was appropriate. That feedback is used to improve what the agent surfaces over time. Take a minute to use it, especially in the first few weeks of running a new monitor. It’s the fastest way to get the digest calibrated to what your team actually needs.
How to Get Value Out of This in Practice
Start with your two or three most important metrics, not ten. The temptation is to monitor everything immediately. Resist it. Start with the metrics that cause the most pain when they drift unnoticed — usually a key conversion event, an activation metric, and a retention signal. Get those monitors calibrated and delivering useful digests before expanding.
Write instructions based on what you’ve wished someone had told you in the past. Think about the last time a metric moved in a way that mattered. What would have been useful to know in the digest? What threshold would have signaled “investigate this”? What context would have prevented a false alarm? That’s what goes in instructions.
Deliver team metrics to a shared Slack channel, not individual email. The digest becomes more valuable when it’s a shared reference point for discussion rather than a report someone reads alone. A shared channel means when the digest says “conversions dropped 18% this week,” the whole team can immediately discuss whether it’s a tracking issue or a real product signal.
Don’t duplicate monitoring you’re already doing with Data Volume Monitoring. Data Volume Monitoring watches for sudden large drops in event volume — the kind of signal that indicates a tracking break. KPI Monitors watch metrics for business-level shifts — the kind of signal that indicates something meaningful changed in user behavior. They’re complementary, not redundant. If your purchase event drops 80% suddenly, Data Volume Monitoring catches that. If your purchase conversion rate gradually shifts 8% over two weeks, KPI Monitoring catches that.
Review and refine instructions after the first few digests. The first version of your instructions is a hypothesis about what matters. After you’ve received three or four digests, you’ll know whether the agent is flagging the right things or generating noise. Adjust the instructions based on what you actually found useful versus what you skimmed.
Current Limitations Worth Knowing
The feature is early and a few things that teams naturally ask for aren’t available yet.
Funnel and retention metrics aren’t supported — only Insights-style event metrics. If you want to monitor a funnel conversion rate, you’ll need to create a derived metric that expresses it as an event count or use a workaround like monitoring the final funnel step event separately.
There’s no per-user delivery window control. You can set weekly cadence but you can’t say “deliver every Monday at 9am local time.” The agent delivers at the cadence boundary, not at a specific time of day.
The agent runs one fixed query per monitor. It can’t do comparative analysis across multiple metrics, can’t pull in external context, and can’t take actions. It reads one thing and writes about it. That constraint makes the behavior predictable but it does mean complex multi-metric analysis isn’t something you can configure through instructions.
If any of these limitations are blockers for your use case, your account manager is the right contact — the product team is actively developing the feature and stakeholder input directly shapes the roadmap.
The Bottom Line
KPI Monitoring through Agentic Automations isn’t a replacement for deep analysis or human judgment about what metrics mean. It’s infrastructure for making sure the right people see the right signals on the right cadence, with enough initial interpretation that a drifting metric doesn’t go unnoticed for a week.
Set it up for the metrics that matter most, write instructions that reflect what your team actually cares about, and deliver to wherever your team already pays attention. The monitoring that happens consistently is always more valuable than the monitoring that happens when someone remembers to check.