Mixpanel est une plateforme d'analytique produit. Les équipes l'utilisent pour voir quelles fonctionnalités les gens adoptent, où ils sortent d'un funnel, et qui revient la semaine suivante. Elle excelle dans ce rôle, et pour beaucoup d'équipes produit, c'est l'endroit où les questions sur le comportement des utilisateurs trouvent leur réponse.
Une nouvelle question s'ajoute désormais à celles-ci. Certains des événements de votre produit ne sont plus déclenchés par une personne qui clique. Ils viennent d'agents IA agissant pour de vrais clients, de personnes travaillant avec un assistant IA, et d'automatisations que vous ne pouvez pas encore expliquer. Avant de lire un funnel, vous devez de plus en plus savoir qui ou quoi a produit les événements qu'il contient, et votre application doit savoir la même chose au moment où elle répond. C'est pour cela que Proof of Actor d'AgentCredia a été conçu.
Cette page compare les deux de manière équitable. Les faits sur Mixpanel ci-dessous proviennent de la documentation de Mixpanel elle-même, à novembre 2026.
La version courte
| Mixpanel | Proof of Actor | |
|---|---|---|
| Question principale | Comment les utilisateurs adoptent-ils, convertissent-ils et restent-ils ? | Qui ou quoi agit sur cette interaction, et quelle est la preuve ? |
| Où il collecte | SDK client et serveur plus APIs d'ingestion ; Mixpanel recommande le suivi côté serveur quand c'est possible | Middleware serveur, edge, HTTP API, MCP servers, plus un collecteur navigateur approuvé |
| Libellés d'agent et de bot | $mp_actor_type de agent, bot ou none, classé à partir du user agent |
Human, Human + AI, Agent ou Unknown, avec une base indiquée |
| Identité d'agent vérifiée | Non décrit dans la documentation de Mixpanel sur le trafic bot | Base Verified lorsqu'une signature de requête est validée par rapport à une clé publiée |
| Personnes assistées par IA | Non décrit comme une classe distincte | Un résultat à part entière : Human + AI |
| Trafic ambigu | Étiqueté none lorsqu'aucune correspondance agent ou bot n'est trouvée | Signalé comme Unknown, avec un repli que vous choisissez |
| Agit sur le trafic | Non, il analyse les événements | Routage selon vos politiques dans votre propre code, après observation |
Le reste de cette page explique chaque ligne.
À quoi le modèle d'événements de Mixpanel est conçu
Mixpanel repose sur les événements et sur les propriétés qui leur sont attachées. Vous instrumentez des actions comme sign up, create project ou invite teammate, vous ajoutez des propriétés comme plan ou platform, puis vous construisez des funnels, des courbes de rétention, des flows et des cohorts en décomposant les événements selon ces propriétés. Chaque question d'analyse dans Mixpanel devient finalement une question sur quels événements se sont produits, pour qui, et avec quelles valeurs de propriétés.
Ce modèle explique précisément pourquoi le contexte d'acteur s'y intègre si bien. Un libellé d'acteur n'est qu'une propriété de plus, et une fois qu'il figure sur vos événements, chaque funnel et chaque graphique de rétention peut être segmenté par celui-ci. Mixpanel a déjà évolué dans cette direction avec son propre étiquetage d'acteur. La question ouverte est de savoir sur quoi cette propriété repose, et si votre application peut utiliser la même réponse pendant que la requête est encore en cours de traitement.
Proof of Actor produit cette réponse dans le chemin de requête. Chaque interaction reçoit l'une des quatre classes : Human quand les signaux indiquent une personne, Human + AI quand une personne a agi avec une assistance IA déclarée ou observée via une intégration prise en charge, Agent pour une interaction automatisée ou d'origine agent, et Unknown lorsque les preuves ne permettent pas une détermination fiable. Chaque résultat indique sa base de preuve, verified, declared, inferred ou unknown, ce qui transforme la propriété d'un simple libellé en un libellé avec une force déclarée.
Où chacun s'exécute
Mixpanel propose à la fois du suivi côté client et côté serveur. Sa documentation sur le choix d'une méthode de suivi recommande de suivre autant que possible depuis vos serveurs et de compléter avec le suivi côté client lorsque c'est nécessaire, en notant que le suivi côté client est affecté par les bloqueurs de publicité.
Proof of Actor s'exécute aussi côté serveur, mais sa position est différente. Il se place dans le chemin de requête de votre application : middleware Node.js, Next.js, la couche edge que vous contrôlez, une HTTP API générique ou votre MCP server, avec un collecteur navigateur optionnel sur les pages approuvées. Cela lui permet de voir les signaux au moment de la requête, comme le fait qu'un client ait présenté une signature, qu'un client se soit déclaré lui-même, et que votre propre assistant ait effectué l'action. Consultez la page intégrations pour la liste complète.
Comment Mixpanel traite les bots et les agents IA
Mixpanel a ajouté un vrai support ici, et cela mérite d'être reconnu. Selon sa documentation sur le trafic bot :
- La bibliothèque JavaScript de Mixpanel filtre par défaut une courte liste de crawlers connus, dont Googlebot et Bingbot.
- Tout événement envoyé avec la propriété
$ignoredéfinie est supprimé à l'ingestion, ce qui vous permet d'écrire votre propre logique de filtrage. - Les APIs d'ingestion de Mixpanel classent le user agent de chaque événement et définissent
$mp_actor_type(Actor Type) suragentpour les requêtes provenant d'un LLM agissant pour le compte d'un utilisateur humain,botpour le trafic automatisé générique comme les crawlers et les indexeurs de recherche, ounonequand aucun des deux ne s'applique. Lorsque le type estagentoubot,$mp_actor_name(Actor Name) contient l'identité classée, comme GPTBot ou ClaudeBot. - Avec le suivi côté serveur, la classification utilise le user agent de la requête qui est arrivée jusqu'à Mixpanel, c'est-à-dire la bibliothèque HTTP de votre serveur, sauf si vous transmettez le user agent de l'utilisateur final, par exemple dans
$mp_raw_user_agent. Mixpanel indique que la classification peut sinon être inexacte. - Les événements dans Mixpanel sont immuables, donc les événements de bot déjà enregistrés sont gérés en les excluant de l'analyse plutôt qu'en les supprimant.
C'est un libellé de reporting utile. C'est aussi, par conception, un libellé dérivé de la chaîne user agent. Les chaînes user agent sont auto-déclarées et faciles à imiter, un problème abordé dans l'entrée user agent spoofing. Et la documentation ne décrit pas de classe pour les personnes travaillant avec une assistance IA, ni de façon d'indiquer que les preuves sont trop faibles pour conclure.
$mp_actor_type et la classe Proof of Actor, côte à côte
Comme les deux résultats peuvent vivre sur le même événement Mixpanel, il est utile de voir comment ils se rapportent l'un à l'autre :
$mp_actor_type |
Sur quoi cela repose | Ce que la classe Proof of Actor peut ajouter |
|---|---|---|
agent |
Une correspondance de user agent pour un LLM agissant pour un utilisateur | Agent avec une base verified lorsque la requête porte une signature valide, ou une base declared ou inferred sinon |
bot |
Une correspondance de user agent pour des crawlers et des indexeurs | Agent lorsque les preuves le permettent, ou Unknown lorsqu'un user agent de type crawler n'est appuyé par rien d'autre |
none |
Aucun agent ou bot correspondant sur le user agent | Human, Human + AI ou Unknown, de sorte que les personnes assistées et le trafic inexpliqué ne restent pas cachés dans le même bucket |
Les principales différences viennent de l'endroit où chaque réponse est produite.
Des preuves au-delà de la chaîne user agent. $mp_actor_type est dérivé du user agent, qui est auto-déclaré et facile à imiter, comme l'explique l'entrée user agent spoofing. Un résultat Proof of Actor verified signifie qu'une signature de requête a été vérifiée par rapport à une clé publiée, en utilisant HTTP Message Signatures tel que défini dans RFC 9421 et utilisé par Web Bot Auth.
Une classe pour les personnes assistées par IA. Dans $mp_actor_type, une personne qui rédige avec un assistant tombe dans none avec tous les autres utilisateurs. Proof of Actor signale Human + AI lorsque l'assistance est déclarée ou observée via une intégration prise en charge, de sorte qu'un funnel Mixpanel puisse montrer si les utilisateurs assistés par IA activent plus vite ou bloquent à d'autres endroits.
Unknown au lieu de none. none signifie qu'aucune correspondance n'a été trouvée. Unknown signifie que les preuves n'étaient pas assez solides pour conclure, ce qui est une affirmation différente et plus utile. Vous pouvez suivre le taux de Unknown par route, et le guide sur la gestion du trafic Unknown couvre les schémas de repli.
Des événements qui ne passent jamais par votre suivi. Les agents appellent souvent des APIs et des MCP servers plutôt que de cliquer dans une UI. Proof of Actor classe ces interactions là où elles se produisent, y compris les appels d'outils MCP ; voir le cas d'usage MCP servers.
Une décision au moment de la requête. Les événements Mixpanel sont immuables et analysés après coup, ce qui est correct pour l'analytique. Proof of Actor permet aussi à votre application d'autoriser, d'adapter, de challenger, d'envoyer en revue ou de rate-limit selon la route, la classe et la base. Il commence en mode observation, donc rien ne change tant que vous ne choisissez pas d'appliquer.
Utiliser Mixpanel et Proof of Actor ensemble
- Classer à la requête. Proof of Actor renvoie une classe et une base pour chaque interaction dans votre application, API ou MCP server.
- Ajouter deux propriétés d'événement. Attachez la classe et la base comme propriétés, par exemple celles que vous nommez
actor_classetactor_basis, sur les événements Mixpanel que vous envoyez déjà. Le suivi côté serveur rend cela simple, car votre application détient le résultat. - Conserver aussi
$mp_actor_type. Transmettez le user agent de l'utilisateur final afin que le propre libellé de Mixpanel reste exact, et comparez les deux propriétés. Lorsqu'elles divergent, la base Proof of Actor vous indique quelle preuve il faut faire primer. - Décomposer les rapports que vous utilisez déjà. Segmentez les funnels, la rétention et les flows par classe d'acteur pour voir si les inscriptions pilotées par agent retiennent comme celles des humains, ou si les utilisateurs assistés par IA atteignent l'activation plus tôt. Le cas d'usage SaaS apps montre où cela compte le plus.
- Agir là où c'est important. Écrivez des politiques pour les routes où la classe d'acteur doit modifier l'expérience. Le guide sur déployer des politiques sensibles à l'acteur en toute sécurité couvre le processus.
Quand choisir l'un ou l'autre
Choisissez Mixpanel lorsque votre question porte sur le comportement produit : activation, conversion, rétention, adoption des fonctionnalités et parcours empruntés par les utilisateurs. Son libellé $mp_actor_type est une bonne première approximation pour séparer agents et bots à l'intérieur de cette analyse.
Ajoutez Proof of Actor lorsque vous avez besoin que ce libellé porte des preuves, lorsque les utilisateurs assistés par IA comptent pour votre produit, lorsque une grande partie de votre trafic agent arrive via des APIs ou des MCP servers, ou lorsque votre application doit répondre au moment de la requête plutôt que dans un rapport. Mixpanel vous indique comment votre produit est utilisé. Proof of Actor vous indique qui l'utilise à chaque interaction, avec des preuves, et donne à votre code un moyen d'agir en conséquence.
Commencer
Proof of Actor est en bêta privée. Dans le cadre du founding developer program, les équipes sélectionnées peuvent bénéficier jusqu'à 12 mois d'accès gratuit dans les limites d'utilisation convenues, sans facturation automatique. Demandez un accès anticipé et parlez-nous de votre produit et des interactions que vous souhaitez comprendre.
Mixpanel est une marque déposée de Mixpanel, Inc.