A/Bテストとは？Webサイト・LPでのやり方と失敗しない進め方 16.08.02  （更新: 26.08.20）

A/Bテスト（ABテスト）とは、WebサイトやLP、広告などに2つ以上のパターンを用意し、ユーザーの反応を比較して、より成果につながる案を確かめる方法です。見出しや画像、CTA、入力フォームなどを感覚だけで変更するのではなく、実際の行動データをもとに改善を進められる点が大きな特徴です。

ただし、A案とB案を一定期間表示するだけでは、信頼できる結果になるとは限りません。複数の要素を一度に変更したり、十分なサンプルが集まる前に終了したりすると、偶然の差や別の要因をテストの効果と誤認することがあります。アクセスやコンバージョンが少ないページでは、A/Bテスト以外の方法を選んだ方がよい場合もあります。

この記事では、A/Bテストの仕組みとWebサイト・LPでのやり方から、仮説の立て方、MDE、サンプル数、実施期間、有意差の判断、ツールの選び方、GA4での計測まで順を追って解説します。これからA/Bテストを始める方はもちろん、現在のテスト方法や判定方法に問題がないか確認したい方も参考にしてください。

A/Bテストとは

A/Bテストとは、WebサイトやLP、広告などに異なるパターンを用意し、ユーザーの反応を比較する検証方法です。対象となるユーザーを複数のグループへ無作為に振り分け、同じ期間にA案とB案を表示します。

たとえば、LPのCTAを「お問い合わせはこちら」から「無料相談を申し込む」へ変更し、どちらの方が多くクリックされたかを比較します。ほかにも、商品の購入率、問い合わせ完了率、広告のクリック率など、目的に応じた指標を設定できます。

A/Bテストの目的は、単に見た目のよい案を選ぶことではありません。変更した内容がユーザーの行動や成果にどのような影響を与えたかを確かめ、次の改善へ生かすことが目的です。

「A/B」という名称ですが、必要に応じてA案・B案・C案のように3つ以上のパターンを比較する場合もあります。一般には「ABテスト」と表記されることもありますが、この記事では「A/Bテスト」に統一します。

A/Bテストの仕組み

A/Bテストでは、元のページをA案、変更したページをB案として、訪問したユーザーを50％ずつ振り分ける方法がよく使われます。必ずしも均等に分ける必要はなく、影響を抑えたい場合は、最初にB案を表示する割合を少なくすることも可能です。

たとえば、1万人の訪問者をA案とB案に5,000人ずつ振り分け、A案から100件、B案から125件の申し込みが発生した場合、CVRはA案が2％、B案が2.5％です。ただし、この数値だけで直ちにB案を採用できるとは限りません。偶然によって生じた差ではないかを判断するため、必要なサンプル数や実施期間、有意差も確認します。

また、同じユーザーが訪問するたびに異なるパターンを表示すると、内容が変わって混乱を招くことがあります。そのため、実施期間中は原則として、同じユーザーに同じパターンを表示する仕組みが必要です。

変更前と変更後を別の時期に比較する方法とは異なり、A案とB案を同じ期間に表示することで、曜日、季節、広告施策といった外部要因の影響を受けにくくできます。

A/Bテストを行うメリット

WebサイトやLPを改善するときは、「目立つ色にした方がよい」「文章を短くした方が読まれやすい」といった意見が出ることがあります。しかし、担当者の経験や好みだけでは、どちらの案が実際の成果につながるかを判断できません。

A/Bテストを行うことで、次のようなメリットが期待できます。

ただし、A/Bテストで成果の高かった案が、すべてのユーザーや時期に対して常に有効とは限りません。対象ページ、流入元、実施期間、ユーザー層などの条件とあわせて結果を見ることが重要です。

A/Bテストと多変量テストの違い

A/Bテストと似た検証方法に、多変量テストがあります。どちらも複数のパターンを比較しますが、同時に検証する要素と組み合わせ方が異なります。

たとえば、見出しを2種類、画像を2種類、CTAを2種類用意した場合、多変量テストでは「2×2×2」で8通りの組み合わせが生まれます。検証する要素が増えるほどパターン数も増えるため、A/Bテストより多くのアクセスとコンバージョンが必要です。

アクセス数が限られているWebサイトや、初めて検証を行う場合は、まずA/Bテストで変更箇所を1つずつ試す方が現実的です。複数の要素が影響し合うページで、十分なデータ量を確保できる場合は、多変量テストも選択肢になります。

A/Bテストで検証できるWebサイト・LP・広告の要素

A/Bテストでは、WebサイトやLPの文章・画像・レイアウトから、広告のクリエイティブや広告文まで、ユーザーの行動に影響するさまざまな要素を検証できます。

ただし、目についた箇所を手当たり次第に変更しても、成果につながるとは限りません。離脱が多い箇所や、問い合わせ・購入に近い箇所を確認し、改善による影響が大きいと考えられる要素から検証することが重要です。

ここでは、Webサイト・LP・広告でA/Bテストの対象になりやすい要素と、検証するときに確認したい指標を紹介します。

ファーストビュー・見出し・CTA

WebサイトやLPでは、訪問者が最初に目にするファーストビューや、申し込みにつながるCTAが主な検証対象になります。特にLPは、ファーストビューを見た段階で続きを読むか、ページを離れるかを判断されることが多いため、優先して検証したい箇所です。

たとえば、「業務効率化を支援します」という機能中心の見出しと、「毎月の集計作業にかかる時間を減らす」という課題中心の見出しを比較すれば、どちらの訴求が対象ユーザーに伝わりやすいかを確認できます。

