【ITニュース解説】How to A/B Test Two Landing Pages Using Campaign Links

ウェブサイトやアプリケーションを開発する際、どのデザインや機能がユーザーにとって最も効果的かを判断するのは難しい。特に、ユーザーが最初に着地するページである「ランディングページ」は、サービスへの興味を引き、特定の行動（商品購入や問い合わせなど）を促すための重要な入り口となる。ここで、異なる2つのランディングページ「A」と「B」を用意し、どちらがより高い成果（コンバージョン）を生み出すかを科学的に検証する手法が「A/Bテスト」である。システムエンジニアにとって、このテストの仕組みを理解することは重要だ。

A/Bテストの目的は、「このボタンの色を変えたらクリック率が上がるか？」や「この見出しの文言を変えたら資料請求が増えるか？」といった疑問をデータに基づいて解決することにある。しかし、ただ2つのページを作って公開するだけでは不十分だ。多くのユーザーを特定のキャンペーン（広告やメールマガジンなど）から誘導する場合、通常は一つのキャンペーンリンクを使用する。この一つのリンクから、テスト対象のAとB、どちらかのページへユーザーを適切に振り分け、その効果を正確に測定する方法が今回の解説の中心となる。

まず、なぜ一つのキャンペーンリンクを使う必要があるのかを考える。もしA/Bテストのためにキャンペーンリンク自体をA用とB用で変えてしまうと、例えば広告プラットフォームに登録したURLを変更し続ける必要があり、これまで積み重ねてきたデータの紐付けが困難になったり、既にユーザーに共有されているリンクが使えなくなったりする。つまり、キャンペーンリンクは安定しているべきだ。

そこで重要になるのが、「キャンペーンリンクの裏側」でユーザーをAかBのどちらかのランディングページへ振り分ける「ルーティング」である。最もシンプルなアーキテクチャは次のようになる。

1. キャンペーンリンクの設定: まず、広告やメール、SNSなどに設置するキャンペーンリンクを、特定のリダイレクト用エンドポイント（例えば https://example.com/campaign）に設定する。このURLは常に同じで変わらない。
2. リダイレクトエンドポイントでの処理: ユーザーがこのキャンペーンリンクをクリックすると、リダイレクト用エンドポイントにアクセスする。ここで、どのバリアント（AかB）を見せるかを決定し、対応するランディングページへ一時的に転送（リダイレクト）する。この転送は、HTTPステータスコード 302 Found を使用する。
3. ランディングページでの測定: ユーザーが最終的に着地したランディングページでは、自分がどのバリアント（AまたはB）を見ているのかを記録し、そこでのユーザー行動（ページ閲覧、申し込み、購入など）を分析ツールに報告する。

この仕組みにより、ユーザーには常に安定したキャンペーンリンクが提供されつつ、裏側で柔軟にA/Bテストが実行できる。

A/Bテストで最も重要な要素の一つが、ユーザーへのバリアント割り当て方法である。よくある間違いは、ユーザーがページを読み込むたびにランダムにAかBを割り当ててしまうことだ。もし同じユーザーがページをリロードするたびにAとBが入れ替わって見えたら、ユーザー体験は混乱し、テストデータもノイズが多くて信頼できないものになってしまう。

そこで必要となるのが、「ランダムに一度だけ割り当て、その後は固定（スティッキー）」にする仕組みである。つまり、あるユーザーが初めてキャンペーンリンクにアクセスしたときにAかBのどちらかに割り当てられたら、そのユーザーはテスト期間中は常に同じバリアントを見続けるようにする。これを実現する最も簡単な方法は、「ファーストパーティクッキー」を利用することである。

具体的には、ユーザーが初めてリダイレクトエンドポイントにアクセスした際、AとBのどちらかをランダムに決定し、その情報をクッキー（例: ab_variant=a）としてブラウザに保存する。次に同じユーザーがアクセスしてきた際には、ブラウザから送られてくるクッキーを読み取り、以前に割り当てられたバリアントを再利用する。これにより、ユーザーは一貫した体験を得られ、データも正確になるだろう。

この割り当てロジックでは、いくつか考慮すべき点がある。リダイレクトの際には、302 Found という一時的なリダイレクトを示すHTTPステータスコードを使う。これは、ブラウザやプロキシサーバーがリダイレクト先を永久にキャッシュしてしまう 301 Moved Permanently を避けるためだ。また、キャッシュの悪影響を防ぐために Cache-Control: no-store というヘッダーをリダイレクトのレスポンスに含める。これにより、CDNなどが同じリダイレクト結果を全ユーザーに提供することを防ぎ、各ユーザーが適切に割り当てられたバリアントにリダイレクトされる。

さらに、ランディングページ側でどのバリアントが表示されているかを知るために、リダイレクト先のURLに ?variant=a のようにクエリパラメータとしてバリアント情報を付加する方法が有効だ。これにより、ランディングページで改めてクッキーを読み取る手間が省け、JavaScriptなどで簡単にバリアント情報を取得できる。

クッキーの使用に関しては、プライバシー要件も考慮する必要がある。追跡目的ではないファーストパーティクッキーであれば、一般的に問題ないことが多いが、自身のクッキーポリシーに明記することが推奨される。もしクッキーが使えない場合、ユーザーのIPアドレスとユーザーエージェント（ブラウザ情報など）を組み合わせたハッシュ値を利用する代替案もあるが、これは共有ネットワーク環境などで不安定になる可能性がある。

A/Bテストの真価は、結果をいかに正確に測定し分析できるかにかかっている。各コンバージョン（目的とする行動）がどのバリアントによるものなのかを明確に紐付けられなければ、テストの意味がない。

