Mixpanel はプロダクト分析プラットフォームです。チームはこれを使って、どの機能が採用されているか、どこでファネルから離脱するか、誰が翌週戻ってくるかを把握します。この用途には非常に優れており、多くのプロダクトチームにとって、ユーザー行動に関する問いに答える場所になっています。
今では、その問いに新しいものが加わっています。プロダクト内のイベントの一部は、もはや人がクリックして発生させるものではありません。実際の顧客のために acting する AI agents、AI アシスタントと一緒に作業する人、まだ説明できない automation から発生します。ファネルを読む前に、その中のイベントを誰または何が生成したのかを知る必要があり、アプリケーションはその場で同じことを知って応答する必要があります。AgentCredia の Proof of Actor は、そのために作られています。
このページでは、両者を公平に比較します。以下の Mixpanel に関する事実は、2026年11月時点の Mixpanel 自身のドキュメントに基づいています。
要点
| Mixpanel | Proof of Actor | |
|---|---|---|
| 主な問い | ユーザーはどう採用し、変換し、継続するのか? | このインタラクションで acting しているのは誰または何か。そしてその証拠は何か? |
| 収集場所 | client と server の SDK に加え、取り込み API。可能なら server-side tracking を推奨 | server middleware、edge、HTTP API、MCP servers、そして承認済みの browser collector |
| agent と bot のラベル | user agent から分類された agent, bot, none の $mp_actor_type |
basis を明示した Human, Human + AI, Agent, Unknown |
| 検証済みの agent identity | Mixpanel の bot traffic documentation では説明されていない | 公開鍵に対して request signature が検証された場合は Verified basis |
| AI 支援の人 | 別クラスとしては説明されていない | 主要な結果として Human + AI |
| 不明なトラフィック | agent や bot に一致しない場合は none と表示 | Unknown として報告され、選択した fallback を使える |
| トラフィックに対して action を起こすか | いいえ。イベントを分析するだけ | observation の後、独自コードで policy に従って route ごとに制御 |
このページの残りでは、それぞれの行を説明します。
Mixpanel のイベントモデルが想定する用途
Mixpanel はイベントと、それに付随する properties を中心に設計されています。sign up、create project、invite teammate などの action を計測し、plan や platform といった properties を追加してから、イベントをそれらで分解し、funnel、retention curve、flow、cohort を構築します。Mixpanel におけるあらゆる分析の問いは、最終的にはどのイベントが、誰に対して、どの property 値とともに発生したか、という問いになります。
このモデルは、actor context がその中に自然に収まる理由でもあります。actor label は単なる別の property であり、それをイベントに付ければ、すべての funnel と retention chart をそれで分解できます。Mixpanel もすでに、自身の actor labeling でこの方向に進んでいます。未解決の問いは、その property が何を根拠にしているか、そして request の処理中にアプリケーションが同じ答えを使えるかどうかです。
Proof of Actor は、その答えを request path で生成します。各インタラクションは 4 つの class のいずれかになります。signals が人を示す場合は Human、人が宣言された、または対応する integration を通じて観測された AI 支援で acting した場合は Human + AI、自動化された、または agent 起点のインタラクションは Agent、そして evidence が信頼できる判断を支えない場合は Unknown です。各結果は evidence basis として verified, declared, inferred, unknown のいずれかを示し、property を単なるラベルから、強さが明示されたラベルへと変えます。
それぞれが動く場所
Mixpanel は client-side と server-side の両方の tracking を提供します。tracking method の選択 に関するドキュメントでは、可能な限り server から tracking し、必要に応じて client-side tracking を補完することを推奨しており、client-side tracking は ad blocker の影響を受けると述べています。
Proof of Actor も server-side で動作しますが、その位置づけは異なります。あなたのアプリケーションの request path, Node.js middleware, Next.js, 自分で管理する edge layer, 汎用 HTTP API, または MCP server に置かれ、承認済みページでは任意で browser collector も使えます。これにより、request の瞬間に signals を確認できます。たとえば、client が signature を提示したか、client が自分を宣言したか、そして自分の assistant がその action を実行したか、です。完全な一覧は integrations ページを参照してください。
Mixpanel における bot と AI agents の扱い
Mixpanel はこの領域で実際の support を追加しており、それは評価に値します。Mixpanel の bot traffic documentation によると:
- Mixpanel の JavaScript library は、Googlebot や Bingbot を含む既知の crawler の短い一覧をデフォルトで除外します。
$ignoreproperty を設定して送信されたイベントは取り込み時に破棄されるため、自前の filtering logic を書けます。- Mixpanel の取り込み API は各イベントの user agent を分類し、
$mp_actor_type(Actor Type) を、ユーザーの代わりに acting する LLM からの request にはagent、crawler や search indexer のような一般的な automated traffic にはbot、どちらでもない場合にはnoneに設定します。type がagentまたはbotの場合、$mp_actor_name(Actor Name) には GPTBot や ClaudeBot などの分類された identity が入ります。 - server-side tracking では、分類は Mixpanel に届いた request の user agent を使います。つまり、あなたの server の HTTP library の値が使われます。必要なら、たとえば
$mp_raw_user_agentで end user's user agent を転送できます。そうしないと分類が不正確になる可能性があると Mixpanel は述べています。 - Mixpanel のイベントは immutable なので、すでに記録された bot イベントは削除ではなく、分析から除外することで扱います。
これは有用な report label です。しかし設計上、user agent string から導かれたラベルでもあります。user agent string は自己申告であり、模倣も容易です。この問題は user agent spoofing の項目で扱っています。そしてドキュメントには、AI 支援で作業する人のための class や、証拠が弱すぎて判断できないと示す方法は記載されていません。
$mp_actor_type と Proof of Actor の class を並べて比較する
両方の結果を同じ Mixpanel event に載せられるので、その関係を確認すると分かりやすくなります。
$mp_actor_type |
何に基づくか | Proof of Actor class が追加できること |
|---|---|---|
agent |
ユーザーのために acting する LLM に一致した user agent | request に有効な signature が含まれていれば Verified basis、それ以外でも declared または inferred basis を持つ Agent |
bot |
crawler と indexer に一致した user agent | evidence がそれを支える場合は Agent、crawler 風の user agent に他の裏付けがなければ Unknown |
none |
user agent に agent や bot の一致がない | Human, Human + AI, Unknown のいずれかになり、支援を受けた人や説明のつかないトラフィックが同じ bucket に隠れなくなる |
主な違いは、それぞれの答えがどこで生成されるかにあります。
user agent string を超える evidence. $mp_actor_type は user agent から導かれますが、前述のとおり自己申告で、模倣も容易です。user agent spoofing の項目で説明しているように、Verified な Proof of Actor の結果とは、HTTP Message Signatures を RFC 9421 で定義された方法で用い、Web Bot Auth でも使われている公開鍵に対して request signature を検証したことを意味します。
AI 支援の人のための class. $mp_actor_type では、assistant を使って下書きを行う人は、他のすべての user と一緒に none に入ります。Proof of Actor は、支援が宣言された場合、または対応する integration を通じて観測された場合に Human + AI を報告します。そのため、Mixpanel の funnel で、AI 支援ユーザーがより早く activation するのか、あるいは別の場所で停滞するのかを確認できます。
none ではなく Unknown. none は一致が見つからなかったことを意味します。Unknown は、判断に足るだけの evidence がなかったことを意味します。この違いは重要で、より有用です。Unknown rate を route ごとに追跡でき、Unknown traffic の扱い方 のガイドで fallback pattern を説明しています。
tracking を通らないイベント. agent は UI をクリックするよりも、API や MCP servers を呼び出すことが多くあります。Proof of Actor はそのような interaction を発生地点で分類し、MCP tool call も含みます。詳細は MCP servers のユースケース を参照してください。
request 時点での decision. Mixpanel の event は immutable で、後から分析するためのものです。それは analytics に適しています。Proof of Actor はさらに、あなたの application が route、class、basis ごとに allow、adapt、challenge、review に送る、または rate-limit することも可能にします。最初は observation mode で始まるため、enforce するまでは何も変更されません。
Mixpanel と Proof of Actor を併用する
- request 時点で classify する。 Proof of Actor は、あなたの application、API、または MCP server における各 interaction に対して class と basis を返します。
- 2 つの event property を追加する。 すでに送信している Mixpanel event に、たとえば
actor_classとactor_basisと名付けた property として class と basis を付与します。server-side tracking なら、application 側に結果があるため簡単です。 $mp_actor_typeも保持する。 end user's user agent を転送して、Mixpanel 自身のラベルが正確なままになるようにし、2 つの property を比較します。食い違う場合は、Proof of Actor の basis がどの evidence を信頼すべきかを示します。- 既存の report を分解する。 funnel, retention, flow を actor class で分けて、agent-driven の sign up が human と同じように継続するのか、AI 支援ユーザーがより早く activation に到達するのかを確認します。SaaS apps のユースケース は、この違いが最も重要になる場面を示しています。
- 重要な場所で action を起こす。 actor class によって体験を変えるべき route には policy を書きます。actor-aware policy を安全に展開する方法 のガイドで、その手順を説明しています。
どちらを選ぶべきか
Mixpanel を選ぶのは、問いが product behavior に関する場合です。activation、conversion、retention、feature adoption、そしてユーザーがたどる path が対象です。その $mp_actor_type ラベルは、その分析の中で agent と bot を切り分ける最初の有効な手がかりになります。
Proof of Actor を追加するのは、そのラベルに evidence が必要なとき、AI 支援ユーザーがプロダクトにとって重要なとき、多くの agent traffic が API や MCP servers 経由で届くとき、または application が report ではなく request 時点で応答する必要があるときです。Mixpanel は、あなたのプロダクトがどう使われているかを示します。Proof of Actor は、各 interaction で誰が使っているのかを evidence つきで示し、コードがそれに基づいて action を起こす方法を与えます。
始める
Proof of Actor は private beta です。founding developer program を通じて、選ばれたチームは合意済みの利用上限の範囲で最長 12 か月の無料利用を、通常の自動課金なしで受けられます。早期アクセスに申し込む から、あなたのプロダクトと、理解したい interaction について教えてください。
Mixpanel は Mixpanel, Inc. の商標です。