ファーストビューを検証する場合は、スクロール率やCTAのクリック率だけでなく、最終的な問い合わせ・購入まで確認します。クリック率が上がっても、その後のコンバージョンが増えていなければ、成果につながる改善とは判断できないためです。

また、見出し、画像、CTAのすべてを一度に変更すると、どの要素が結果に影響したのか分かりにくくなります。変更による影響を確かめたい場合は、基本的に検証する要素を1つに絞ります。

実績・料金表・入力フォーム

商品やサービスに興味を持ったユーザーが、申し込みや購入を決める前に確認する情報もA/Bテストの対象になります。実績や料金の見せ方、入力フォームの使いやすさは、比較検討からコンバージョンへ進む段階に影響する要素です。

実績や料金表では、該当箇所を見た人のCTAクリック率やコンバージョン率を確認します。料金表から特定のプランを選ぶ仕組みがある場合は、プランごとの選択率や、その後の申し込み率も評価対象になります。

入力フォームでは、フォームを開いた人の数だけでなく、入力を始めた人、途中で離脱した人、送信を完了した人の割合を見ることが重要です。項目数を減らして完了率が上がっても、商談に必要な情報が不足して対応工数が増える可能性もあるため、問い合わせの件数と質の両方を確認します。

なお、料金そのものをA案とB案で変える場合は、同じ商品を異なる価格で見たユーザーへの対応や、既存顧客との公平性も考える必要があります。まずは料金表の分かりやすさや、価格の根拠が伝わる説明から検証する方が実施しやすいでしょう。

広告クリエイティブ・広告文

リスティング広告やディスプレイ広告、SNS広告でもA/Bテストを実施できます。広告は限られた文字数や表示時間の中で興味を持ってもらう必要があるため、画像や文章の違いがクリック率やコンバージョン率に影響することがあります。

広告の評価では、クリック率だけで採用案を決めないことが重要です。興味を引く広告でクリック数が増えても、LPの内容と一致していなければ、コンバージョンにつながらず広告費だけが増えることがあります。

広告の目的に応じて、クリック率、クリック単価、コンバージョン率、顧客獲得単価、売上、ROASなどを確認します。問い合わせを目的とする場合は、問い合わせ後の商談化率や受注率まで追えると、件数だけでは分からない広告の質も判断できます。

また、広告クリエイティブを比較するときは、配信対象、予算、入札方法、配信期間などの条件をできるだけそろえます。広告媒体による自動的な配信の偏りもあるため、可能であれば媒体に用意された実験機能を使用します。

A/Bテストが有効なケースと向いていないケース

A/Bテストは、WebサイトやLPを改善するうえで有効な方法ですが、どのページでも実施すればよいわけではありません。検証する目的が曖昧な場合や、必要なデータを集められない場合は、A案とB案に差が出ても、それが変更による効果なのか偶然なのかを判断できません。

A/Bテストが適しているのは、一定数のユーザーが継続して訪れ、改善したい指標と検証する仮説が決まっているケースです。一方、アクセスやコンバージョンが少ないページ、短期間しか公開しないキャンペーン、修正すべき問題が明らかなページでは、別の方法を選んだ方が早く改善につながることがあります。

A/Bテストを実施すること自体を目的にせず、信頼できる結果を得られる条件がそろっているかを事前に確認することが重要です。

A/Bテストを実施しやすい条件

A/Bテストを実施する前に、検証の目的、必要なデータ量、計測環境などを確認します。次の条件がそろっていれば、テスト結果をその後の改善へ生かしやすくなります。

「月間何アクセスあれば実施できる」という共通の基準はありません。必要なサンプル数は、現在のCVR、検出したい改善幅、A案とB案への配分などによって変わります。月間アクセスが多くてもCVがほとんど発生していなければ、判定までに長い期間が必要です。

また、フォームが送信できない、スマートフォンでボタンが押せない、料金表示が間違っているといった明らかな不具合は、A/Bテストを行わずに修正します。法令対応、セキュリティ対策、誤解を招く表示の訂正なども、成果を比較してから判断するものではありません。

アクセスやコンバージョンが少ない場合の代替方法

アクセスやコンバージョンが少ないページでA/Bテストを行うと、A案とB案へデータが分散し、判定できるまでに長い時間がかかります。数件のコンバージョン差だけで採用案を決めると、偶然の変動を改善効果と誤認する可能性があります。

必要なサンプルを集めにくい場合は、A/Bテストに限定せず、定量データとユーザーの声を組み合わせて改善案を考えます。

最終的なコンバージョンが少ない場合は、CTAのクリック、料金表の閲覧、フォーム開始、カート追加など、コンバージョンに近い途中の行動を指標にする方法もあります。ただし、途中の行動が増えても、問い合わせや売上が増えるとは限りません。可能な範囲で最終成果との関係も確認します。

特に、成約までの期間が長いBtoBサービスや高額商品では、問い合わせ件数だけでなく、商談化率、受注率、売上などを個別に追う方が適している場合があります。アクセスが少ないから改善できないのではなく、データ量と事業の特性に合った検証方法を選ぶことが大切です。

A/Bテストのやり方を6つの手順で解説

A/Bテストは、A案とB案を作って表示するだけでは正しく実施できません。テストを始める前に、改善する目的、検証する仮説、評価指標、必要なサンプル数、終了条件まで決めておく必要があります。

途中経過を見て都合のよいタイミングで終了したり、結果が出なかったテストを記録せずに終えたりすると、誤った判断や同じ検証の繰り返しにつながります。

