はじめに
データアナリストとして仕事を始めて3年が経ちました。この3年間で、施策の立案やテストの設計、効果測定といったデータを活用とした施策実行支援のプロセスを数多く経験させていただいた中で、自分がデータアナリストとして気をつけていることをまとめてみました。自分の考えていることをほぼ全て書き起こしたので、少し冗長かもしれません。
想定読者はデータアナリスト1年目と施策立案や企画を行うビジネスマンを想定しています。
また、これは筆者の働くWeb系企業の自社プロダクト改善における話になりますので、予めご了承ください。
まとめ
思いのほか長文になってしまったので、時間のない人向けに先にまとめを書いておきます。
- データアナリストは施策設計から積極的に関与すべし。後から効果測定依頼だけもらっても手遅れになることが多い。
- 施策設計の際には、施策によるKPIリフトが大きくなるように、また効果測定が精度良く容易に行えるような施策内容に調整する。
- 施策終了後は効果測定に時間をかけすぎない。潔く負けを認めるのも重要である。
本題に入る前に
大前提としていくつか認識しておいた方が良いことがあるので、先に記しておきます。
データアナリストは施策の設計段階から入るべし
効果測定だけを依頼されるケースがありますが、データアナリストが最大限のバリューを発揮するためには、施策の設計段階から関わることが非常に重要だと考えています。
なぜ効果測定だけ関わるのが望ましくないのでしょうか。施策終了後に効果測定の依頼だけをもらっても、
- ログが正しく仕込まれていないから、そもそもKPIの集計ができない
- ユーザー行動が大きく変化するような別施策が同時期に走っており、別施策と効果の切り分けができない
- 施策設計の筋が悪く、施策の影響を受けるユーザーの数が少なすぎて、施策の効果を検出するのが難しい
- ABテストをやったものの、AAテストが正しく行われておらず施策による効果が不明瞭
このようなことが、施策が終わってから発覚する可能性があります。
効果測定を正しく行えないということは、意思決定の質が下がる・意思決定ができない ということであり、せっかくお金・時間・工数をかけて実施した施策が無駄打ちになってしまいます。
このような事態を避けるためにも、施策の設計段階からデータアナリストを入れておき、正しく効果測定が出来る・施策インパクトの期待値が大きくなるような設計にするのが望ましいと考えます。
施策実施前にやること
施策設計を決める場に参加する
繰り返しになりますが、データアナリストは施策設計段階から入るべきです。
会社やサービスで実施されている全ての施策に関与することは現実的に不可能だと思うので、施策による経済インパクトが大きいと見込まれるものから優先して積極的に設計段階から関与すべきでしょう。
（そもそも、施策が走る際に自然とデータアナリストに効果測定の声がかかる、サービスで実施される重要施策の情報が耳に入るなど、左記のような環境作りが非常に重要なのですが、自分は再現性のあるノウハウを持ち合わせていないので、ここでは省略させていただきます。）
開発チームと密に連携する
自社Webサービスの改善に関する施策の場合、開発チームが在籍する施策設計を決める場に積極的に参加すべきと考えています。なぜならば、Webサービスでは、開発のリソースや既存のソースコード（≒改修しやすさ）によって施策内容が左右されるからです。開発都合によって施策の内容やスケジュールが変わることは多々あります。
開発チームに詳細をお任せしてしまうと、開発の方で悪意なく良かれと思って変更した箇所が、アナリストの観点では効果測定や施策インパクトに影響するような変更してほしくない箇所だった、ということが発生する可能性があります。このような齟齬をなくすために、少なくとも施策設計段階では開発チームと細かい箇所まで積極的に会話すべきです。
開発チームと連携するメリットはその施策限りではありません。開発チームとの要件調整のミーティングに何度も参加してくると、どの機能の改善・開発にどれくらい工数がかかるのか、開発の事情がなんとなく見えてきます。
開発都合に配慮しすぎてしまい、少ない工数で実現できるような施策ばかりを実施することはもちろん良くないですが、開発に関する知識があれば、別の施策を実施する時に開発都合を考慮してイイ感じの施策提案や設計、優先度付けが出来るようになり、後々色々と捗ってきます。
施策設計段階で調整すべきこと
データアナリストが自ら施策提案する場合や、他の人が企画した施策に効果測定者として加わる場合は、効果測定を行うデータアナリストが以下の内容を整理できると良いと思います。
- 施策内容
- KPI
- テスト結果に対するネクストアクション
- 施策の実施時期
- KPI測定に必要なログ設計
施策内容
ここで気にする観点は3つで、1. 事業として優先度の高い問いに関するものか、2. 施策のインパクトが出うる設計になっているか、3. 課題に対して打ち手（施策内容）が対応しているか、という観点です。
1. 事業として優先度の高い課題か?
特に自分から施策立案する時に特に気をつける観点になるでしょう。施策の実施にはヒト・モノ・カネが必要になるので、事業として注力すべきKPIの改善や意思決定者が気にしている課題の解決に関する施策を優先的に提案・実施すべきです。一年目の自分はこれを抑えずに施策提案し、何度もリジェクトされた苦い思い出があります。
2. 施策によるKPIリフトが望める設計になっているか
ここでは説明のため、KPI=売上とします。
施策による売上リフトは 施策影響を受けるユーザーの売上 * 施策による売上リフト幅 で決まります。売上リフト幅が大きくなるような斬新なアイデアの施策を考えたくなりますが、KPIリフト幅を事前に精緻に見積もることは難しいですし、それが事前に分かるなら全てのビジネスは右肩上がりで大成功しているでしょう。
施策内容を吟味する際にまず優先的に考えることは、第1項が大きくなるような、つまり多くのユーザーが施策対象となるような施策設計にすべきです。1%のユーザーの売上を10倍にする施策ではなく、90%のユーザーの売上を1.1倍にする施策を設計すべきです。特にWebサービスの場合、これは事前に数値出しを行えば分かることなので、データアナリストが必ず数値出しや試算を実施すべきです。
では施策による売上リフト幅の見積もりはどうすれば良いでしょうか。これについては過去の他類似施策の実績値等を参考にして現実味のある数値を出すべきでしょう。自分の体感として、売上が2倍, 3倍になるような施策はかなり稀です。小難しい分析を用いて精緻に見積もりを出す必要はないと思いますが、納得感の得られるロジックで簡便に見積もるくらいで良いと思います。
施策のインパクトが小さいことは、効果測定の観点でも望ましくありません。効果が小さいと効果測定にて差を検出するのが難しくなります。適切なサンプルサイズがあるならば問題ないですが、そうでない場合に効果測定の際に分析手法でカバーする方法もありますが、効果測定の工数も増えますし算出される値の信憑性も低くなりますので、施策内容はあまり軽微なものにしすぎない方が良いでしょう。
3. 課題に対する打ち手として施策内容が適切か
こちらも往々にして起こりがちです。
何らかのビジネス課題を解決するための手段として施策が実行されるわけですが、その課題解決の手段として適切な施策内容になっていない場合があります。特に、施策内容先行で企画されたものは目的と手段にズレが生じることが多いような印象を持っています。
これは事前分析で調査することが可能なので、テスト実施する前に調査すべきです。これを怠ると効果測定が始まってから「何でこの施策内容にしたんだっけ...?」と気付くことになります。
2.と被る点ではありますが、課題に対して施策内容が軽微すぎるケースも存在します。これは施策に使える予算や工数、開発都合を考慮しすぎて、実現可能かつ簡易的にできる範囲で収めようとしてしまう時に発生します。せっかくやるならば大胆にやりましょう。
KPI
意思決定に用いるためのKPIを、施策内容に応じて設定します。
メインKPIとして売上のようなKGIに近い指標やそれを良く説明する指標、サブKPIとして施策によって変動しやすい指標かつメインKPIからブレイクダウンされる指標を2 ~ 3個設定するのがベターでしょう。あまり多すぎても意思決定しづらくなるため、多ければ多いほど良いわけではありません。
メインKPIは想像しやすいですが、サブKPIが不明瞭な施策は危険です。サブKPIが不明瞭ということは、施策によってどのような行動変容を期待しているかが不明瞭ということであり、これはつまり施策で検証したい仮説や目的が分かっていないことになります。仮説なき施策やテストは絶対に避けるべきです。
テスト結果に対するネクストアクション
KPIを設定したら、テスト結果（=KPIの増減）に対するネクストアクションを決めます。
KPIがX%リフトしたら施策をローンチする、有意差がつかなくても毀損がなければテスト終了からそのままローンチし続ける、というようなイメージです。
ローンチ是非をいつ判断するのかも予め決めておきましょう。極端な例ですが、効果があると分かっている施策の意思決定を先送りにして効果測定に1ヶ月かけてしまうと、1ヶ月分の機会損失が発生してしまいます。
至極当たり前の話ですが、いつまでに誰が数値を確認するのか、ローンチするためにはいつまでに誰に何をしてもらう必要があるのか、ということをクリアにしておくべきです。
施策の実施時期
ここで確認すべきは、1. 交互作用が生じうる他の施策が同時or前後に走っていないか、2. 効果を測るのに十分な期間か の2点です。
1. 交互作用が生じうる他の施策が同時or前後に走っていないか
特にABテストを実施できない施策では、こいつの調整次第で効果測定の難易度が大きく変わります。前月や前年など別期間のデータを用いてバイアスなく効果を推定するためには、キャンペーンなどユーザー行動に影響を与えうるイベントの開催状況が施策期間と比較期間で揃っていないといけません。施策の実施時期を多少ずらすことで諸条件を揃えることが出来るのならば、施策時期を変更すべきです。
ABテストを実施する場合、テスト群とコントロール群でどちらも別施策の状況を等しく受けるのだから、"基本的には"他の施策の影響を考えなくても問題ないです。ただし、厳密に言えばこれは正しくありません。いくつかの施策が並列に走っている場合、それぞれの施策が干渉し合ってユーザーに別の影響を与えるケースがあるからです。
上述のような施策間の交互作用を全て考慮するのは現実的に不可能なので、明らかに影響を及ぼし合うことが分かっている施策については、施策の実施時期をずらす等の対応を取った方が良いと考えています。
このように書くと、「いやいや、実際に知りたい効果は他施策の並走も含めた影響だろう。寧ろ並走させた上でちゃんと交互作用の影響も調べて意思決定すべきだろう。」というツッコミが来るかもしれません。このような意見は至極真っ当で正しい意見だと思います。しかし自分のチームでは、1. 効果測定の際に交互作用をどこまで気にするべきか範囲を決めるのが難しく分析工数が増えるのを避けたい、2. 意思決定までのリードタイム短縮を優先したい、以上の理由から時期をずらして実施し、交互作用=0と仮定して施策ごとに効果を測る方針を採用しています。
2. 効果を測るのに十分な期間か
これはN週間の単位で施策内容に応じて設定するのが望ましいでしょう。ToCサービスであれば平日と休日でKPIの傾向に差分が生じることが多いと思うので、週単位で見れば曜日による施策影響の差異も確認できるからです。
また、施策開始直後は反応が良くても、時間が経つと反応が落ち着いてくることもあります。このような場合、期間を短くしすぎると施策の効果を過大評価してしまいます。こうした反応が想定される場合はある程度長い期間をとって施策を実施した方が良いでしょう。ただし、期間を長くするということは意思決定までのリードタイムが伸びてしまうことになるため、関係者で合意を取ってイイ感じの期間に設定しましょう。
KPI測定に必要なログ設計
「サイト内の全ての箇所にトラッキングが設置済みでデータ分析環境も完璧でSQLで取得できないデータは存在しない！」というような完全無欠な状況だったら問題ないのですが、そうでない場合や新機能を追加するような施策では、ログの設計と正しくログが格納されていることをSQLで確認するところまでやるべきです。まあ大丈夫っしょ！と油断して確認を怠ると、正しくログが集計出来ていないことにテストが始まってから気づいたりするものです。
ログの設計は、予め効果測定の分析設計をしておき、効果測定の時に必要になりそうなログの実装をお願いしましょう。とりあえず全部で！などと雑なお願いの仕方をすると、ログ実装のせいでリリースがずれ込んでしまい、最悪の場合、スケジュール延期のせいで別施策と被って効果測定が難しくなってしまう...というような状況が発生する可能性があります。
効果測定の分析設計をイメージしておく
KPIやその変化によってネクストアクションを決めるということは、効果測定の分析設計がイメージ出来ていると良いでしょう。
ABテストであればSQLで単純集計してKPIの比較が済むことが多いと思いますが、ABテストでない施策の効果測定ではバイアスを小さくするために工夫が必要なので考えることが増えます。
前後比較する際にはDIDした方が良いな、比較となるユーザー群は用意できるかな、別のキャンペーンやってるけど影響大丈夫かな、となるとちょっと効果測定時間使いそうだな、とか。今回は傾向スコアが使えるかな、でもサンプルサイズの偏りが大きくなりそうだからちょっと微妙かな、とか。CATEを見たいからxx-learner使いたいな、とか。こんな感じのことをザックリで良いので考えられると良いでしょう。
そして、この時点で効果測定が難しくなったり精度の良い数値が出せない見込みがあるならば、予めステークホルダーにアウトプットイメージや効果測定にかかる工数を伝えるなど期待値調整しておくべきです。
具体の分析手法については沢山の書籍がありますが、以下に挙げる書籍を読んでおけば実務の効果測定において手も足も出ない状態にはならないはずです。
- 効果検証入門
- ABテスト実践ガイド
- Pythonで学ぶ効果検証入門
- サンプルサイズの決め方
- 統計的因果推論の理論と実装
- 因果推論入門〜ミックステープ：基礎から現代的アプローチまで
- 「ほとんど無害」な計量経済学
- 統計的多重比較法の基礎
具体の分析設計の話はそれだけで1つ記事を作れるくらいには難しいことなので割愛します。
施策実施中にやること
ダッシュボードを作ってKPIを観察する
無事に施策がローンチされたら、ダッシュボードを作ってKPIをウォッチします。毎日KPIを舐めるように観察する必要はないですが、少なくともローンチ直後や初日のデータは必ず確認すべきです。
確認すべき観点は以下の通りです。
施策が正しく動いているか
特にローンチ直後や初日のデータで確認すべきことです。
- 施策が想定される対象ユーザーのみに当たっているか?
- KPIが異常値を取っていないか
- ログが正しく発火し集計できているか
これらの観点を見ることができれば十分です。異常が見つかった場合は開発メンバーなど関係者に速やかに伝えましょう。
早期停止すべきか
施策によっては、施策開始直後からKPIが悪化してしまうケースがあるでしょう。この場合、早期停止すべきかどうかを考える必要があります。
統計的仮説検定でKPIの増減の判断を行う場合、毎日KPI差分を検定して早期停止を行うのは、教科書的なセオリーで言えばご法度です。
また、ビジネス的観点でも、早期停止は望ましくないことがあります。例えばUI改善施策の場合、序盤のKPI悪化はあくまでユーザーが新UIに不慣れなだけで、徐々にユーザーが慣れることでKPIが回復する可能性があるからです。KPIが増加している時も同様で、序盤はUIの真新しさで新UIの利用が多くKPIが増加したものの、ユーザーがある程度慣れてきて徐々にKPIのリフトが小さくなる、ということはありえるでしょう。このようなことが起きている場合、早期停止すると効果を過剰/過小に推定してしまうことになります。
では、どのような時に早期停止すべきなのでしょうか。それは、上述のような早期停止のデメリットを上回るほどのKPI悪化が起きていると関係者で合意が取れる場合です。
売上やCVRなどの購買指標が明確に下がっている、KPIの推移を見る限り回復する見込みがなさそう、ということが関係者で合意を取れる状況であるならば早期停止すべきです。
施策実施後にやること
効果測定を行う
無事に施策が終了したら効果測定を行います。施策実施前に予めまとめていおいた論点と、実際の結果を踏まえて深堀りするに値する論点や仮説について分析を行ってレポートにまとめます。
効果測定の際に気をつけることは以下の通りです。
深堀り分析に時間をかけすぎない
明確にKPIに差がついた施策であればあまり問題にならないですが、KPIの変動が小さくデータから白黒つけがたい微妙な結果に終わった施策の効果測定は注意が必要です。
Webサービスで様々なトラッキングが仕込まれており、データ分析環境が整っている状況では、様々な切り口で分析をすることができてしまいます。分析設計をやらずに「なぜ差がつかなかったのか？」という問の答えを見つけようとデータに飛び込んでしまうと、無限にクエリを書く羽目になります。
特に自分が提案した愛着ある施策や、皆の期待が大きい肝入の施策が微妙な結果だった場合は注意が必要です。高度でニッチな分析手法を繰り出す、様々な切り口で分析を行うなどして、なんとかして少しでもポジティブな点を見つけようとしがちです。
こうした取り組み自体は悪くないことですし今後の施策に活かすために必要な作業ではありますが、データアナリストの効果測定における一番の役割は、意思決定する上で必要十分なデータを素早く出す、ということです。ある程度データを見た上でKPIに差がついていなければ深堀り分析はストップし、潔く負けを認めてローンチしない、もしくは明確なネガティブがなければローンチしてしまう等、割り切ってしまったうえで早急に結果を関係者に共有し、合意形成に時間をかけたほうが良いと考えています。
次に繋がる示唆を出してスタンスを明示する
施策の結果がどうであれ、数値の出しっぱなしや施策のやりっぱなしはよくありません。施策によるユーザーの行動変化を一番細かく観察した人間として、その後の方針を提示すべきです。
成功した場合、その施策を更に拡大・改善できる箇所はないか、改善する場合伸びしろはどれくらいあるのか、その改善の優先度は高いのか、といったことを考えます。
失敗した場合、どういった形でリベンジするのか、そもそもリベンジする価値があるのか、を考えることになるでしょう。失敗した場合、改善して勝つまでやろう！という方向に向きがちですが、もうこの施策の方向性は筋が悪いからと諦めて別の施策に工数使いましょうよ、という諦めも一つ重要な示唆だと思います。
おわりに
自分が普段の業務で心掛けていることをツラツラと書かせていただきました。偉そうに書いていますが、どれもこれもお世話になった上司やメンターからのご指摘や、自身の失敗から学んだ経験ばかりで「あの時は本当にごめんなさい」という気持ちになりながら書かせてもらいました。
ざっと振り返ってみると、統計学の知識やSQLやPythonなどデータ分析の技術が活躍する場面も当然ありますが、それだけで仕事が成立することはなく、これらの知識を活用しながら他部署の方との調整を始めとした事前の準備が重要であることが分かります。
単なる作業者として依頼内容に従ってSQLを書いて数値を出して終わり、ではなく、事業計画や施策立案に携わる人たちと積極的にコミュニケーションを取り、データを用いてKPIリフトを1%でも多く増やせるよう施策内容の改良を通じて意思決定を変えていくことが、真にビジネス貢献を果たせるデータアナリストなのだろうと考えています。
参考
Discussion