Proof of Actor vs Mixpanel: analytics de produto e evidências de ator, lado a lado

O Mixpanel é uma plataforma de analytics de produto. As equipes a usam para ver quais recursos as pessoas adotam, onde abandonam um funil e quem volta na semana seguinte. Ele é excelente nessa função e, para muitas equipes de produto, é o lugar onde as perguntas sobre comportamento do usuário são respondidas.

Agora existe uma nova pergunta ao lado dessas. Alguns dos eventos no seu produto já não são gerados por uma pessoa clicando. Eles vêm de agentes de IA agindo por clientes reais, de pessoas trabalhando com um assistente de IA e de automação que você ainda não consegue explicar. Antes de ler um funil, cada vez mais você precisa saber quem ou o que produziu os eventos nele, e seu aplicativo precisa saber a mesma coisa no momento em que acontece para poder responder. Foi para isso que o Proof of Actor da AgentCredia foi criado.

Esta página compara os dois de forma justa. Os fatos sobre o Mixpanel abaixo vêm da documentação do próprio Mixpanel, em novembro de 2026.

A versão curta

	Mixpanel	Proof of Actor
Pergunta principal	Como os usuários adotam, convertem e retêm?	Quem ou o que está agindo nesta interação, e qual é a evidência?
Onde coleta	SDKs no cliente e no servidor, mais APIs de ingestão; o Mixpanel recomenda tracking no lado do servidor quando possível	Middleware de servidor, edge, HTTP API, MCP servers e um coletor de navegador aprovado
Rótulos de agente e bot	$mp_actor_type de agent, bot ou none, classificados a partir do user agent	Human, Human + AI, Agent ou Unknown, com uma base declarada
Identidade de agente verificada	Não descrita na documentação de tráfego de bots do Mixpanel	Base Verified quando uma assinatura de requisição confere com uma chave publicada
Pessoas com assistência de IA	Não descritas como uma classe separada	Um resultado de primeira classe: Human + AI
Tráfego pouco claro	Rotulado como none quando não há correspondência de agente ou bot	Reportado como Unknown, com um fallback que você escolhe
Age sobre o tráfego	Não, ele analisa eventos	Faz roteamento por suas políticas no seu próprio código, após a observação

O restante desta página explica cada linha.

Para que o modelo de eventos do Mixpanel foi criado

O Mixpanel é construído em torno de eventos e das propriedades associadas a eles. Você instrumenta ações como cadastro, criar projeto ou convidar colega, adiciona propriedades como plano ou plataforma e então monta funis, curvas de retenção, fluxos e coortes com base nessas propriedades. Toda pergunta de análise no Mixpanel acaba se tornando uma pergunta sobre quais eventos aconteceram, para quem e com quais valores de propriedade.

Esse modelo é exatamente o motivo pelo qual o contexto de ator funciona tão bem dentro dele. Um rótulo de ator é apenas mais uma propriedade e, quando ele está nos seus eventos, todo funil e gráfico de retenção pode ser segmentado por ele. O Mixpanel já avançou nessa direção com sua própria rotulagem de ator. A questão em aberto é em que essa propriedade se baseia e se seu aplicativo pode usar a mesma resposta enquanto a requisição ainda está sendo processada.

O Proof of Actor produz essa resposta no caminho da requisição. Cada interação recebe uma de quatro classes: Human quando os sinais indicam uma pessoa, Human + AI quando uma pessoa agiu com assistência de IA declarada ou observada por meio de uma integração suportada, Agent para interação automatizada ou originada por agente, e Unknown quando a evidência não sustenta uma determinação confiável. Cada resultado informa sua base de evidência, verified, declared, inferred ou unknown, o que transforma a propriedade de um rótulo em um rótulo com força declarada.

Onde cada um roda

O Mixpanel oferece tracking no lado do cliente e no lado do servidor. Sua documentação sobre escolher um método de tracking recomenda rastrear o máximo possível a partir dos seus servidores e complementar com tracking no lado do cliente quando necessário, observando que o tracking no cliente é afetado por bloqueadores de anúncios.

O Proof of Actor também roda no lado do servidor, mas sua posição é diferente. Ele fica no caminho da requisição do seu aplicativo: middleware do Node.js, Next.js, a camada edge que você controla, uma HTTP API genérica ou seu MCP server, com um coletor opcional de navegador em páginas aprovadas. Isso permite que ele veja sinais no momento da requisição, como se um cliente apresentou uma assinatura, se um cliente se declarou e se o seu próprio assistente realizou a ação. Veja a página de integrações para a lista completa.

Como o Mixpanel trata bots e agentes de IA

O Mixpanel adicionou suporte real aqui, e isso merece crédito. De acordo com sua documentação de tráfego de bots:

• A biblioteca JavaScript do Mixpanel filtra por padrão uma pequena lista de crawlers conhecidos, incluindo Googlebot e Bingbot.
• Qualquer evento enviado com a propriedade $ignore definida é descartado na ingestão, então você pode escrever sua própria lógica de filtragem.
• As APIs de ingestão do Mixpanel classificam o user agent de cada evento e definem $mp_actor_type (Actor Type) como agent para requisições de um LLM agindo em nome de um usuário humano, bot para tráfego automatizado genérico como crawlers e indexadores de busca, ou none quando nenhum dos dois se aplica. Quando o tipo é agent ou bot, $mp_actor_name (Actor Name) guarda a identidade classificada, como GPTBot ou ClaudeBot.
• Com tracking no lado do servidor, a classificação usa o user agent da requisição que chegou ao Mixpanel, que é a biblioteca HTTP do seu servidor, a menos que você encaminhe o user agent do usuário final, por exemplo em $mp_raw_user_agent. O Mixpanel observa que, caso contrário, a classificação pode ficar imprecisa.
• Os eventos no Mixpanel são imutáveis, então eventos de bot já registrados são tratados filtrando-os da análise em vez de excluí-los.