ここでは、WebサイトやLPでA/Bテストを行う流れを、準備から結果の活用まで6つの手順に分けて解説します。

1．改善する目的とKPIを決める

最初に、A/Bテストによって何を改善したいのかを決めます。「ページを見やすくする」「デザインをよくする」といった曖昧な目的では、どちらの案を採用するか判断できません。

問い合わせ、商品購入、資料請求、会員登録など、事業上の成果につながる目的を設定し、その達成度を判断するKPIを決めます。

評価の中心となる指標は、原則として1つに決めます。複数の指標から都合のよい結果だけを選ぶと、正しく判定できないためです。

そのうえで、CTAのクリック率やフォーム開始率などを補助指標として確認します。問い合わせ完了率が変わらなかった場合でも、どの段階の行動に変化があったかを確認できます。

売上、利益、問い合わせの質、解約率など、悪化してはいけない指標も決めておきます。たとえば、問い合わせ件数が増えても、対象外の問い合わせばかり増えた場合は、事業上の改善とはいえません。

テスト前のCVRや売上など、現在の数値も同じ条件で確認しておきます。この基準値は、必要なサンプル数や検出したい改善幅を決める際にも使用します。

2．データから課題を見つけて仮説を立てる

次に、アクセス解析やユーザーの声から、成果を妨げている可能性がある箇所を探します。担当者の好みや思いつきだけで変更案を作るのではなく、確認できた事実をもとに仮説を立てます。

仮説は、次のように「確認できた事実」「考えられる原因」「変更案」「期待する行動」をつなげて作ります。

この段階では、原因を断定する必要はありません。A/Bテストは、仮説が正しいかを確かめるために行います。ただし、データと関係のない変更や、結果が出ても次の判断に生かせない変更は優先しない方がよいでしょう。

3．比較する要素を1つに絞ってA案・B案を作る

検証する仮説が決まったら、現在のページをA案、仮説を反映した変更案をB案として用意します。変更による影響を判断しやすくするため、基本的には比較する要素を1つに絞ります。

たとえば、B案で見出し、画像、CTA、料金表をすべて変更して成果が上がっても、どの変更が影響したのか分かりません。複数の要素を同時に変更したい場合は、ページ全体の新旧比較として実施できますが、個々の要素の効果は判断できないことを理解しておく必要があります。

一方で、仮説と関係のない小さな違いだけを作ることも避けます。理由なくボタンの色合いをわずかに変えるより、ユーザーの不安や判断に影響すると考えられる文章・情報・導線を検証する方が、次に生かせる結果を得やすくなります。

A案とB案を作成したら、文章、画像、表示位置、対象ページなどの違いを記録します。公開後に内容が変更される可能性がある場合は、画面のキャプチャーやテスト開始時の原稿も残しておきます。

4．実施方法とユーザーの振り分け方を決める

A案とB案が完成したら、外部のA/Bテストツール、自社サイトへの実装、広告媒体の実験機能などから実施方法を選びます。実施方法は、対象ページ、変更内容、社内の技術体制、予算、必要な計測機能によって判断します。

あわせて、テスト対象となるユーザーと振り分け条件を決めます。

開始前には、パソコンとスマートフォンの両方で表示や操作を確認します。A案とB案で計測イベントが発生するか、フォーム送信や購入を完了できるか、同じユーザーに同じ案が表示されるかもテストします。

ページが一瞬切り替わる、表示速度が低下する、レイアウトが崩れるといった問題があると、変更内容ではなく実装上の不具合が結果に影響します。本番公開前の動作確認を省かないことが重要です。

5．サンプル数・実施期間・停止条件を決める

A/Bテストを開始する前に、判定に必要なサンプル数、最低限の実施期間、テストを終了する条件を決めます。B案が一時的に優勢になった時点で終了すると、偶然の差を改善効果と誤認する可能性があります。

必要なサンプル数を考えるときは、主に次の項目を使用します。

実施期間は、必要なサンプルを集められる見込みと、曜日による利用傾向を考慮して設定します。平日と休日で行動が異なるサイトでは、特定の数日間だけで判定しないようにします。また、大型キャンペーン、価格変更、在庫切れ、システム障害などが予定されている期間は、通常時と条件が変わる可能性があります。

停止条件には、「必要なサンプル数に到達し、最低実施期間を経過した時点で判定する」といった通常の終了条件に加え、計測不備や重大な表示崩れが発生した場合の中止条件も設けます。

途中経過を何度も確認し、望ましい結果が出た時点で終了する方法は避けます。必要なデータを現実的な期間で集められない場合は、A/Bテストを続けるのではなく、ユーザーテストやアクセス解析など別の方法を検討します。

6．結果を判定して採用案と次の施策を決める

事前に決めた終了条件を満たしたら、A案とB案の結果を比較します。最初に、対象ユーザー数、振り分け比率、計測漏れ、テスト期間中の障害やキャンペーンなどを確認し、データに問題がないかを確かめます。

問題がなければ、最初に決めたKPIを中心に結果を判定します。有意差があるかだけでなく、得られた改善幅が実際の売上や問い合わせに与える影響、B案を実装・維持する費用も確認します。

全体では差がないのに、結果を見た後から「スマートフォンだけ」「広告流入だけ」など細かく分けると、偶然よく見えるグループが見つかりやすくなります。ユーザー層別に判定したい場合は、できるだけテスト前に対象と評価方法を決めます。テスト後に見つけた傾向は、新たな仮説として次回あらためて検証します。

最後に、テストの目的、仮説、A案とB案の内容、対象者、実施期間、サンプル数、結果、採用した案、判定理由を記録します。差が出なかった結果も残すことで、同じテストの繰り返しを防ぎ、次の施策に役立てられます。

