ABテスト設計ガイド

1. A/Bテスト設計の狙い
2. 設計書
1. 2-1. 具体的な設計例
3. A/Bテスト設計ヒアリング時の注意点
4. A/Bテストのノウハウアーカイブ化
＊Appendix

1. A/Bテスト設計の狙い

適切なA/Bテストを行い、実行する実験の妥当性を担保し、テスト結果を最大限活用できるよう事前にプランの設計(見通し)を立てる

2. 設計書

　私は、以下の10項目について、テストオーナー（企画者）にヒアリングします。A/Bテストをする前に、これが答えられない、決まっていない実験は行わないほうが方がいいです。グダグダになり、評価も曖昧、勝者が決まらずリリースに至らないケースが多いです。適切にヒアリングすることで、テストオーナー（企画者）に「決める」事を経験をさせ、Webマーケティングスキルを上げる機会をしてください。

テストの仮説と目的
テスト対象ユーザの特定（場所、デバイス、ユーザ属性、時期など）
リフトさせたい目標KPIの決定
モニタリングすべきガードレール、デバッキング指標の決定
テストの技術的な実行方法
想定リフト値の確認　※オフライン評価の結果
テストパターン洗い出しの決定
テストに必要なサンプルターゲットとボリュームの決定
テスト結果の検証方法
テスト結果の活用方法

2-1. 具体的な設計例

例：
– テスト概要：検索アリゴリズムのモデルのA/Bテスト
– 施策　　　：前日CTR情報を特徴量として追加する

- テスト概要　　　　　：検索アリゴリズムのリランク重みづけのチューニングテスト
- 今回変更した内容　　：リランクの重みづけとして前日のCLICK数を追加する
- 対象のボリューム　　：検索利用者[1日iOSで***人くらい]
- 評価したいセグメント：検索TOP来訪者
- 仮説　　　　　　　　：前日CTRをリランク評価に活用することによって, 最新情報コンテンツの掲載RANKを上げてCTRが上がる
- 評価指標　　　　　　：検索結果のCTR
- 目標　　　　　　　　：検索結果ありページのCTR 1%リフト
- ガードレールと目標　：CTVR、継続率
- デバッグ目標　　　　：検索IMPユーザー数、0件ヒット率
- テスト結果の活用方法：施策バージョンが有意差あり判定で、リランクチューニングの変更をしたい
- 配信ロジック　　　　：自社A/Bテストツール
- 希望開始日　　　　　：2020-12-1
- AAテストの有無　　　：有
- そのほか伝えたいこと：集計単位は検索セッション単位
　　　　　　　　　　　　評価指標のモニタリングで参考にしているTableauがあれば記入してください

3. A/Bテスト設計ヒアリング時の注意点

A/Bテストの結果精度を上げるために、どのようなポイントに注意してヒアリングをするか書き出してみました。

3-1. テスト対象ユーザの特定

（場所、デバイス、ユーザ属性、時期など）

チェックポイント①：
検証内容は特定の場所に到達したすべてのユーザーが対象になるか。テスト対象の場所へ到達する経路によってユーザー行動が極端に変わる可能性があるか？
検証内容が特定の行動をしたユーザーにしか影響しない場合は、サンプル数の調整や集計時にセグメントが必要になる
チェックポイント②：
特別な外的要因を受ける可能性、パターンがあるか。テストに悪影響を与える可能性がある外的要因をテスト時に排除する手段があるか、もしくは評価時に除外することができるか。
チェックポイント③：
1つの環境（デイバス、OSなど）のテスト結果をすべてのデバイスへ適用してよいか。デバイス毎にテストをすべきか検討。他のテスト結果を参考にすることもある。「iOSアプリのA/Bテスト結果は、Androidアプリにも反映してよいか」など

3-2. リフトさせたい目標KPIの決定

チェックポイント①：
改めて、目標KPIが現状の計測方法、集計方法で適切かを確認。適当でなかったり、安易なケースがあります。テストの仮説や目的をしっかりビジネス的に理解して、目標KPIはしっかり議論しましょう。
企画者の安易な「CTRっす！」に騙されない
チェックポイント②：
回数、ユーザーなどの集計スコープの確認。評価をするという視点で集計スコープを議論してください。例えば検索の場合は、検索するキーワードが変わるまでを単位とした「検索セッション」という概念を利用したりします。
チェックポイント③：
ゴールが、テスト期間中に複数回発生する場合の集計方法の決定。会員登録のようにユーザーがサービス接触後に1回しか発生しないものと、検索やクリックのように１ユーザーがテスト期間中に複数回実行する可能性があるケースで、集計対象の計測を考慮する必要があります。0/1（CTR、CVRなど)なのか連続値（売上など）なのかの議論です。

3-3. ガードレール、デバッグ指標の決定

