勝敗は、戦う前から決まっている
PdMノウハウの第13回目のnoteです。第12回目のnoteは「神はオンボーディングに宿る」でした。もし良ければ読んでいただけたら嬉しいです。今日は「勝敗は、戦う前から決まっている」というタイトルで、どんな施策を打つ時も大切な考え方や方法について言語化したいと思います。参考にしていただき、自身のプロダクトが1mmでも成功に近づけば幸いです。僕が所属している組織について、このnoteで言及している概念については全く関係がないことを最初に明記させていただきます。
勝敗は、戦う前から決まっている？
孫子の兵法で以下のような学びがあります。
勝兵は先ず勝ちて而る後に戦いを求め、敗兵は先ず戦いて而る後に勝を求む
これは、勝つ戦い方は勝つことを予め見通しが立っている状態で戦いに臨み、負ける方は戦っている最中で勝つ方法を見つけるというようなことだと解釈しています。戦う前から勝つことがわかっていることに越したことはありません、そんなこと誰だってそうです。どうすれば、戦う前に勝敗を知ることができ、負ける戦はしないという状態にできるのでしょうか、プロダクト開発におけるその考え方を書いていきたいと思います。孫子の兵法に興味がある方は漫画が取っ付きやすいので、参考にしてみてください。
戦わずして、勝敗を知る
そもそも、戦わずして勝敗を知るとはどのような状態でしょうか。まず、勝敗がわからない状態を不確実性の観点から考えると、不確実性が高い状態だと言えます。世の中、不確実性が低いこともあって、絶対そうだとは言えませんが、商品は質が良くて安い方がいいし、配達は早ければ早いほど良いなど、人間が本来持っている欲望に沿ったものを実現できるならば、それは不確実性が低いのではないかと思います。しかしながら、そんな上手くはいかないのが人生なので、様々な打ち手には不確実性が存在します。
つまり、不確実性を下げることが勝敗を知る方法だということです。不確実性を下げるためには、不確実性に応じた情報が必要です。例えば、ユーザーはこういうプロダクトや機能が欲しいと言っている、クライアントはこれがあれば課金したいと言っているというような情報は確実ではなくても不確実性を下げる情報です。しかしながら、そういった情報では実際は不確実性が高い状態であり、それがリリースしたけど使われない、売れないということに繋がってしまいます。人間、口では言うが実際に取る行動は異なるからです。これを解決するために日夜行われていることが、MVPを使った実際の検証ということになります。
MVPをリリースして、世の中のニーズを検証しようということを詳しくは書きません。一般的に、仮説を立て、MVPをリリースして、定性定量分析を行い、フィードバックをMVPに反映させて、イテレーションを回すということは行われていると思います。今回のnoteでは、正しく不確実性を落とすために必要なTipsを紹介したいと思います。
ABテストを掌握する
ABテスト、プロダクト開発をしていれば一度は聞いたことがある、あるいはすでに何度も実施したことがあると思います。ABテストこそ、インターネット上で可能になった最適解を見つける方法として、最たるものでしょう。念の為、どういうものかを引用しておきます。
A/Bテストとは、バナーや広告文、Webサイトなどを最適化するために実施するテストの一つです。
特定の要素を変更したAパターン、Bパターンを作成し、ランダムにユーザーに表示し、それぞれの成果を比較することで、より高い成果を得られるパターンを見つけることができます。「A/B」テストという名前ではありますが、もちろん3パターン以上でテストすることもあります。
様々な要素でA/Bテストを行い、成果の高かったパターンを実装していくことにより、広告やWebサイト全体のクリック率やコンバージョン率といった成果が向上し、最適化されていくのです。
さて、ABテストを正しくできているでしょうか。Firebase A/B Testingのように、webでもアプリでも充実したサードパーティが存在しているので、仕組みに乗ってしまえば簡単に実装、実行し、有意差がある結果なのかという専門的な分析さえもやってくれるようになりました。簡単なバナーや文言をテストするだけなら、サードパーティが上手くやってくれるでしょう。しかしながら、当たり前ですが複雑なことをしようとすると、結果の解釈は独自でSQLを書いてみたり、母集団は自分たちで形成するなどのケースが出てくると思います。
コントロールを正しく扱う
ABテストを行う時は、AパターンとBパターンを用意して、コントロールグループとどう結果が異なるかをみます。このコントロールグループをどう扱うかが正しくABテストを行うコツです。今回は便宜上、すでに回している広告のクリエイティブを改善したいというケースで考えます。あくまで、僕が今まで経験してきた中での解なので、本当に正しくかは専門の書籍を参考にしてください。正しいやり方を知っている方はご教授くだされば嬉しいです。
例えば、上記の図のように母集団からランダムにABテストのグループを選定して、そのグループに広告を当てて結果を見るということを行います。比較対象となるのは、今まで回してきた広告の結果を使うというケースです。正直、これでも良いと思います。個人的には、ABテストはあくまでも手段であるので、手段の正しさを厳密にやるというのは違うと考えています。一方で、強力な方法は正しく扱わないと、思わぬ結果になってしまうこともあります。
こうすれば、もっと正確らしさがわかるという方法を紹介します。まず、テスト対象という大きい括りを母集団から切り出します。その括ったテスト対象の中で、ランダムに、A、B、そしてコントロールグループを形成します。AとBには試したいものを当てるのですが、コントロールグループには既存を当てます。その結果として、論理的にはテスト対象以外の結果とコントロールグループの結果は同じ値になるはずです。なぜ、こんなまどろっこしいことをするのでしょうか。それは、AとBのグループを抽出するという作業など様々な要因を排除するためです。臨床試験や化学実験でもプラセボを用いたり、ブランクテストを行うなどが用いられています。少々、面倒ですが、このようにすることで、ABテストの確らしさを上げることができると思います。
よくある質問で、どのくらいサンプルをテストすればいいのか、有意差がある比較とはどのくらいを言うのか、があります。便利なツールを見つけたので、参考にしてみてください。
変更する要素はたった一つだけ
次に注意すべきは、ABテストをする際に変更すべきはたった一つだけということです。これも、ただ単に方法論なので、絶対に変更点は一つにしないといけないということではありません。
しかしながら、広告クリエイティブを複数パターン試す時に、画像、文言、UI、掲載場所など様々な要素が含まれています。当たり前ですが、複数要因を変更してしまうと、どれが結果に効いたのかわからなくなってしまいます。打てる数や実施期間という制約があったり、早く結果を出したい気持ちもありますが、落ち着いて、着実に実行する方がかえって良いと思われます。もしも、母集団が巨大で、ABテストの数もN個回せるならば、並列で何個も回してみるということも可能です。
しかしながら、ABテストが盛んに行われている環境だと、複数のチームがABテストを実施していて、それらがミックスされて対象となってしまうというケースがあります。例えば、広告設置場所最適化のABテストと検索UI結果最適化のABテストを別々のチームが運用していた時、対象となる人が被っていて、双方の変更が当たってしまったなどです。この場合、文脈次第でありますが、論理的には多少の誤差が生じてしまい、双方の結果に影響してしまいます。対象となるグループの選定を横軸で調整するなどの仕組みで解決する方法を模索するといいと思います。ま、いっかでやってしまうのも手ですが、長期的な視点に則って、あるべき姿に寄せる方がいいと個人的には思います。
因果関係の分析を必ず行う
例えば、ECサイトを運営しているとして、検索結果のUIを変更するABテストを実施したとします。ABテストのゴールは売上です。売上が高いパターンが勝利だとします。これはこれで正しいです。
しかしながら、例えば、なぜAパターンの方が結果が良く、Bパターンの方が結果が芳しくないのでしょうか。その理由はなんでしょうか。因果関係を分析することで、間違った結果になることを防ぐことができます。
方法としては、上記の例ではユーザーがサイトを訪れて、最終的に購入するまでのアクションのそれぞれのエンゲージメントをAB双方のパターンで比較することです。サイトを訪れ、検索バーに文言を入力して、検索結果を表示して、閲覧して (ページを遷移したり) 、詳細ページに行き、カートに入れて、決済ページに行き、決済する、このそれぞれのアクションについてエンゲージメント率を出しておくと、どの数値がリフトしたかが見えてきます。最終的に、その結果について意味を与えるのは施策を回している人間です。しかしながら、数値に対して確からしい仮説を当てることで、どんどん精度が高まっていくでしょう。このような分析を行えば、Aパターンが実はユーザーに誤った操作を誘発してしまうUIになっていて、とあるエンゲージメントが異常なほど高かった結果として売上が上がっているだけで、後にクレームがたくさん来た (あるいはリピート率が極端に低く、LTVが低い) みたいなことになってしまいます。
ABテストの結果が出てきてから因果関係を分析するのも良いですが、仮説を立てることの練度を上げるならば、ABテストをする前からそれぞれ仮説を立てて、Aパターン、Bパターンが勝利する時の仮説は何か、調査すべき指標は何かを明確にしておくことで、抜け漏れがなく、より正確なABテストが可能になります。
局所最適化の罠
ABテストを行なっていく際に、行き着くのが局所最適化です。局所最適化が良くないことと言ってのではないことに注意してください。例えば、とある機能でめちゃくちゃ良い結果が出たけれども、他の機能との見え方や使い方が違いすぎて別世界になっている。あと、後述しますが、とある数値はめちゃくちゃ高まったけど、実は別の指標が落ちていたというようなことです。加えて、ABテストをやって80点は簡単に取れたけど、そこから先が大変でかなりリソースをかけたけど、5点上げるために使ったリソースを他に充てた方がよかったかも、などです。
局所最適化の罠から抜けるためには、局所最適化と同時に全体最適化も効かせることです。一歩引いて考え、数値は良いかもしれないが全体としてどうなのかという視点を持つことです。加えて、重要なのが目標設定です。どのくらいのリソースを使って、どの程度の結果を得たいのかを事前に設定しておくことが重要で、これはABテストを行うチーム自体では難しい可能性もあるので、それらを束ねる意思決定者の責任の下、行うのが良いでしょう。ある程度成果がでて、全体感も良さそうなら、さっさと違うことにリソースを割いた方がいいこともあります。カウンターメトリクスについては後述します。
カウンターメトリクスに目を向ける
重要なので、切り出しました。そもそも、カウンターメトリクスとはどんな指標でしょうか。引用します。
Counter Metricsとは、「Metricsの改善に難癖をつけれる可能性がある指標」です。
例えば、LPのクリック率が改善したとしても、その後のCV率が悪化していないか、などです。
これを習慣的に確認しないと、改善を進めているつもりが気づいたら全体改悪されてたという事態になることも珍しくありません。
書いてある通りではあるのですが、何か指標を改善するとなったら、それによって変動するであろう指標は見ておいた方がいいと思います。ABテストをしているならば、主要な数値はモニタリングするくらい仕組み化してしまった方が漏れが少なく済みそうです。つい、自分だけのスコープで物事を見てしまうと、追っている指標が上がったと喜んでしまいがちですが、本当にそれはチーム、はたまたプロダクト全体にとって良いことなのかを常に監視する目を持っておくことが長期的にみて、良いと思います。
この記事が気に入ったらサポートをしてみませんか？