A/Bテストは1回で完了する施策ではありません。結果から新しい仮説を立て、優先度の高い箇所を一つずつ検証することで、WebサイトやLPの改善を続けていきます。

A/Bテストのサンプル数・期間・有意差の考え方

A/Bテストでは、B案のCVRがA案を上回っただけで、改善に成功したとは判断できません。ユーザー数やコンバージョン数が少なければ、偶然によって差が生じることがあるためです。

信頼できる結果を得るには、検出したい改善幅から必要なサンプル数を求め、最低実施期間と停止条件をテスト前に決めます。終了後は、有意差だけでなく、改善幅、売上への影響、データのばらつきも確認します。

必要なデータ量に一律の基準はありません。現在のCVR、検出したい差、A案とB案の配分などによって変わるため、「何人集めるか」「いつまで実施するか」「何をもって採用するか」をテストごとに設定します。

MDEから必要なサンプル数を考える

MDEとは「Minimum Detectable Effect」の略で、A/Bテストで検出したい最小の改善幅を指します。小さな差まで見つけようとするほど、必要なサンプル数は多くなります。

たとえば、現在のCVRが2％の場合、B案によって2.4％まで改善するかを確かめたいとします。この場合の改善幅は、絶対値では0.4ポイント、相対値では20％です。

サンプルサイズ計算ツールによって、MDEを絶対値で入力する場合と相対値で入力する場合があります。「0.4ポイント」と「20％」を取り違えると、必要なサンプル数が大きく変わるため、入力形式を確認してください。

必要なサンプル数は、主に次の条件から計算します。

例として、現在のCVRが2％、検出したいCVRが2.4％、有意水準5％、検出力80％、A案とB案を50％ずつ配信する条件では、単純な2群比較で各案に約2万1,000人、合計約4万2,000人が必要になる計算です。

※必要なサンプル数は、片側・両側検定などの計算条件や使用するツールによって異なります。上記は必要なデータ量の大きさを示す目安です。

MDEを半分にして、さらに小さな改善まで検出しようとすると、同じ条件では必要なサンプル数がおおむね4倍になります。わずかな変化を検出するためにテストを長期間続けても、得られる利益より実施コストの方が大きくなる可能性があります。

MDEは「できるだけ小さくする数値」ではありません。改善によって増える売上や問い合わせと、制作・実装・運用にかかる費用を考え、事業上、採用を検討する価値がある差を設定します。

サンプルサイズ計算ツールを使う場合は、表示された人数が「1案当たり」なのか「A案とB案の合計」なのかも確認します。また、ユーザー単位で振り分ける場合は、セッション数ではなく、原則としてテスト対象となったユーザー数を基準にします。

実施期間と停止条件を事前に決める

必要なサンプル数を計算したら、1日当たりの対象ユーザー数から、データが集まるまでの期間を見積もります。合計4万2,000人が必要で、対象ページへの訪問者が1日1,000人であれば、単純計算では約42日かかります。

ただし、必要人数に到達すれば、いつ終了してもよいわけではありません。曜日、給料日前後、繁忙期、広告配信、セールなどによってユーザーの行動が変わるため、サイトの利用周期を含む期間を設定します。

サンプル数に到達しても実施期間が短すぎる場合は、特定の曜日や一時的な広告流入に偏っている可能性があります。反対に、予定していた期間が過ぎても必要なサンプル数に達していなければ、十分な検出力を確保できません。

最大実施期間までに必要なデータが集まらなかった場合は、結果を無理に勝敗へ結び付けず、「今回の条件では判定できなかった」とします。そのうえで、MDE、対象ページ、評価指標、テスト方法を見直します。

テスト中は、可能な限り次のような条件を変更しないようにします。

やむを得ず条件を変更した場合は、変更した日時と内容を記録し、結果への影響を確認します。大きな変更で比較条件を保てなくなった場合は、そのまま継続せず、テストのやり直しも検討します。

また、広告を見てから数日後に購入する商品や、問い合わせ後に商談へ進むサービスでは、成果が確定するまで時間がかかります。テスト終了直前に参加したユーザーの成果が反映されるまで待ってから、最終結果を判定します。

有意差と途中で結果を見る場合の注意点

A/Bテストにおける有意差とは、確認された差を、あらかじめ設定した基準にもとづいて「偶然だけでは説明しにくい」と判断できる状態を指します。

一般的な検定で使われるp値は、「A案とB案に本当の差がない」と仮定したときに、今回と同じか、それ以上に極端な差が観測される確率を表します。事前に有意水準を5％と設定し、p値が0.05未満になった場合は、統計的に有意な差があると判断します。

ただし、p値が0.05未満だからといって、「B案がA案より優れている確率が95％」という意味ではありません。また、有意差があることは、改善幅が事業上十分に大きいことや、同じ結果が将来も続くことを保証するものでもありません。

結果を見るときは、次の3点をあわせて確認します。

サンプル数が非常に多いと、わずかな差でも有意になることがあります。CVRが0.01ポイント上がって有意差が出ても、実装費用を回収できなければ、B案を採用する価値は低いかもしれません。反対に、改善幅が大きく見えても信頼区間が広い場合は、データ不足によって推定が不安定な可能性があります。

A/Bテストで特に注意したいのが、途中経過を何度も確認し、p値が0.05未満になった瞬間に終了する「ピーピング」です。通常の固定期間を前提とした検定でこの方法を繰り返すと、本当は差がないのに、有意差があると判断する可能性が高くなります。