チェックポイント①：
目標KPIのリフトに伴い下降が想定できるKPIを洗い出しとモニタリング。強力な施策は他のアクション率（KPI）の低下を招く可能性が多々あります。軽微な下降を許容するかどうかも含めてモニタリングと許容閾値(影響度)を決定しておく必要があります。
チェックポイント②：
目標KPIの先にある事業KPIへの影響をモニタリング。
施策の目標KPIは直接的に影響するKPIを設定する必要があります。例えば特定ページのCTRなど。CLICKされた後、視聴につながる（事業KPI＝
＝KGI）かどうかをモニタリング指標に追加し（ガードレール指標）、CTRが上がったがCTVRが下がっていないことを確認してください(“無料”や”今すぐ”のような強い訴求でCTRだけを上げ、本質的なユーザー体験の向上につながらない施策を行わない
チェックポイント③：
AAテストの実施有無。サンプル数の同値確認などを行い、テストが正常に行われていることをデバッグできる指標の確認を行う。
検証時に実はテストを「スプリットラン」できていないという事はそこそこ起きます。A/Bテストの結果は「ユーザーの声という」とても強い説得手段になり得るからこそ、適切なテストを行われている必要があります。データサイエンティストがここを疎かにすると後々痛い目にあいます。

3-4. スプリットランの技術的な実行方法

チェックポイント①：
適切な同時スプリットランが行われていることを確認する。ランダムであることの確認。必要であれば検証時にも役立つAAテストを同時に走らせることも検討
チェックポイント②：
CDN、キャッシュ、除外設定などの確認。ユーザー体験と集計データが対をなしているか確認。
チェックポイント③：
テスト期間中は同じユーザに同じパターンを体験し続けることができているかの確認。単純ランダム配信(テストに出会うたびにランダムに振り分けられる）ではなく、一度接触したテストパターンをテスト期間中には同じパターンに出会う仕組みになっているか確認。

3-5. 想定リフト値の確認

オフライン評価の結果の活用

チェックポイント①：
目標KPIの実績と想定リフト率をオフライン評価で見通す。A/Bテストはこれくらい良くなるという目標リスト値が無いと検定が出来ません。対象(ターゲティング／セグメント）と目標KPIの現状の値と目標値が明確にしましょう。これがないと適切なサンプルサイズの算出もテスト後の評価もできません。テスト結果に満足がいかない際に深堀分析ができないケースや、想定以上に原因究明に時間がかかるのは「オフライン評価」をしていないため。「オフライン評価」とは過去の実績を使ったシミュレーションです。テスト結果がこうなるというシミュレーションを事前に行いましょう。
チェックポイント②：
ターゲットユーザー、アクションが明確にしておくと深堀分析時に役立つ。施策が特定の行動を行うユーザーに大きく影響を与える場合は、適切なセグメントに絞って施策の評価を行う必要”も”あります。
チェックポイント③：
オフライン評価の振り返り、精度上げも視野に入れる。オフライン評価の確からしさや因果関係の確認をオンライン結果と突き合わせを視点に入れる。オンラインテストの結果データの蓄積を継続的に行い、オフライン評価の精度を高める。

3-6. テストパターン洗い出しの決定

チェックポイント①：
コントロールグループに対して、どのようなパターンを準備すべきか施策考案者と一緒に検討。機能/UIの有無の評価であればAB。できる限りABテストの確からしさを上げるためにAAテストを走らせる。他にも比較すべきパターンがあるか議論する

チェックポイント②：
A/Bテストで閾値、係数の最適解を導きたい場合は、オフライン評価の結果を利用しオンラインテストすべきパターンを適切あぶりだす。必ずオフラインテストを行い、どういうレンジでどういうパターンをオンラインテストすべきか判断する
例：モデルの計算式「Y=A*X のAが{1,2,3,4,5} 」のどれが一番良いかをオンラインテストで探す。本当に{1,2,3,4,5}というパターンが適切か。
チェックポイント③：
A/Bテストに複数の可変部分がある場合のテストパターンの洗い出しについて。MultivariateTestを行う際はパターンの適切な洗い出しと相関性の有無、サンプルサイズ（テスト期間）を考慮して1テストとして行うべきか、2つのテストにわけるか検討する

3-7. テストに必要なターゲットボリュームの決定

チェックポイント①：
前述の対象ユーザー数と目標KPIと想定リフトから必要なサンプルサイズを算出します。必要サンプルサイズはテスト期間に影響します。目標KPIが現状0.1%だとして、0.2%にリフトさせるようなA/Bテストの場合は大きなサンプルサイズが必要になることがあります。
その場合は、A/Bテストをすべきか検討してください。現実的ではないサンプルサイズ（テスト期間）※例えば1年間かかるなど※ が必要になった場合は、オンラインテストをせずにオフライン評価の結果を元にリリースをするか検討をすべきです。
　どうしてもサンプルサイズ（テスト期間）を準備できない場合にどうするかを企画者と事前に議論しておく必要があります。A/Bテストは適切に行う必要があり、品質の担保はデータサイエンティストが行うべきです。ビジネス担当者は、どちらが良いか答えが知りたいだけで、出来ない事はできない。違う方法を一緒に見つけていく事も大事です。

3-8. テスト結果の検証方法

チェックポイント①：
事前にテスト後の評価方法まで必ず決めておく。評価方法を確認せずにテストを行うと、(多くの場合は勝ち負けが出ないため）負けた場合になぜ負けたかを深堀分析をする必要が出てきます。その時に分析に必要なデータや手段がない可能性があります。想定できる想定外のテスト結果から考えられるネクストアクションを洗い出し必要なものが準備できているか確認する

チェックポイント②：
データクレンジングの必要有無を確認しましょう。A/Bテストなので無作為に全データをそのまま利用し判断をすると痛い目にあうことがあります。テストの信頼性を阻害するデータが紛れ込んでいないかクリーニングの必要有無をチェックしてください。可能であればプロジェクトごとにノウハウをためて除外すべきデータを排除する機能を準備しておく
※この「除外」がABテストハックのようにならない事も重要です。
チェックポイント③：
テストに影響しそうな因子の洗い出しとノウハウアーカイブ化。構造化された影響因子やテスト方法のノウハウを知見として残していくこと。テスト毎にまとめるのではなく、具体的な内容をノウハウとしてリスト化していくことで利活用実績を高める。1回のA/Bテストで多くの知見を得ることがあります。それはテストの仕方や評価方法についてもいえる事。次テストをする際に、再利用できるようにサービスならではA/Bテストナレッジは誰もが読み書きできる環境を準備しておきましょう。

3-9. テスト結果の活用方法

チェックポイント①：
仮設通りテストに勝利し有意差が出た場合、パターンが2個以上あり両方とも勝利した場合など、テスト結果毎にネクストアクションを決めておく。テスト結果は常に期待を裏切ります。ABテスト設計の肝は想定外の結果に対してネクストアクションを決めること。逃げずにテスト事前に想定外の事態に対してネクストアクションを決めてください

チェックポイント②：
有意差がでないケースのネクストアクションを必ず準備する。ABテストは勝敗の決着が付かないことが多いです。全適用するリスクを可視化しリリース可否の判断をしましょう。軽率な判断がサービス全体のユーザー体験を損なう可能性があります
チェックポイント③：
テストの勝敗だけではなく、様々はKPIの相関、因果、回帰の有無の確認、勝利時の背景などの理解を行い、次の施策に役立てる分析設計する。テスト結果は多くの情報を我々グロースハッカーに提供します。活用できる情報をノウハウとして明文化（言語化）し、次の施策のアイデアリストしてアーカイブしてください。テストに負けてもテストの結果を得られた事実は無限の価値があります

チェックポイント④：
有意差が出て、分析結果が妥当と判断された結果を100%適応した後で、プロジェクトKPI（KGI）への貢献度の可視化を行う。オンラインテストはあくまでも施策の確からしさの判定であり、事業インパクトは100%リリースした後に可視化をする必要があります。施策によってはA/Bテストの結果が大成功であっても、全適用後にどれくらいのインパクトがあるかを確認することは忘れない

※文中にオンラインテストというフレーズがあるかもしれませんが、オンラインテスト＝A/Bテストのことです。

4. A/Bテストのノウハウアーカイブ化

A/Bテスト設計項目と被りますが、以下のカテゴリー毎にルールや注意点、やり方をまとめると再利用できます。

例：

テスト前の準備編
データクレンジング
異常値除外
オフライン評価
教師データの準備
有意差検定視点
深堀分析視点
目標KPIとガードレールKPI、デバッグKPI
テストバリエーションの洗い出し

＊Appendix

GA4とGoogle Optimizeの連携

GA4とGoogle Optimizeの連携方法について説明しています。プロパティのリンクや、目標の設定など管理画面の設定内容と。GAとGA4の違いなどを説明

Google Optimizeのテスト期間とサンプル数について

ベイズ推定を用いて有意差検定を行うGoogle Optimize。少ないサンプル数でも優劣をつけるのが得意です。実験の有意差検定には、テスト期間とサンプル数がとても重要な要素です。

GA4/ABテストツールの選定

2023年9月30日をもって、Google Optimizeはサービス終了します。GA4と連携するABテストツールとして、候補に挙がるサービスをどのように選定していくかがとても重要

ランディングページのURLパラメータをリンク先に引き継ぐJavaScript

特定のサービスのリード獲得のためのラインディングページ。広告を出稿することもあります。その際に、Web2Appの遷移や、別ドメインに立てたランディングページの場合、広告のトラッキングコードがコンバージョンまで引き継げないケースがある。ランディングページの特定のURLパラメータを引き継ぐJavaScript