見出し画像

A/Bテストは事前準備で決まる!?LIFULLのA/Bテスト事前設計の取り組み

こんにちは。LIFULLの梁取(やなとり)です。
私は不動産・住宅情報サイト「LIFULL HOME'S」でユーザーデータを統合するCDP(Customer Data Platform)の統括と、プロダクト・マーケティング領域のデータ活用推進を担当するチームで、マネージャーをしてます。

この記事では、A/Bテストの結果の信頼性を担保し、意思決定のスピード・精度を向上させる「A/Bテストの事前設計フレームワーク」導入の取り組みを紹介します。

次のような課題をお持ちの方に参考にしていただければ幸いです。

  • 現在A/Bテストを実施しているが、スムーズに意思決定できずに困っている

  • A/Bテストの考え方を色々と調べたが、ベストプラクティスに出会えず困っている



A/Bテストとは

A/Bテストとは無作為に抽出したユーザーを2つの集団に対して均等に割り当て、片方にだけ変更を加えそれによる効果の有無を統計的に効果検証する手法です。


LIFULL HOME’SにおけるA/Bテストの位置付け

以前こちらの記事でも「市場学習の最大化」という取り組みを紹介しましたが、LIFULL HOME'Sで実施しているA/Bテストは市場学習という位置付けになります。

LIFULLはプロダクトマネジメントにおける「継続的な製品発見・製品開発」を発展させ「市場学習の最大化」という取り組みを強化しています。

これは端的にいえば市場学習=PDCAの回数を大幅に増やしていこうという考えです。
図中にあるNetflix、Amazon、Google等では、年間の市場学習回数が数千〜数万とされています。この状態を目指していきたいと考えています。

LIFULLが取り組むプロダクトマネジメント&賃貸プロダクトにおけるグロース事例(前編)より


市場学習回数を最大化するために必要なのが、以下の2点です。

  • プロダクトの課題発見プロセスの効率化

  • 施策実施前後の意思決定プロセスの効率化

プロダクトの課題発見プロセスを効率化する取り組みは、こちらの記事の「プロダクトアナリティクスの導入」の箇所にて紹介していますので、ご覧ください。

今回紹介する「A/Bテストの事前設計フレームワーク」は、施策実施前後の意思決定プロセスの効率化に大きく貢献しました。


LIFULL HOME’SにおけるA/Bテストの課題

LIFULL HOME’Sでは施策を実施する際、ほとんどのケースでA/Bテストを実施してますが、以下のような課題がありました。

  •  A/Bテストの結果が悪かったときに、何か良かった点はないか?を深掘ってしまった

    •  いいところだけを取り出して効果があったという主張をしていた(チェリーピッキング問題)

  • A/Bテストの結果をもとに次回アクションについて議論したものの、プロチームの関係者間で意見がバラバラで、意見がまとまらなかった

  • アナリストに相談したら、このA/Bテスト自体に意味がないと言われた

  • サンプルサイズの問題でいつまでたってもテスト期間が終わらなかった

  • A/Bテストが終わったものの、集計してみるとそもそもテストがうまくできてなかった(AとBの比率が均等になっていなかった。)


A/Bテスト成熟度モデル

上記の課題を整理してみると、ほとんどがA/Bテスト実施後に発生するものだったため、A/Bテストの実施前に何か基準を設けることで解決できるのではないか?と考えました。

解決のヒントを探るために、A/Bテストの有識者の方々が絶賛する「ABテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは(通称 カバ本)」を読み「A/Bテストの成熟度モデル」を知りました。

「ABテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは」から引用

当時のLIFULL HOME'Sはプロダクトごとにばらつきがあったものの、全体で見るとCrawlフェーズでした。

A/Bテストの実施前にテストの目的背景、解決したい課題と施策の整合性、テスト設定、評価指標・判断軸のフレームワークを作ることで、Walkフェーズの「A/Bテスト結果の信頼性の確立」につながるんだと理解できました。


A/Bテストの結果の信頼性を担保し、意思決定のスピード・精度を向上させる「Experiment Design Doc(EDD)」とは

A/Bテストの事前設計フレームを作成するにあたってはメルカリさんの「メルカリにおけるA/Bテスト標準化への取り組み」の記事を参考にさせてもらい、LIFULL流のExperiment Design Doc(EDD)を作成しました。

※ Experiment Design Docは以後EDDと表記します。

Background

テストの目的、課題、施策、仮説に一貫性があるように記載します。Howが先行してしまって施策が課題を適切にとらえていないケースが発生しないように注意します。

Test Setting

テスト対象となるターゲットユーザーの条件や割り当て手段、割当て率やサンプルサイズなどを記入します。