最も簡単な方法は、ランディングページでURLに付加されたバリアントのクエリパラメータ（例: ?variant=a）を読み取り、その情報をウェブ解析ツール（Google Analytics 4、Plausible、Fathomなど）にカスタムディメンションやイベントプロパティとして送信することだ。例えば、ページが表示された時や、ユーザーがフォームを送信してコンバージョンが発生した時に、「このユーザーはバリアントAを見た」という情報を添えてデータを送信する。これにより、アナリティクスツール上でバリアントごとのコンバージョン率やその他の指標を比較できるようになる。

ただし、ユーザーが一度ランディングページを離れて再び戻ってきた場合、URLパラメータだけではバリアント情報が失われる可能性がある。これを防ぐためには、リダイレクト時にクッキーを設定するか、ランディングページがURLパラメータからクッキーをセットする仕組みが必要だ。そうすることで、ユーザーがサイト内を回遊しても、どのバリアントを見ているかという情報が維持される。

A/Bテストを成功させるためには、いくつかの一般的な落とし穴を避ける必要がある。

• クライアントサイドリダイレクトによるフリッカー: ページが読み込まれた後にJavaScriptでバリアントを切り替えるような「クライアントサイドリダイレクト」は避けるべきだ。一瞬でもユーザーが間違ったページを目にする「フリッカー」が発生し、ユーザー体験を損ねたり、テスト結果に悪影響を与えたりする可能性がある。サーバーサイドまたはエッジ環境でのリダイレクトは、HTMLがレンダリングされる前に処理されるため、この問題を回避できる。
• ボットの影響: 検索エンジンのクローラーや監視ツールなどの「ボット」もキャンペーンリンクをたどる。これらの非人間的なアクセスは、実際のユーザー行動とは異なるため、テスト結果を歪める可能性がある。既知のボットのユーザーエージェントを割り当てから除外するか、アナリティクスツールでボットのデータをフィルタリングするなどの対策が必要だ。
• テストの早すぎる終了: A/Bテストは、統計的に有意な差を検出するために、十分な量のデータ（コンバージョン数）が必要だ。トラフィックが少ない場合は、テストを数週間、あるいはそれ以上継続する必要がある。安易に結果を毎日確認し、途中でテストを終了してしまうと、単なる偶然の変動を本当の効果と誤認する可能性があるため、事前にサンプルサイズ計算機を使って必要なデータ量を把握することが重要である。
• 季節性の影響: 特定のセール期間中やイベント中に片方のバリアントだけをテストし、別の時期にもう片方をテストすると、ページの優劣ではなく時期的な要因を測定してしまうことになる。A/Bテストは、常に両方のバリアントを同時に、同じ条件で実行する必要がある。
• noindexの忘れ: A/Bテスト用のランディングページは、検索エンジンにインデックスされないように <meta name="robots" content="noindex"> をHTMLの <head> タグ内に記述すべきだ。そうしないと、内容がほぼ重複するページが複数存在し、検索エンジン最適化（SEO）の観点から問題が生じる可能性がある。リダイレクトエンドポイント自体もインデックスされないようにする。

キャンペーンリンクは、広告やSNSのプロフィール欄、QRコードなど、さまざまな場所に配置される。リダイレクトエンドポイントのURLが長くても機能的には問題ないが、視覚的に短く、入力しやすい方が望ましい場合がある。

その場合、LinkBitのようなショートリンクサービスを利用して、リダイレクトエンドポイント（例: https://example.com/campaign）を指す短いURLを作成することができる。これにより、ユーザーが目にするキャンペーンリンクは短く保たれ、その裏側で今回説明したバリアント割り当てロジックが機能する。ただし、ショートリンクサービス自体がA/Bテスト機能を提供している場合があるため、自身の割り当てロジックと衝突しないか十分に確認し、テストロジックは一箇所に集中させるべきである。

A/Bテストで最終的に測定すべきは、単にどちらのページがより多くのコンバージョンを生み出したかだけではない。次の指標をバリアントごとに追跡し、総合的に判断することが重要だ。

• 割り当てられた訪問者数: テストに参加したユニークユーザーの総数。
• コンバージョン数: 目的とした行動（サインアップ、購入、資料請求など）を完了した数。
• コンバージョン率: コンバージョン数を訪問者数で割った値。これがA/Bテストの主要な比較対象となる。
• コンバージョンまでの時間: ユーザーがページにアクセスしてからコンバージョンに至るまでの時間。特に、購入などの意思決定に時間がかかる場合に有用だ。

これらだけでなく、バウンス率（直帰率）やページのスクロール深度など、ユーザーエンゲージメントを示す指標も確認するとよい。例えば、コンバージョン率がわずかに高いが、直帰率が極端に高いページは、長期的に見て良い結果をもたらさない可能性もあるからだ。

一つのキャンペーンリンクを使って2つのランディングページをA/Bテストする基本的な考え方は、大きく3つの要素に集約される。それは、「安定したキャンペーンURLが、内部でバリアントに応じたページへリダイレクトする仕組み」、そして「訪問者に対してランダムに一度だけ割り当てられ、クッキーによってそれが固定される仕組み」、さらに「バリアント情報がコンバージョンに至るまで正確にアナリティクスツールへ連携される仕組み」である。

これらの仕組みは、数十行程度のシンプルなコードで実装可能だ。しかし、最も難しいのは、テスト途中の設定変更という誘惑に打ち勝つこと、そして、ルーティングと同様に測定結果の信頼性を保証するための規律と注意深さである。システムエンジニアとして、これらの原則を理解し、A/Bテストを適切に実施することは、非常に価値のあるスキルとなる。