Skip to main content
URL リダイレクト分割テストは Graphic エディタと Code エディタでのみ利用できます。PBX では利用できません。
クラシックな A/B 実験とは異なり、URL リダイレクトを伴う A/B 実験では、テスト対象のページの異なるバージョンを自社の Web サーバーで開発・ホスティングし、ウェブサイトを介して訪問者に直接バージョンを提供します。 次の例を見てみましょう。テストしたい 2 つのサブスクリプションページがあります。これらが URL です。 http://mywebsite.com/SubscriptionA.html http://mywebsite.com/SubscriptionB.html ページはウェブサイト経由でアクセスできます。Kameleoon を使用すると、これら 2 つのページを A/B テストし、パフォーマンスと結果を分析できます。

​
シンプルな URL リダイレクト

通常通り Kameleoon Graphic エディタまたは Code エディタを起動し、バリエーションの URL リダイレクトを設定します。
  • Graphic エディタでは、新しいバリエーションを追加するか、既存のバリエーションを選択し、バリエーション名の横にある 三点 をクリックして、ドロップダウンメニューから Redirection URL を選択します。
  • Code エディタでは、Add variation の横の シェブロン をクリックし、URL redirection を選択します。
その後、Global redirection と Redirection by parameter の 2 種類のリダイレクトから設定できます。
Kameleoon Web Experimentation は JavaScript を使用してリダイレクトを実行します。HTTP レスポンスステータスコード 302 で URL リダイレクトを実行したい場合は、Kameleoon の Feature Experimentation ソリューションと SDK を使用してください。
リダイレクト実験をセットアップする際、Kameleoon は元のバリエーションのセルフリダイレクトを自動的に処理し、次の理由からこのデフォルトの動作を維持することを強く推奨します。
  • ユーザー体験の一貫性: 元のバリエーションをリダイレクトすることで、コントロールまたはバリアントのどちらを見ても、すべてのユーザーが同じ扱いを受けるようになります。このリダイレクトがないと、元のバリエーションのユーザーは、Kameleoon がバリエーションを提供する方法により、わずかな遅延や違いを経験する可能性があり、テスト結果にバイアスが生じる可能性があります。詳細については、この記事 のセクション 9 を参照してください。
  • 正確なデータ収集: リダイレクトベースのテストでは、元のバリエーションへのリダイレクトに失敗すると、Kameleoon がインタラクションを測定する方法に不整合が生じる可能性があります。たとえば、元のページの訪問者は、リダイレクトされたバリエーションの訪問者と同じトラッキングおよびレポートシステムを経験しない可能性があり、不完全または偏ったデータにつながります（SRM のセクション を参照）。

​
グローバルリダイレクト

グローバルリダイレクトは、追加パラメータを伴わないシンプルな URL リダイレクトです。
完全な URL を入力する必要があります（URL のフラグメントだけでなく）。たとえば、次のグローバルリダイレクトを指定できます。 http://www.website/page1 から: http://www.website/page2 リダイレクトにクエリパラメータを含めるかどうかも選択できます。たとえば、ユーザーを https://www.example.com/products?category=shoes から https://www.example2.com/products にリダイレクトする場合、Kameleoon はクエリパラメータ category=shoes をリダイレクト URL（https://www.example2.com/products?category=shoes）に渡します。

​
パラメータによるリダイレクト

同じ URL を使用しつつ追加のパラメータを使用したい場合は、Redirection by parameter を選択します。 URL の末尾に追加するパラメータを指定します。このオプションは、たとえば商品ページの結果のデフォルトの並び順を変更したい場合に便利です。 テストしたいバリエーションごとにこの操作を繰り返し、それぞれについて訪問者をリダイレクトする URL を指定します。
分割 URL A/B 実験の場合、実験を正しくターゲティングすることが重要です。Presence of an element on the page ターゲティングオプションは使用すべきではありません。フリッカリング効果が大幅に増加するためです。Kameleoon はページのロードを待ってターゲット要素の有無を確認し、その後訪問者をバリエーションにリダイレクトします。この種の実験には、他のターゲティングオプション（URL または高度な JavaScript 条件）を使用してください。同様に、複雑なリダイレクトに JavaScript コードを使用する場合は、Load this JavaScript code after page has finished loading (at DOMReady) ボックスのチェックを外しておきます。また、実験のターゲティングに両方のページ（A と B）が関連していることを示す必要はありません。ページ A で十分です。

​
複数ページでの URL リダイレクト

分割 URL A/B 実験が複数のページ（たとえば、すべての商品情報ページ）で実行される場合、Redirection URL パネルが提供するものより多くの機能が必要になります。多くの場合、カスタム JavaScript コードでリダイレクトを管理する必要があります。 たとえば、次のページにアクセスするすべての訪問者をリダイレクトしたいとします。 http://mywebsite.com/product/sheet/technology,product,id.aspx これらのページへ: http://mywebsite.com/product_AB/sheet/technology,product,id.aspx technology、product、ID パラメータは表示される商品情報ページに応じて変わります。このテストを実行するには、すべての可能なケースを考慮するように JavaScript コードを記述する必要があります。例を以下に示します。
JavaScript コードを記述したら、ターゲットを慎重に定義します。URL でターゲティングする場合は、次のフラグメントを含む URL にテストを制限する必要があります。 http://mywebsite.com/product/sheet/
複数ページで分割 URL A/B 実験を実行する場合、識別の要素をパラメータとして管理するのではなく、URL に直接管理することを意味します。ページタイプは category.php?product= ではなく /category/product.html になります。
詳細については、Kameleoon の URL リダイレクトに関する開発者ドキュメント を参照してください。