途中経過は、表示崩れや計測漏れなどの異常を確認する目的で見ます。勝敗については、事前に決めたサンプル数と実施期間に到達してから判定します。

ツールによっては、逐次検定やベイズ統計など、途中経過の確認を前提とした判定方法が使われています。その場合も、ツールに表示された数値の意味と推奨される停止条件を確認し、通常のp値や「勝つ確率」を同じ意味として扱わないようにします。

有意差の有無だけで勝敗を決めず、データの信頼性、改善幅、事業への影響を合わせて判断することが、A/Bテストの結果を正しく活用するポイントです。

A/Bテストを実施する方法とツールの選び方

A/Bテストを実施するには、ユーザーをA案とB案へ振り分け、表示したパターンとコンバージョンを結び付けて記録する仕組みが必要です。HTMLを2種類用意するだけでは、同じユーザーへの表示を固定したり、結果を正しく比較したりできません。

Google Optimizeの提供終了後は、外部のA/Bテストツール、自社での実装、CMSやECプラットフォームの機能、広告媒体の実験機能などから、目的に合う方法を選びます。

ツールの機能数だけでなく、検証したい内容、対象ページのアクセス数、社内の技術体制、月額費用、GA4との連携、ページ表示への影響まで確認することが重要です。

Google Optimize終了後の主な実施方法

Googleが提供していたGoogle OptimizeとGoogle Optimize 360は、2023年9月30日に提供を終了しました。現在はGoogle Optimizeで新しいA/Bテストを作成・実施することはできません。

※提供終了については、Google Optimizeの提供終了に関する公式案内をご確認ください。

Google Optimize終了後にWebサイトやLPでA/Bテストを実施する方法は、主に次の4つです。

GA4は、A/Bテストのパターンをユーザーへ表示するツールではありません。外部ツールや自社実装によってA案とB案を振り分けたうえで、表示されたパターンをイベントとしてGA4へ送信し、行動やコンバージョンを比較します。

小規模なサイトでCTAの文言などを数回検証する場合と、複数のページで継続的にテストする場合では、必要な機能や許容できる費用が異なります。Google Optimizeの代替ツールを探すことから始めるのではなく、何をどの頻度で検証するかを決めてから実施方法を選びます。

外部ツールと自社実装の違い

WebサイトやLPで継続的にA/Bテストを行う場合は、外部ツールを利用する方法と、自社で振り分け機能を実装する方法が主な選択肢になります。それぞれに利点と注意点があるため、費用だけではなく、テストの内容と運用体制から判断します。

自社実装には、ページを表示した後にJavaScriptで内容を変更するクライアントサイド方式と、ページを返す前にサーバー側でパターンを決めるサーバーサイド方式があります。

外部ツールを比較する場合は、次の項目を確認します。

検索流入があるページを異なるURLに分けてテストする場合は、検索エンジンへの対応も必要です。Googleは、テスト用URLから元のURLへrel="canonical"を設定し、一時的な転送には301ではなく302リダイレクトを使用するよう案内しています。

Googlebotだけに別の内容を表示する方法は避け、テスト終了後は不要になったURL、振り分け処理、スクリプトを取り除きます。詳しくは、Google検索におけるA/Bテストの推奨事項をご確認ください。

Google広告の実験機能を利用する方法

Google広告では、管理画面の「テスト」または「Experiments」に用意された機能を使い、元のキャンペーンと変更案を比較できます。利用できる実験の種類はキャンペーンによって異なり、広告のパターン、カスタムテスト、Demand Gen、P-MAX、動画などに対応した機能があります。

実際の管理画面や利用できる機能は、キャンペーンの種類やアカウントによって異なるため、実施時点の表示を確認してください。

基本的な流れは次のとおりです。

Google広告では、元のキャンペーンとテスト案へ予算またはトラフィックを分けて比較します。2案を比較する場合は50％ずつに分ける方法が基本ですが、50％ずつ設定しても、広告オークション、入札方法、広告ランクなどの影響により、表示回数や広告費が完全に同じになるとは限りません。

広告文を検証する場合は文章だけ、入札方法を検証する場合は入札方法だけというように、変更する要素を絞ります。広告文、リンク先、対象者、入札方法を同時に変更すると、何が成果に影響したのか判断できません。

Google広告の公式ヘルプでは、実験は4～6週間以上を目安とし、コンバージョンまでの期間が長い場合は、1～2回のコンバージョンサイクルを待つことが推奨されています。ただし、必要な期間は配信量やコンバージョン数によって変わるため、期間だけで終了せず、十分なデータが集まったかも確認します。

また、実験によっては、終了後に変更内容を自動で元のキャンペーンへ適用する設定があります。社内で結果を確認してから判断したい場合は、実験開始前に自動適用の設定を確認してください。

結果はクリック率だけではなく、コンバージョン数、コンバージョン率、顧客獲得単価、売上、ROASなど、最初に決めた目的に近い指標で評価します。クリック数が増えても、問い合わせや購入が増えず広告費だけが上がっている場合は、成果が改善したとはいえません。

Google広告の実験機能と対応するキャンペーンについては、Google広告の「テスト」ページに関する公式案内をご確認ください。

GA4でA/Bテストの結果を計測する方法

GA4でA/Bテストの結果を計測するには、どのユーザーにA案・B案のどちらを表示したかをイベントで記録し、その後の問い合わせや購入と結び付けます。

GA4だけでは、A案とB案の作成やユーザーの振り分けはできません。外部ツールや自社実装でパターンを表示し、GA4では表示されたパターンとユーザーの行動を計測します。

基本的な設定の流れは次のとおりです。

