Mixpanel is a product analytics platform. Teams use it to see which features people adopt, where they drop out of a funnel, and who comes back next week. It is excellent at that job, and for many product teams it is the place where questions about user behavior get answered.
A new question now sits next to those. Some of the events in your product are no longer driven by a person clicking. They come from AI agents acting for real customers, from people working with an AI assistant, and from automation you cannot yet explain. Before you read a funnel, you increasingly need to know who or what produced the events in it, and your application needs to know the same thing in the moment so it can respond. That is what Proof of Actor from AgentCredia is built for.
This page compares the two fairly. Mixpanel facts below come from Mixpanel's own documentation as of November 2026.
The short version
| Mixpanel | Proof of Actor | |
|---|---|---|
| Main question | How do users adopt, convert and retain? | Who or what is acting on this interaction, and what is the evidence? |
| Where it collects | Client and server SDKs plus ingestion APIs; Mixpanel recommends server-side tracking where possible | Server middleware, edge, HTTP API, MCP servers, plus an approved browser collector |
| Agent and bot labels | $mp_actor_type of agent, bot or none, classified from the user agent |
Human, Human + AI, Agent or Unknown, with a stated basis |
| Verified agent identity | Not described in Mixpanel's bot traffic documentation | Verified basis when a request signature checks out against a published key |
| AI-assisted people | Not described as a separate class | A first-class result: Human + AI |
| Unclear traffic | Labeled none when no agent or bot match | Reported as Unknown, with a fallback you choose |
| Acts on traffic | No, it analyzes events | Routes per your policies in your own code, after observation |
The rest of this page explains each row.
What Mixpanel's event model is built for
Mixpanel is built around events and the properties attached to them. You instrument actions such as sign up, create project or invite teammate, add properties such as plan or platform, and then build funnels, retention curves, flows and cohorts by breaking events down by those properties. Every analysis question in Mixpanel eventually becomes a question about which events happened, to whom, and with which property values.
That model is exactly why actor context fits so well inside it. An actor label is just another property, and once it is on your events, every funnel and retention chart can be split by it. Mixpanel has already moved in this direction with its own actor labelling. The open question is what that property is based on, and whether your application can use the same answer while the request is still being handled.
Proof of Actor produces that answer in the request path. Each interaction gets one of four classes: Human when the signals indicate a person, Human + AI when a person acted with AI assistance that was declared or observed through a supported integration, Agent for automated or agent-origin interaction, and Unknown when the evidence does not support a reliable determination. Each result states its evidence basis, verified, declared, inferred or unknown, which turns the property from a label into a label with stated strength.
Where each one runs
Mixpanel offers both client-side and server-side tracking. Its documentation on choosing a tracking method recommends tracking as much as possible from your servers and supplementing with client-side tracking when necessary, noting that client-side tracking is affected by ad blockers.
Proof of Actor also runs server-side, but its position is different. It sits in the request path of your application: Node.js middleware, Next.js, the edge layer you control, a generic HTTP API or your MCP server, with an optional browser collector on approved pages. That lets it see signals at the moment of the request, such as whether a client presented a signature, whether a client declared itself, and whether your own assistant took the action. See the integrations page for the full list.
How Mixpanel treats bots and AI agents
Mixpanel has added real support here, and it deserves credit. According to its bot traffic documentation:
- The Mixpanel JavaScript library filters out a short list of known crawlers by default, including Googlebot and Bingbot.
- Any event sent with the
$ignoreproperty set is dropped at ingestion, so you can write your own filtering logic. - Mixpanel's ingestion APIs classify the user agent of each event and set
$mp_actor_type(Actor Type) toagentfor requests from an LLM acting on behalf of a human user,botfor generic automated traffic such as crawlers and search indexers, ornonewhen neither applies. When the type isagentorbot,$mp_actor_name(Actor Name) holds the classified identity, such as GPTBot or ClaudeBot. - With server-side tracking, classification uses the user agent of the request that reached Mixpanel, which is your server's HTTP library, unless you forward the end user's user agent, for example in
$mp_raw_user_agent. Mixpanel notes that classification can otherwise be inaccurate. - Events in Mixpanel are immutable, so bot events already recorded are handled by filtering them out of analysis rather than deleting them.
That is a useful reporting label. It is also, by design, a label derived from the user agent string. User agent strings are self-reported and easy to imitate, a problem covered in the user agent spoofing entry. And the documentation does not describe a class for people working with AI assistance, or a way to say that the evidence is too weak to call.
$mp_actor_type and the Proof of Actor class, side by side
Because both results can live on the same Mixpanel event, it helps to see how they relate:
$mp_actor_type |
What it is based on | What the Proof of Actor class can add |
|---|---|---|
agent |
A user agent match for an LLM acting for a user | Agent with a verified basis when the request carries a valid signature, or a declared or inferred basis otherwise |
bot |
A user agent match for crawlers and indexers | Agent when the evidence supports it, or Unknown when a crawler-style user agent is not backed by anything else |
none |
No agent or bot match on the user agent | Human, Human + AI or Unknown, so assisted people and unexplained traffic stop hiding in the same bucket |
The main differences come from where each answer is produced.
Evidence beyond the user agent string. $mp_actor_type is derived from the user agent, which is self-reported and easy to imitate, as the user agent spoofing entry explains. A verified Proof of Actor result means a request signature was checked against a published key, using HTTP Message Signatures as defined in RFC 9421 and used by Web Bot Auth.
A class for AI-assisted people. Under $mp_actor_type, a person drafting with an assistant falls into none alongside every other user. Proof of Actor reports Human + AI when the assistance is declared or observed through a supported integration, so a Mixpanel funnel can show whether AI-assisted users activate faster or stall in different places.
Unknown instead of none. none means no match was found. Unknown means the evidence was not strong enough to call, which is a different and more useful statement. You can track the Unknown rate by route, and the guide on handling Unknown traffic covers the fallback patterns.
Events that never pass through your tracking. Agents often call APIs and MCP servers rather than clicking through a UI. Proof of Actor classifies those interactions where they happen, including MCP tool calls; see the MCP servers use case.
A decision at request time. Mixpanel events are immutable and analyzed after the fact, which is right for analytics. Proof of Actor also lets your application allow, adapt, challenge, send to review or rate-limit per route, class and basis. It starts in observation mode, so nothing changes until you choose to enforce.
Using Mixpanel and Proof of Actor together
- Classify at the request. Proof of Actor returns a class and basis for each interaction in your application, API or MCP server.
- Add two event properties. Attach the class and basis as properties, for example ones you name
actor_classandactor_basis, on the Mixpanel events you already send. Server-side tracking makes this simple because your application holds the result. - Keep
$mp_actor_typetoo. Forward the end user's user agent so Mixpanel's own label stays accurate, and compare the two properties. Where they disagree, the Proof of Actor basis tells you which evidence to trust. - Break down the reports you already use. Split funnels, retention and flows by actor class to see whether agent-driven sign ups retain like human ones, or whether AI-assisted users reach activation sooner. The SaaS apps use case shows where this matters most.
- Act where it matters. Write policies for the routes where actor class should change the experience. The guide on rolling out actor-aware policies safely covers the process.
When to choose which
Choose Mixpanel when your question is about product behavior: activation, conversion, retention, feature adoption and the paths users take. Its $mp_actor_type label is a good first cut at separating agents and bots inside that analysis.
Add Proof of Actor when you need that label to carry evidence, when AI-assisted users matter to your product, when much of your agent traffic arrives through APIs or MCP servers, or when your application needs to respond at request time rather than in a report. Mixpanel tells you how your product is used. Proof of Actor tells you who is using it on each interaction, with evidence, and gives your code a way to act on it.
Get started
Proof of Actor is in private beta. Through the founding developer program, selected teams can receive up to 12 months of free access within agreed usage limits, with no automatic billing. Apply for early access and tell us about your product and the interactions you want to understand.
Mixpanel is a trademark of Mixpanel, Inc.