Metrics Details

テストの評価をするための指標で3つのメトリクスを定義します。

  • Goal Metrics

    • 施策に直接影響を及ぼす指標を設定します。施策実施箇所とCVポイントが遠い場合は、CVRなどの指標を置かないように注意が必要です。

      例えば、LIFULL HOME’Sの物件詳細ページ閲覧数を上げるために、検索結果ページに施策を打った場合、検索結果ページから物件詳細ページへの遷移率が指標になります。

  • Guardrail Metrics

    • CVRや売上などビジネス観点やページの表示スピード、リテンション等UXにおいて棄損したくない指標を設定します。

  • Debugging Metrics

    • 事前に設計した通りにテストが実施されているか?をモニタリングするための指標を設定します。

    • 具体的にはSample Ratio Mismatch (SRM)と呼ばれる事前に割り当てを予定していたAとBのサンプル数、比率が異なる事象が起こっていないか?を確認します。

    • SRMについての詳細はこちらの論文に記載されているので、興味があればご覧ください。

How to Evaluate Metrics

各メトリクスをどのような統計手法を用いて検証するか?を記載します。

カイ二乗検定は最も馴染みのある仮説検定手法である一方で、一定のサンプルサイズが集まらないと検定が難しいという課題があります。LIFULL HOME'Sにおいてはこれらの課題を解決するためにサンプルサイズが小さくても検定でき、かつ直感的でビジネスサイドのメンバーも理解しやすいという理由からベイズ推定を用いるようになりました。

Judgment Criteria&Action plan

Goal MetricsとGuardrail Metricsをもとに図のような2✕3のマトリクスでGo・No Goの基準を決めておきます。
ここを決めておくことで施策終了後に議論が割れることもなくなり、スムーズな意思決定につながります。


Experiment Design Doc(EDD)導入までの取り組み

まず、全サービス企画職(※LIFULLではプロダクトの企画を担う職種を「サービス企画」名称で定義しています。)が集まる場でEDD導入の目的・背景とEDDの概要について説明した後、企画立案の際はConfluenceに用意したEDDのテンプレート項目を記載してもらうようにお願いしました。

ConfluenceのEDDテンプレート

それから各プロダクトマネージャーにEDD推進担当を任命してもらい、プロダクトごとにEDD導入の課題や知見を共有する機会をつくりました。

その結果、3ヶ月でA/Bテストを実施している全てのプロダクトでEDDを導入することができました。


Experiment Design Doc(EDD)導入後の変化

SRM発生を早期に発見し、対処することができた

Debugging MetricsとしてSRMが起きていないか?をモニタリングするようにしたことで、実際にSRMが発生しても早期に対処できるようになりました。

施策実施前における判断基準の合意形成がスムーズになった

プロダクトを横断した施策実施をするケースの場合、事前にEDDの内容を複数のプロダクトチームに共有しておくことで「Guardrail Metricsとして〇〇の指標も見てほしい」といったコミュニケーションができるようになり、施策効果の判断基準の合意形成がスムーズになりました。

施策実施後の意思決定までのスピードが上がった

定量データとして計測できてないのが残念ですが、「EDDを導入したことで指標や判断基準が明確になり、プロダクトチームで施策実施後の意思決定しやすくなった(≒意思決定のスピードと精度が向上した)」という現場の声を聞く機会が増えました。

経営ボードとのコミュニケーションがスムーズになった

以前のA/Bテストはプロダクトチームによってバラバラな指標や手法を用いて実施していたため、プロダクトマネージャー・プロダクトオーナーの視点ではA/Bテストそのものや成果に対する確信が持てない課題がありました。EDD導入後はプロダクトチームが実施する検証プロセス自体に確証が持てるようになり、経営トップ・取締役などの経営ボードとのコミュニケーションが円滑に進められるようになりました。


おわりに

EDDの導入をしたことで、先程紹介した「A/Bテストの成熟度モデル」のWalkフェーズまで進むことができました。今後はRunフェーズにむけて進んでいくとともに、各施策とEDDを紐づけたDBのようなものを作って、過去の知見を活用できる環境を作っていきたいです。

最後まで読んでいただきありがとうございます。
この記事を読んでくださった方はプロダクトをグロースしていくために日々A/Bテストに取り組まれていることだと思います。

EDDはA/Bテストの課題を解決するためにとても重要なフレームワークなので、弊社のような課題をお持ちの場合は是非参考にしていただければ幸いです。

LIFULLでは一緒にプロダクトをグロースしてくれる仲間を募集しています!
LIFULLの取り組みに興味をお持ちの方は、是非以下の求人をチェックしてみてください!


この記事が気に入ったらサポートをしてみませんか?