プロダクト分析SaaSの先駆者Mixpanel 復活にむけた価格改定

Mixpanelは2009年にサンフランシスコで設立された。創業者のスハイル・ドーシ氏が、PayPalの共同創業者であるマックス・レフチンが率いていたSlideという今はなき会社で、インターンをしていたときに生まれたアイデアがMixpanelへと繋がる。同社は後にProduct Analyticsと呼ばれる分野を切り開くことになる。

前職でプライシングのためにプロダクト分析をよく行っていた関係で、どのようなツールがあるのかはよく調べていましたが、その中でもっとも頻出するプレイヤーの一人がMixpanelでした。当時も今もProduct Analytics領域には山のようにプレイヤーがいたため、ユーザーとしては選択肢があって良かったですが、裏返せばMixpanelにとっては強豪ひしめく中で戦っていたということ。今回は、同社がプライシングをどう使ってProduct Analytics業界を切り抜けてきたのか気になったため、ニュースレターとしてまとめてみます。

なお、当記事では特に注釈がない限り、引用は「Price to Scale」8章から行います。

当時SaaSやモバイルアプリが急速に発展している一方、ユーザーの行動を詳細に分析するツールは不足していた。当時分析ツールといえば、既存のウェブ解析ツールであるGoogle Analyticsであったが、プロダクト分析としての用途としては不十分だった。Google Analyticsはウェブサイト全体のトラフィックやページビューの数、参照元などを提供する強力なツールであるが、個々のユーザーがアプリケーション内でどのように行動しているかを具体的に追跡するには不十分だったのだ。一方で、Slide社でインターンとしてプロダクト分析をしていたドーシ氏は、Slideが内製されていた分析ツールを使うことでかなり効率的に分析できており、Zyngaを始めとしたソフトウェア企業の多くが同じように内製していたことに気づいた。

この問題を解決するため、ドーシは新たな解析ツールの開発を決意。Y Combinatorから資金を得て、アリゾナ州立大学の同窓生であるティム・トレフレンとともにMixpanelを設立した。Mixpanelの初期のミッションは、Google Analyticsとは異なり、ウェブやモバイルアプリケーション内でのユーザー行動を詳細に追跡し、企業がユーザー体験を向上させるための洞察を提供することであった。このツールは、どの機能が頻繁に使用されているか、どのプロセスでユーザーが離脱しているか、またどのユーザー層がどのような行動パターンを示しているかを分析するために設計された。結果、Google Analyticsが全体的なトラフィック分析に強みを持つのに対し、Mixpanelはよりサービス内の詳細なユーザー行動分析に特化して、両者は補完的な役割を果たすようになる。実際、当時Product Analyticsという領域において、Mixpanelがどのような点で革新的だったのかは、ニュースレター「ｺｯｶﾗSaaS」のAmplitude回に詳しい。

その後、Mixpanelは後発であるAmplitudeに抜き去られてしまうものの、Amplitudeがエンタープライズ企業へフォーカスを変えたことによって、Mixpanelは空いたSMB〜中堅スタートアップの市場に向けて製品市場進出戦略を磨き直す余地を得られるようになる。その結果Mixpanelは、ARRの半分以上をセルフサーブによって獲得できるようになったと言われている。2024年8月29日時点では、Amplitudeの時価総額が$10.91B（約1,636億円）なのに対して、一度は追い抜かされたMixpanelも$1.05B（≒1,557億円）、ARR$100M（≒150億円）以上と、筋肉質なケンタウロス企業に成長する。公開企業であるAmplitudeと未公開企業のMixpanelの企業価値を比べるのは難しいが、間違いなくMixpanelはプロダクト分析SaaSにおいてAmplitudeと双璧をなすSaaS企業と言える。

今回紹介するMixpanelの価格改定を主導したプラナヴ・カシャップ氏は、シマンテックやマイクロソフトといった大手テック企業でPM（プロダクトマネージャー）やPMM（プロダクトマーケティングマネージャー）の経験を積んだのち、マッキンゼーでテック企業の解約やコンバージョン改善を支援するという、B2B SaaSのGTMを中心におきキャリアを歩んできた人物。2018年にMixpanelに入社した際は、プロダクトマネージャーとHead of Pricingという二つの役職を兼ねて入社している。