GA4で表示されるCVRの差だけでは、統計的な有意差まで判断できません。GA4は計測と比較に利用し、必要なサンプル数や有意差は、A/Bテストツールや別の計算方法で確認します。

評価指標とキーイベントを決める

最初に、A/Bテストの採用案を決めるための評価指標を設定します。GA4では、問い合わせ、購入、会員登録など、事業上重要な行動を「キーイベント」として記録できます。

評価の中心となるキーイベントは、検証する目的に近いものを選びます。

CTAのクリック、フォーム開始、カート追加、購入手続き開始などは、ユーザーがどの段階まで進んだかを確認する補助指標として使用します。

CTAのクリック率だけが上がり、問い合わせ完了率が変わっていない場合、最終成果が改善したとは判断できません。主な評価指標は問い合わせや購入などの最終成果に置き、途中の行動は原因を考えるために使用するのが基本です。

A/Bテストでユーザー単位にパターンを固定する場合は、セッション単位のキーイベント率より、各案を見たユーザーのうち何人がキーイベントを発生させたかを見る方が、振り分け単位と一致します。ただし、セッション単位で実施するテストでは、セッションキーイベント率を使用する場合もあります。

キーイベント数は、同じユーザーが複数回実行すると複数件として記録されることがあります。A案とB案の人数が異なる場合は、件数だけを比べず、ユーザーキーイベント率やユーザー当たりの売上などの割合も確認します。

テストで使用するイベントは、本番開始前にGA4へ設定し、必要なイベントをキーイベントとして登録します。詳しくは、GA4のキーイベントに関する公式案内をご確認ください。

実験IDと表示パターンをイベントで記録する

A案とB案を比較するには、パターンが表示されたユーザーをGA4上で区別できるようにします。自社でA/Bテストを実装する場合は、パターンの表示時にexperiment_impressionなどのイベントを送信し、実験IDとパターンIDをイベントパラメータとして付けます。

たとえば、LPのファーストビューを比較するテストでは、次のように設定します。

gtag('event', 'experiment_impression', {
  'experiment_id': 'lp_firstview_202608',
  'variant_id': 'variant_A'
});

B案を表示した場合は、variant_idをvariant_Bに変更します。Googleタグマネージャーを使用する場合も、同じ実験IDとパターンIDをイベントパラメータとしてGA4へ送信します。

イベントは、ユーザーを振り分けただけではなく、対象となるパターンが実際に表示されたタイミングで送信します。表示エラーによってB案を見ていないユーザーまでB案へ含めると、正しい比較ができません。

また、同じユーザーにA案とB案の両方が表示されないよう、Cookie、会員IDなどを使って振り分け結果を維持します。同じユーザーが両方のグループに含まれると、A案とB案の差が小さく見える可能性があります。

実験IDやパターンIDには、氏名、メールアドレス、電話番号など、個人を特定できる情報を含めないでください。

GA4の探索でイベントパラメータを使用するには、管理画面の「カスタム定義」から、イベントスコープのカスタムディメンションを作成します。

カスタムディメンションはテスト開始前に作成します。Googleの公式案内では、送信したカスタムデータをレポートや探索で使用できるようになるまで、24～48時間かかる場合があるとされています。

テスト開始前にリアルタイムレポートやDebugViewを使い、次の項目を確認してください。

外部のA/Bテストツールを使用する場合は、ツール側でGA4連携が用意されていることがあります。Google公式の第三者ツール向け連携では、experience_impressionイベントとexp_variant_stringパラメータを使用する方法も案内されています。使用するイベント名やパラメータは、導入したツールの仕様に合わせてください。

自社実装を含む詳しい方法は、Google Analyticsの実験連携に関する公式ガイドをご確認ください。

探索レポートでパターン別の結果を比較する

実験用イベントとカスタムディメンションを設定したら、GA4の探索でA案・B案の結果を比較します。ユーザー単位で振り分けたテストでは、各パターンを見たユーザーのセグメントを作成する方法が適しています。

A案のユーザーセグメントには、同じイベント内で次の条件を満たしたユーザーを指定します。

B案についても同じ条件でセグメントを作り、variant_idだけをvariant_Bに変更します。

探索レポートは、次の手順で作成します。

主な確認項目は次のとおりです。

variant_idを表の行へ置くだけでは、後から発生した問い合わせや購入のイベントにパターンIDが付いておらず、成果を正しく結び付けられない場合があります。そのため、各パターンの表示イベントを条件にしたユーザーセグメントで比較する方法が適しています。

フォーム開始から送信完了までの違いを詳しく確認したい場合は、ファネルデータ探索を使用し、A案・B案のセグメントを適用します。パターン表示を最初のステップ、CTAクリックやフォーム開始を途中のステップ、問い合わせや購入を最後のステップに設定します。

ユーザーセグメントでは、対象期間内のパターン表示前の行動まで含まれる場合があります。表示後に発生した成果だけを確認したい場合は、ファネルや順序を指定したセグメントを使用し、「パターン表示の後にキーイベントが発生した」という条件で比較します。

計測結果を確認するときは、次の問題がないかも確認してください。

GA4とA/Bテストツールでは、ユーザーの識別方法、データの処理時刻、Cookieへの同意などの違いにより、数値が完全には一致しないことがあります。テスト開始前に、最終判定へ使用するデータをどちらにするか決めておきます。

GA4で確認できるのは各案の実績値です。表示されたCVRの差だけで採用案を決めず、事前に決めたサンプル数、停止条件、有意差、事業上の改善幅まで確認してください。

