ファネルと成長チャネル — 順序と人数を数える
一言でいうと
ファネルは、「登録した人のうち、何人が次の段階に順序どおりに、決められた時間内に到達したか」を人数で数えます。そして、有料転換をどの広告チャネルの手柄にするかは、アトリビューションモデルという選択であり、選択を変えると、チャネル別の顧客獲得コスト(CAC)が変わります。どちらも、定義を書かなければ、同じ記録から、異なる結論が出ます。
なぜ必要なのか
登録は月に1,000人なのに、有料転換は数十人です。どこから漏れているかを知って初めて、何を直すかを決められます。最初のドキュメントを作れないのか、作っても共有しないのか、共有しても決済の手前で止まるのか。この問いに答える表が、ファネルです。
ところが、ファネルの表は、簡単に膨らみます。「共有」イベントが2,500行と書くと、共有した人が2,500人いるように読まれます。1人が20回共有したのかもしれません。共有より先に招待をした人を、「共有 → 招待」を経た人として数えると、段階の間のコンバージョン率が偽物になります。3か月後に決済した人まで入れると、「登録後2週間以内の転換」という問いとは違う数字になります。
チャネルも同じです。検索広告を見て入り、1週間後に、知人の紹介リンクで登録した人は、どのチャネルの顧客でしょうか。ファーストタッチに与えれば検索広告が、ラストタッチに与えれば紹介が、この人を連れてきたことになります。広告費の配分は、この1行の選択にかかっています。
どう動くのか
人数と順序と窓: このラボのファネルは、登録 → create_doc → share_doc → invite_sent → upgradeです。各段階は、前の段階に到達した時刻以降の最初の発生で到達し、すべての段階は、登録時刻から14×24時間以内でなければなりません。1人は、1つの段階で1回だけ数えます。こう定義すれば、各欄は前の欄より大きくなりえず、欄の間の比率が、「次の段階に進んだ人の割合」という意味を持ちます。
| よくある間違い | 何が膨らむか |
|---|---|
| イベントの行数を数える | 繰り返しの行動が多い段階が大きくなる。欄が前の欄より大きくなることもある |
| 順序を見ない | 段階を逆にたどった人が混ざって、後ろの欄が大きくなる |
| 窓を置かない | 古いコホートほど、転換が高く見える(観測期間が長いだけです) |
最も大きく漏れる欄: 段階別のコンバージョン率(次の欄 ÷ この欄)を並べると、最も低いところが見えます。最も低いところが、ただちに最初に直すところだとは限りませんが(直すコストが違うので)、少なくとも、どこを先に調べるかは決まります。
アトリビューションモデル: 1人が複数の接点を経て転換したときに、手柄をどこに与えるかを決めるルールです。このラボは、2つを比べます。ファーストタッチ(最初に私たちを知らせたチャネル)と、ラストタッチ(登録直前のチャネル)です。参考までに、Googleアナリティクス4のアトリビューションモデルの案内は、ファーストクリック・線形・時間減衰・位置ベースのモデルを、2023年11月から提供しなくなったと書いており、今はデータドリブンモデルと、ラストクリック系だけが残っています。ツールがどのモデルを使っているかを、先に確認する必要があるという意味です。
CAC: このラボのチャネルCACは、「そのチャネルの3か月分のマーケティング費用の合計 ÷ そのチャネルに帰属した有料転換者数」です。アトリビューションモデルを変えれば、分母が変わって、CACが変わります。費用が0のオーガニック検索は、CACが0に見えますが、コンテンツを作った人の時間が、費用から抜けているのかもしれません。費用表に何が入っているかも、定義の一部です。以下の例の金額は、このラボのデータの、架空の値です。
ファネルの定義は、製品の仮説です: ドキュメント作成 → 共有 → 招待 → 決済という順序は、「共有して招待してみたチームがお金を払う」という仮説を含んでいます。実際の顧客が別の道(招待なしにすぐ決済)を進んでいるなら、順序を強制したファネルは、彼らを「離脱」として数えます。そのため、順序を無視したファネルと、定義どおりのファネルが大きく違うなら、計算ミスを疑う前に、仮説そのものを見直すシグナルでもあります。
現場での姿
- マーケティングチームはファーストタッチで、グロースチームはラストタッチで計算して、同じチャネルのCACを、2倍の差で報告します。どちらも、計算は合っています。
- 「共有コンバージョン率90%」というスライド。分子が共有イベントの数、分母がドキュメントを作った人の数でした。
- 広告から入った人の転換が低いのに、CACだけを見て予算を増やします。コホートのモジュールで見たように、そのチャネルの人は、長く残りもしません。ファネル・継続・CACをチャネル別に並べて初めて、判断が成り立ちます。
間違いに気づく方法
- ファネルのどの欄でも、前の欄より大きければ、計算が間違っています。人数で、順序どおりに数えれば、欄は減るだけです。
- コホートごとにコンバージョン率を分けて見たとき、古いコホートほど高ければ、窓がないのではと疑います。
- アトリビューションモデル別の有料転換者の合計が、全体の有料転換者数と同じかどうかを見ます。違えば、誰かが2回数えられたか、抜けています。
- CACの表に、アトリビューションモデルと費用の期間が書かれていなければ、その表で予算を動かしません。
次のラボですること
「モアノート」の記録で、イベント数と人数の違いを先に確認し、順序と14日の窓を守ったファネル関数を作ります。順序を無視したり、窓をなくしたりしたときに、数字がどれだけ膨らむかを測り、登録経路別のファネルを見た後、ファーストタッチとラストタッチで有料転換を帰属して、チャネル別のCACを出します。採点ツールは、あなたのファネル関数を、変形したデータでも再実行します。