そんなSaaS企業のGTMを長らく見てきたカシャップ氏から見て、Mixpanelのプライシングはいくつかの課題を生んでいた。

前提として、Mixpanelではユーザー行動を「イベント」という単位でトラッキングしている。「アプリの特定のボタンをクリックしたとき」「ページを閲覧したとき」「ユーザーがサインアップまたはログインしたとき」「特定の機能を利用したとき」など、分析者はトラッキングしたい行動を「イベント」として設定する。2009年の創業時、Mixpanelはこのイベントという概念を、製品価値の指標であり、請求対象の単位であるバリューメトリックとして選んでいた。

しかし創業から10年ちかく経過して、カシャップ氏がHead of Pricingとして入社した2018年には、バリューメトリックがイベントであることが大きく3つの問題を引き起こしていた。

一つ目に、イベントというバリューメトリックがMixpanelの費用の見積もりを難しくさせていた。顧客の多くは初めて導入するProduct AnalyticsのプロダクトがMixpanelであったため、何をどれだけトラッキングするかという、イベントの概念に馴染みがなかった。そのため、新規ユーザーや営業担当者に、必要なイベント数を尋ねても、その場で答えることができなかった。Mixpanelを導入しようという顧客にしてみればユーザー数はパッと答えることができても、どれだけ自分たちがトラッキングするべきか、イベント数はわからない。こうしたことは、Mixpanelの商談のリードタイムを引き伸ばすことに繋がっており、LPを見て自分たちが払うことになる費用感を想像しにくかったことが、潜在的な顧客たちを取り逃がすことにも繋がっていたはずだ。

二つ目に、Mixpanelへの支払いが必ずしも顧客の成長に連動しないケースが出てきたことだ。プロダクトマネージャーは、製品を改善するために、ユーザーがどこで困っているのか、あるいは新しい機能がどのように機能しているのか、ユーザーがそれを使っているかどうか、それを使い続けているかどうかなどを知りたいと思ってMixpanelを利用する。しかしたくさんのイベントをトラッキングする必要がある = Mixpanelへ高額な支払いをする一方で、それがビジネス上の成長に直接結びつかないケースが出てきており、これが解約や不満につながっていた。例えばゲーム企業であれば、莫大な無料ユーザーを抱えており、トラックするイベント数も大量になる一方で、実際にゲーム内で消費をしてくれるアクティブなプレイヤーは少数に過ぎない。ゲーム自体の収益性とは関係なく、イベント数ゆえにMixpanelへの支払いは高額になってしまっていた。

この問題がさらに三つ目の問題を引き起こしていた。コスト削減のためには、優先順位の低いイベントを削除する必要があるが、どのユーザー行動が最も価値があり、最も価値がないかを把握するため、顧客はMixpanelを使って分析してコスト削減をしていた。本来サービスの成長のために使うはずのMixpanelを、Mixpanelというコストを削減するために利用していたことになる。また、一部の顧客にいたっては、コスト削減のために、本来は測定し続けたいはずのイベントすらも削除してしまう、という行動を起こしていた。顧客がユーザーの行動を完全に把握できるようにすること、これがMixpanelが提供したい価値のはずだったが、価格設定がこれを阻んでいたことになる。

カシャップ氏はこうした3つの問題を把握した上で、顧客が気になるイベントを費用を気にせずすべてトラッキング追跡できるように、イベントを追加するたびにコストが増えないような、別のバリューメトリックへの切り替えを検討することになる。

バリューメトリックの変更は、プライシングの変更において最も大きな変更の一つにかぞえられる。ほぼ全ての顧客になんらかの影響を与えるため広く顧客に説明をしなければいけないし、金銭的な額も大きく変わることが多い。追うべき指標が変わるため、社内においてもダッシュボードはもちろん、あらゆるチームのKPIが追従して変わらざるを得ないし、ボーナスの計算式に売上が組み込まれている企業においては、従業員の生活にまで影響する。