Esse é um rótulo útil de relatório. Também é, por design, um rótulo derivado da string de user agent. Strings de user agent são autodeclaradas e fáceis de imitar, um problema abordado na entrada sobre user agent spoofing. E a documentação não descreve uma classe para pessoas trabalhando com assistência de IA, nem um jeito de dizer que a evidência é fraca demais para concluir.

$mp_actor_type e a classe do Proof of Actor, lado a lado

Como os dois resultados podem viver no mesmo evento do Mixpanel, vale a pena ver como eles se relacionam:

$mp_actor_type	Em que se baseia	O que a classe do Proof of Actor pode adicionar
agent	Uma correspondência de user agent para um LLM agindo para um usuário	Agent com base Verified quando a requisição traz uma assinatura válida, ou uma base declared ou inferred caso contrário
bot	Uma correspondência de user agent para crawlers e indexadores	Agent quando a evidência sustenta isso, ou Unknown quando um user agent no estilo crawler não é apoiado por mais nada
none	Nenhuma correspondência de agent ou bot no user agent	Human, Human + AI ou Unknown, para que pessoas assistidas e tráfego sem explicação não fiquem escondidos no mesmo grupo

As principais diferenças vêm de onde cada resposta é produzida.

Evidência além da string de user agent. $mp_actor_type é derivado do user agent, que é autodeclarado e fácil de imitar, como explica a entrada sobre user agent spoofing. Um resultado verified do Proof of Actor significa que uma assinatura de requisição foi verificada contra uma chave publicada, usando HTTP Message Signatures conforme definido no RFC 9421 e usado pelo Web Bot Auth.

Uma classe para pessoas com assistência de IA. Em $mp_actor_type, uma pessoa elaborando algo com um assistente cai em none junto com qualquer outro usuário. O Proof of Actor reporta Human + AI quando a assistência é declarada ou observada por meio de uma integração suportada, então um funil do Mixpanel pode mostrar se usuários com assistência de IA ativam mais rápido ou travam em outros pontos.

Unknown em vez de none. none significa que nenhuma correspondência foi encontrada. Unknown significa que a evidência não foi forte o bastante para concluir, o que é uma afirmação diferente e mais útil. Você pode acompanhar a taxa de Unknown por rota, e o guia sobre lidar com tráfego Unknown cobre os padrões de fallback.

Eventos que nunca passam pelo seu tracking. Agentes costumam chamar APIs e MCP servers em vez de clicar em uma interface. O Proof of Actor classifica essas interações onde elas acontecem, incluindo chamadas de ferramentas MCP; veja o caso de uso de MCP servers.

Uma decisão no momento da requisição. Eventos do Mixpanel são imutáveis e analisados depois do fato, o que é adequado para analytics. O Proof of Actor também permite que seu aplicativo permita, adapte, desafie, envie para revisão ou limite a taxa por rota, classe e base. Ele começa no modo de observação, então nada muda até que você decida aplicar.

Usando o Mixpanel e o Proof of Actor juntos

1. Classifique na requisição. O Proof of Actor retorna uma classe e uma base para cada interação no seu aplicativo, API ou MCP server.
2. Adicione duas propriedades de evento. Anexe a classe e a base como propriedades, por exemplo as que você nomear actor_class e actor_basis, nos eventos do Mixpanel que já envia. O tracking no lado do servidor torna isso simples porque seu aplicativo mantém o resultado.
3. Mantenha $mp_actor_type também. Encaminhe o user agent do usuário final para que o próprio rótulo do Mixpanel continue preciso, e compare as duas propriedades. Quando elas divergirem, a base do Proof of Actor diz em qual evidência confiar.
4. Segmente os relatórios que você já usa. Separe funis, retenção e fluxos por classe de ator para ver se cadastros conduzidos por agentes retêm como os humanos, ou se usuários com assistência de IA chegam à ativação mais cedo. O caso de uso de SaaS apps mostra onde isso mais importa.
5. Aja onde importa. Escreva políticas para as rotas em que a classe do ator deve mudar a experiência. O guia sobre implantar políticas conscientes de ator com segurança cobre o processo.

Quando escolher cada um

Escolha Mixpanel quando sua pergunta for sobre comportamento do produto: ativação, conversão, retenção, adoção de recursos e os caminhos que os usuários percorrem. Seu rótulo de $mp_actor_type é uma boa primeira aproximação para separar agentes e bots dentro dessa análise.

Adicione Proof of Actor quando você precisar que esse rótulo venha com evidência, quando usuários com assistência de IA importarem para o seu produto, quando grande parte do seu tráfego de agentes chegar por APIs ou MCP servers, ou quando seu aplicativo precisar responder no momento da requisição e não em um relatório. O Mixpanel mostra como seu produto é usado. O Proof of Actor mostra quem está usando em cada interação, com evidência, e dá ao seu código um jeito de agir com base nisso.

Comece agora

O Proof of Actor está em beta privado. Pelo programa de founding developer, equipes selecionadas podem receber até 12 meses de acesso gratuito dentro de limites de uso acordados, sem cobrança automática. Solicite acesso antecipado e conte sobre seu produto e as interações que você quer entender.

Mixpanel é uma marca registrada da Mixpanel, Inc.