メインコンテンツへスキップ
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 エディタを起動します。Add variation の横の 矢印 をクリックし、Add URL redirection を選択します。次に、バリエーションの URL リダイレクトを構成できます。 リダイレクトには 2 種類あります。Global redirection と Redirection by parameter です。
Kameleoon Web Experimentation は JavaScript を使用してリダイレクトを実行します。HTTP レスポンスステータスコード 302 で URL リダイレクトを実行したい場合は、Kameleoon の Feature Experimentation ソリューションと SDK を使用してください。
リダイレクト実験をセットアップする際、Kameleoon は元のバリエーションのセルフリダイレクトを自動的に処理します。これは、次の理由から強く推奨されます。
  • ユーザー体験の一貫性: 元のバリエーションをリダイレクトすることで、コントロールまたはバリアントが表示されているかどうかにかかわらず、すべてのユーザーが同じように扱われるようになります。このリダイレクトがないと、元のバリエーションのユーザーは、バリエーションの提供方法によりわずかな遅延や違いを経験する可能性があり、テスト結果にバイアスが生じる可能性があります。詳細については、この記事 のセクション 9 を参照してください。
  • 正確なデータ収集: リダイレクトベースのテストでは、元のバリエーションへのリダイレクトに失敗すると、インタラクションの測定方法に不整合が生じる可能性があります。たとえば、元のページの訪問者は、リダイレクトされたバリエーションの訪問者と同じトラッキングおよびレポートシステムを経験しない可能性があり、不完全または偏ったデータにつながります（SRM のセクション を参照）。

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

グローバルリダイレクトは、追加パラメータを伴わないシンプルな URL リダイレクトです。
完全な URL を入力する必要があります（URL のフラグメントだけでなく）。たとえば、次のグローバルリダイレクトを指定できます。 http://www.website/page1 から: http://www.website/page2 リダイレクトにクエリパラメータを含めるかどうかも選択できます。たとえば、ユーザーを https://www.example.com/products?category=shoes から https://www.example2.com/products にリダイレクトする場合、クエリパラメータ 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 実験が複数のページ（たとえば、すべての商品情報ページ）で実行される場合、上記のリダイレクトパネルで利用可能なものより多くの機能が必要になります。多くの場合、パーソナライズされた JavaScript コードでリダイレクトを管理する必要があります。 たとえば、次のページにアクセスするすべての訪問者をリダイレクトしたいとします。 http://mywebsite.com/product/sheet/technology,product,id.aspx これらのページへ: http://mywebsite.com/product_AB/sheet/technology,product,id.aspx technology、product、ID パラメータは表示される商品情報ページに応じて変わります。このテストを実行するには、すべての可能なケースを考慮するように JavaScript コードを記述する必要があります。例を以下に示します。 
var url = window.location.href;
var redirect_url = url.replace("/product/", "/product_AB/");
Kameleoon.API.Core.processRedirect(redirect_url);
JavaScript コードが記述されたら、ターゲットを慎重に定義する必要があります。URL でターゲティングする場合は、次のフラグメントを含む URL にテストを制限する必要があります。 http://mywebsite.com/product/sheet/
複数ページで分割 URL A/B 実験を実行することは、識別の要素がパラメータとして管理されるのではなく、URL に直接管理されることを意味します。ページタイプは category.php?product= ではなく /category/product.html になります。
URL リダイレクトに関する開発者ドキュメント を参照することを躊躇しないでください。

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

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

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

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

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

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

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

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

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

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

分割 URL 実験を QA するには、ブラウザでシークレットタブを開き、次の手順に従います。
  1. UTM パラメータを含めて自分のページに移動します: https://www.site.com?utm_param
  2. シミュレーション付きの新しいタブを開きます。
  3. タブを更新します。ターゲティングされます。
  4. バリエーションに切り替えます。
その後リダイレクトが実行されます。 Kameleoon は、初期公開時およびアトリビューションウィンドウ内のその後のすべての再訪問について、ターゲットされた訪問者のコンバージョンを追跡します。アトリビューションウィンドウは、訪問者のコンバージョンとトランザクションが特定のバリエーションに帰属する期間を決定します。訪問者のコンバージョンは、訪問が実験によってターゲティングされた場合、またはアトリビューションウィンドウ内にある場合にのみ実験で考慮されます。 詳細については、こちらの記事を参照してください。

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

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