カシャップ氏は顧客の成長に応じたバリューメトリックにすることを念頭に、まずは約50種類の指標を挙げて、そこから絞り込んでいく工程を踏んだ。指標の候補には、追跡したアプリやウェブサイトの数、ページビュー、定額制、クエリー量、保存データ、エクスポートしたデータ、Mixpanelが貢献した収益の割合、解約率の低減など、月間アクティブユーザー数（MAU）や月間トラッキングユーザー数（MTU）など、Mixpanelが関連するありとあらゆる候補が挙がった。

その上でカシャップ氏は5つの基準に照らして候補を絞り込んだ。

予測可能か：予測可能であることは、バリューメトリックを選ぶ上で一番重要な基準の一つ。一般的に顧客は、SaaSの請求金額が毎月乱高下するようなことは望んでいない。予測可能性が低いといくつかの弊害を引き起こす。一つに獲得への悪影響だ。潜在顧客がいつも測定していない指標がバリューメトリックになっている場合、公開されている価格表を見たとしても、自社にとってどれくらいのコストになるかイメージがつきづらい。商談においても、顧客がいつも測定していない指標は、「一度持ち帰って」調べてもらって改めて見積もりを作成することになる。また年間でのコストの見積もりもしにくくなるので、顧客がサービス契約のために予算を確保する点でも難しくなる。例えば、Zoomのバリューメトリックはユーザーライセンス数だが、これがもし総通話時間であったならば、どれくらいコストがかかるのか俄然イメージしづらくなるだろう。仮にある企業が営業チーム用にZoomを契約する場合、営業担当者の人数=ユーザーライセンス数はパッと思い出せるが、どれくらい商談をしているか時間合計は一度帰って調べなければならない。また顧客にとってのコストの乱高下は、SaaS企業にとっての収益の乱高下でもあり、そういった観点からも予測可能性は重要になる。

顧客に受け入れられるか：Mixpanelは、従業員10人以下のSMBから、10万人以上のエンタープライズまで、さまざまな顧客サイズに使われていた。そのため、定額制にしてしまうとどちらかのサイズの企業にとって受け入れられない価格となってしまうことから、定額制は見送った。また、Mixpanelの利用を妨げるような指標は同様に見送ることにした。例えばMixpanel上で実行したクエリ量という指標は、もし実現した場合Mixpanelの中で新しい切り口での分析を試したり、より分析を深める意欲を削いでしまうリスクがあった（予測可能性も低かった）。

追跡可能か：バリューメトリックは、顧客とサービス提供側の両方が確実に追跡できるものである必要がある。仮にMixpanelが貢献した収益のX％を請求するとした場合を考えてみると分かりやすい。このバリューメトリックは顧客が収益を上げなければMixpanelへの費用が発生しないため、一見魅力的に見える。しかし実際のところ、「Mixpanelが貢献した収益」を定義して、定義した収益を顧客から開示してもらなければならないが、ほとんどの企業はそんなことはしたくない。たとえ収益が帳簿を公開することに熱心であったとしても、請求のたびに行う顧客とのやり取りは請求を行うMixpanelのバックオフィスを疲弊させるだけになる。

スケーラブルか：そのバリューメトリックはSMBにもエンタープライズにも適用できるか。MixpanelはSMBからスタートアップ、エンタープライズなど、様々なサイズの企業が顧客にいたため、カシャップ氏としては、毎月100ドルの予算しかない顧客と、年間数百万ドルを支払うエンタープライズが整合するようなバリューメトリックにしたかった。例えば、Mixpanelに作られるプロジェクト数（イベントデータを格納するコンテナ）は候補の一つだったが、企業サイズが大きくなるほどにプロジェクト数が増える傾向が見られなかったため、候補から外された。

価値と整合しているか：カシャップ氏は候補に上げた50種類以上の指標について回帰分析を行い、どれが最も顧客の収益と相関性が高いかを調べた。その結果、従来のバリューメトリックであるイベント数ではなく、月次追跡ユーザー数=Monthly Tracked Users（MTU、Mixpanelで分析するデータのなかで月に少なくとも1つのアクションを起こしたユーザー）という指標が圧倒的に相関を示した。

このMTUという指標は他の基準に照らしても、最も優れた指標だった。