A/BテストをWebサイト改善につなげる運用方法

A/Bテストは、1回の勝ち案を見つけて終わる施策ではありません。アクセス解析やユーザーの声から課題を見つけ、仮説を立て、結果を記録し、次の検証へつなげることで、WebサイトやLPの改善に役立ちます。

テストの実施数や勝率だけを目標にすると、簡単に結果が出そうな変更や、事業成果から遠い変更が優先されることがあります。差が確認できなかったテストや、B案の成果が低かったテストからも、ユーザーが重視している内容を学べます。

成果への影響が大きい仮説へ工数を配分し、すべての結果を次の判断に使える形で残すことが、継続的なA/Bテスト運用の基本です。

仮説に優先順位を付ける

Webサイトを確認すると、見出し、画像、料金表、CTA、入力フォームなど、さまざまな改善案が見つかります。しかし、すべてを同時に検証することはできません。まずは仮説の候補を一覧にし、事業への影響と検証のしやすさから実施順を決めます。

優先順位を付けるときは、次の項目を確認します。

各項目を1～5点などで評価すると、複数の仮説を比較しやすくなります。ただし、合計点だけで機械的に決めるのではなく、主力商品や問い合わせに近いページなど、事業上の重要度を優先します。

たとえば、次の2つの仮説があるとします。

料金に関する問い合わせが多く、料金表からの離脱も確認できている場合は、仮説Aの方が根拠と事業への影響があります。実装しやすいという理由だけで、仮説Bを先に検証し続けないようにします。

一方、フォームが送信できない、料金表示が間違っている、スマートフォンで操作できないなど、修正すべきことが明らかな問題はA/Bテストの対象にしません。テストの順番を待たずに修正し、正常に利用できる状態へ戻します。

A/Aテストと同時実施するテストの考え方

A/Aテストとは、内容が同じ2つのパターンを用意し、通常のA/Bテストと同じ方法でユーザーを振り分ける検証です。改善案の効果を見るのではなく、振り分けや計測が正しく機能しているかを確認するために行います。

A/Aテストでは、主に次の項目を確認できます。

A/Aテストは、新しいA/Bテストツールを導入したとき、振り分け方法を変更したとき、GA4のイベント設定を大きく変更したときなどに有効です。すべてのA/Bテストの前に毎回実施する必要はなく、計測環境が安定していれば、通常の動作確認で対応できる場合もあります。

同じ内容を表示していても、A案とA案の数値が完全に一致するわけではありません。無作為な振り分けによって、一時的に差が生じることがあります。有意水準を5％に設定した検定では、実際に差がなくても、長期的には一定の割合で有意差が出る可能性があります。

そのため、A/Aテストで有意差が出たという理由だけで、すぐに計測不備と断定しません。次の項目を確認します。

また、複数のA/Bテストを同時に実施するときは、ユーザーや検証箇所が重ならないかを確認します。

たとえば、同じLPで「ファーストビューの見出し」と「料金表の見せ方」を別々のテストとして同時に実施すると、ユーザーには次の4通りの組み合わせが表示されます。

見出しと料金表が互いに影響する場合、どちらの変更によって成果が変わったのか分かりにくくなります。同じページ、同じ購入経路、同じキーイベントへ影響するテストは、原則として順番に実施する方が判断しやすくなります。

同時実施が必要な場合は、次のいずれかの方法を検討します。

複数の担当者がテストを実施する場合は、対象ページ、対象ユーザー、実施期間、実験ID、評価指標を共有し、別のテストと重なっていないかを開始前に確認します。

結果を記録して次の仮説へつなげる

A/Bテストが終了したら、勝ち案だけでなく、仮説、実施条件、結果、判断理由まで記録します。「B案のCVRが高かった」という結論だけでは、後から条件を確認できず、別のページへ応用することも難しくなります。

テストごとに、少なくとも次の項目を残します。

結果は、次のように分けて記録すると、その後の対応が明確になります。

B案を採用した場合も、「見出しを変えれば必ずCVRが上がる」と一般化しないことが重要です。対象ユーザー、商品、流入元、掲載位置など、今回の条件で結果が得られたと考えます。別のページへ展開する場合は、新しい仮説として改めて検証します。

明確な差が出なかった場合は、テストを失敗として終わらせず、次の可能性を確認します。

B案の成果が下がった場合も、ユーザーが元のページで何を重視していたかを知る材料になります。削除した情報への反応が悪かった場合は、その情報が申し込み前の不安を減らしていた可能性があります。

採用したB案を通常ページへ反映した後も、表示や計測に問題がないか確認し、CVRや売上の推移を継続して見ます。テスト期間中の効果が、全ユーザーへの反映後も同じように続くとは限らないためです。

採用されなかった案や差が出なかった結果も含めて記録することで、A/Bテストが一時的な施策ではなく、Webサイト改善の判断材料として蓄積されます。

A/Bテストでよくある失敗と回避策

A/Bテストでは、実施方法や判定条件に問題があると、効果のないB案を採用したり、本来は有効だった改善案を見逃したりすることがあります。管理画面上でA案とB案の数値が表示されていても、正しく比較できているとは限りません。

特に注意したいのが、複数要素の同時変更、十分なデータが集まる前の終了、CVRだけを見た判断です。いずれも数値上はB案が優れているように見えることがありますが、その後の改善や事業成果につながらない可能性があります。

テストを開始する前に仮説・評価指標・停止条件を決め、終了後は売上や問い合わせの質まで確認することで、誤った判断を防ぎやすくなります。

複数の要素を同時に変更して原因が分からなくなる