​
URL リダイレクトと同意ポリシー

Kameleoon はリダイレクトを実行する際、リダイレクト完了後の適切なトラッキングを保証するために、特定のデータ（バリエーション ID など）を訪問者のブラウザに一時的に保存します。 ただし、訪問者が同意する前にデータを保存することはできないため、同意を得たユーザーに対してのみリダイレクト実験を実行し、その際に実験の構成で次の JavaScript ターゲティング条件を使用してください。 return Kameleoon.API.Visitor.experimentLegalConsent || false;
同意を提供していないユーザーに対して実験を実行することを選択した場合、Kameleoon は、ユーザーがページを再ロードしたときの初期割り当てを維持するために、バリエーション ID をセッションストレージに一時的に保存します。
同意ポリシーの詳細

​
URL リダイレクトとサードパーティアナリティクスツール

​
カスタムアナリティクス統合への影響

リダイレクト実験でカスタムアナリティクス統合を使用する場合、Kameleoon が訪問者を最初にターゲティングする時点では、データを送信しません。リダイレクトが発生する前にアナリティクスツールがロードする十分な時間がない可能性があるためです。 正確なトラッキングを確保するために、Kameleoon はリダイレクト前にブラウザにデータを保存し、リダイレクト後（バリエーションページ上）にデータを送信します。これにより、アナリティクスツールが正しい情報を受け取り、リダイレクトがスムーズに（フリッカリングなしで）発生することが保証されます。

​
リファラートラッキングへの影響

Kameleoon がリダイレクトを実行すると、サードパーティアナリティクスツールは元のリファラー document.referrer へのアクセスを失います。 たとえば、訪問者が有料の Facebook キャンペーン経由でウェブサイトに到着しても、Kameleoon がすぐにバリエーションにリダイレクトする場合、記録されるリファラーは Facebook キャンペーンではなく、（リダイレクト前の）元のページになります。Facebook キャンペーン → 元のページ（リダイレクト前） → バリエーションページ（リダイレクト後） そのため、Google Analytics 4（GA4）は、Kameleoon が訪問者をバリエーションにリダイレクトすると、ページの元のバージョンを常に リファラー として記録します。 正しいリファラーを取得するには、Kameleoon でデータを確認するか、バリエーションページで Kameleoon.Gatherer.Referrer.obtain() を使用し、値をご自身のカスタム変数に保存して、正しいリファラー（たとえば Facebook キャンペーン）をキャプチャするようにします。

​
URL リダイレクトとサンプル比率不一致

Kameleoon が元のバリエーションを自動的にリダイレクトする場合でも、URL リダイレクトを伴う実験を実施すると、SRM に遭遇する可能性が高くなります。SRM は、variant B にリダイレクトされた訪問者がページを見ることができない場合や、データ収集がページ B のロード後にのみ行われる場合に発生します。SRM により、元のページには存在しなかった一定量のデータ損失が variant B で発生します。SRM に対処するには、SRM に関するガイドライン に従ってください。
オリジナル 0%、コントロール 50%、リダイレクト 50% のトラフィック割り当てで実験を構成する場合、Results ページで新しいコントロールをリファレンスとして定義してください。

​
URL リダイレクト実験の QA 方法

分割 URL 実験を公開する前に、実験が訪問者を正しくターゲティングし、意図したバリエーション URL にリダイレクトしていることを確認してください。
  1. 実験の Graphic エディタまたは Code エディタから、Simulate をクリックして新しいブラウザウィンドウでシミュレーションを開きます。シミュレーションパネルの詳細については、キャンペーンをシミュレートする を参照してください。
  2. シミュレーションパネルの Preview タブで、バリエーションセレクタを使用してテストするバリエーションを選択し、Force display をオンにします。
  3. ブラウザがそのバリエーションに対して設定した URL にナビゲートし、リダイレクト時に引き継がれると予想するクエリパラメータが含まれていることを確認してください。
Force display はターゲティング条件をオーバーライドするため、ターゲティングルールを満たさなくても各バリエーションをテストできます。 実験を公開する前に、各バリエーションについてこれらのステップを繰り返してください。 Kameleoon は、初期公開時およびアトリビューションウィンドウ内のその後のすべての再訪問について、ターゲットされた訪問者のコンバージョンを追跡します。アトリビューションウィンドウは、訪問者のコンバージョンとトランザクションが特定のバリエーションに帰属する期間を決定します。Kameleoon は、実験がその訪問をターゲティングした場合、またはアトリビューションウィンドウ内にある場合にのみ、訪問者のコンバージョンを実験で考慮します。 詳細については、Kameleoon がコンバージョンを数える方法 をご覧ください。

​
URL リダイレクトと SEO への影響

リダイレクト実験がウェブサイトの SEO に与える潜在的な影響について心配している場合、または実験開始以降に検索エンジンがウェブページをインデックスから除外していることに気づいた場合は、こちらの記事 を参照してください。