A/Bテストでよくある失敗の一つが、B案で見出し、画像、CTA、料金表、入力フォームなどを一度に変更することです。B案のCVRが上がっても、どの変更が影響したのか分からないため、結果を次の改善に生かせません。

たとえば、B案で次の変更を同時に行ったとします。

このB案で問い合わせが増えても、キャッチコピーが伝わりやすくなったのか、フォームの入力負担が減ったのか、料金表の移動が影響したのかを判断できません。効果がなかった変更や、悪影響を与えた変更まで採用する可能性もあります。

原因を判断できるテストにするには、次の方法で変更範囲を決めます。

ページ全体のリニューアル前後を比較すること自体は可能です。ただし、その場合に判断できるのは「新しいページ全体の成果」であり、個々の変更要素の効果ではありません。

複数要素の組み合わせを詳しく確認したい場合は、多変量テストとして設計する方法もあります。ただし、組み合わせが増えるほど多くのサンプルが必要になるため、十分なアクセスと分析体制がなければ、変更箇所を絞ったA/Bテストの方が実施しやすいでしょう。

短期間で終了して偶然の差を採用する

A/Bテストを開始すると、数日間だけB案のCVRが大きく上回ることがあります。しかし、サンプルが少ない段階では、数件のコンバージョンによって結果が大きく変動します。

たとえば、A案で1件、B案で3件の問い合わせが発生した時点では、B案が3倍の成果を上げたように見えます。しかし、その後にA案で問い合わせが増え、差がほとんどなくなる可能性があります。

途中経過を何度も確認し、B案が有意になった時点で終了する方法も避けます。通常の固定期間を前提とした検定では、確認回数が増えるほど、偶然の差を有意と判断する可能性が高くなります。

短期間での誤判定を防ぐため、開始前に次の条件を決めておきます。

必要なサンプル数に到達していても、数日間だけのデータでは、曜日や一時的な広告配信に偏っている可能性があります。反対に、予定していた期間を経過してもサンプル数が不足していれば、テスト期間が終わったという理由だけで勝敗を決めることはできません。

また、問い合わせや購入までに時間がかかる商品・サービスでは、テスト終了直前に参加したユーザーの成果がまだ記録されていない場合があります。コンバージョンまでの平均的な日数を確認し、結果が反映されるまで待ってから判定します。

最大実施期間を過ぎても必要なデータが集まらない場合は、B案が勝つまで延長するのではなく、「今回の条件では判定できなかった」とします。そのうえで、より大きな改善が期待できる仮説への変更や、ユーザーテストなど別の方法を検討します。

途中経過は計測や表示の異常を見つけるために確認し、採用案は事前に決めた停止条件を満たしてから判断することが重要です。

CVRだけを見て売上や解約率を確認しない

A/BテストではCVRが主な指標として使われますが、CVRが上がったからといって、売上や利益まで改善したとは限りません。コンバージョンの件数だけを増やす変更が、事業全体には悪影響を与えることもあります。

たとえば、次のようなケースがあります。

このような誤判定を防ぐには、主なKPIに加えて、悪化してはいけない指標をテスト前に決めます。

売上や購入データはGA4で確認できますが、粗利益、商談化率、受注率、解約率などは、ECシステムや顧客管理システムの情報と組み合わせる必要があります。A案・B案の識別情報を受注や契約のデータまで安全に引き継げると、Webサイト上のCVだけでは分からない成果を確認できます。

ただし、氏名やメールアドレスなど、個人を特定できる情報をGA4のイベントパラメータへ送信してはいけません。実験IDや社内で管理する匿名の識別子を使用し、個人情報の取り扱いにも配慮します。

解約率や継続率のように、結果が分かるまで時間がかかる指標もあります。その場合は、テスト終了直後のCVRだけで最終判断せず、後日確認する日を決めます。必要であれば、短期結果にもとづく判断を暫定とし、継続率や利益が確認できてから正式な採用を決めます。

A/Bテストの目的はCVRという一つの数値を高くすることではなく、売上・利益・顧客との関係を含めて事業成果を改善することです。主なKPIと悪影響を確認する指標をあわせて見て、採用案を判断してください。

A/Bテストについてよくある質問（FAQ）

まとめ：A/Bテストは仮説と判定条件を決めてから始める

A/Bテストとは、WebサイトやLP、広告に複数のパターンを用意し、ユーザーの行動データから成果につながる案を確かめる方法です。担当者の好みだけで変更案を決めず、実際の反応を比較できる点にメリットがあります。

ただし、A案とB案を表示するだけでは、信頼できる結果を得られません。A/Bテストを始める前に、次の項目を決めておきましょう。

テスト中にB案のCVRが高くなっても、途中で終了せず、事前に決めた条件を満たしてから判定します。有意差だけでなく、改善幅が事業上意味のある大きさか、売上、利益、問い合わせの質、解約率などに悪影響がないかも確認してください。

必要なアクセスやコンバージョンを集められない場合は、無理にA/Bテストを行う必要はありません。アクセス解析、ヒートマップ、ユーザーテスト、顧客への聞き取りなどから課題を見つけ、有力な改善案を通常ページへ反映する方法もあります。

また、B案が採用されなかった場合や、明確な差が出なかった場合も、仮説と結果を記録します。ユーザーが反応しなかった変更を知ることも、同じテストの繰り返しを防ぎ、次の仮説を考える材料になります。

まずは、問い合わせや購入に近く、データから課題が確認できる箇所を一つ選ぶことから始めてください。仮説、評価指標、判定条件を決めたうえで小さく検証し、その結果を次のWebサイト改善へつなげていきましょう。