A / Bテストを実行するときに、ドメイン、デバイス、ブラウザ間でeコマースのコンバージョンを追跡する方法は?

公開: 2021-11-09
A / Bテストを実行するときに、ドメイン、デバイス、ブラウザ間でeコマースのコンバージョンを追跡する方法は?

クロス環境トラッキングとは何ですか?

1つの変換、複数のタッチポイント!

これが、環境間追跡のすべてです。

今日の顧客は、さまざまなタッチポイントを使用してeコマースの購入を完了しています。 複数のデバイスからインターネットにアクセスし、ある環境でマーケティングキャンペーンを表示してから、別の環境に変換する場合があります。おそらく、ラップトップデバイスとドメイン「A」から始めて、自分に最適な製品を決定するまでブラウジングしてから、スマートフォンにアクセスします。 、多くの場合、ブラウザを切り替えて、最終的にドメイン「B」で購入します。

この傾向の結果として、ますます多くのコンバージョンファネルが複数のドメイン、デバイス、およびWebブラウザーにまたがっています。

Webサイト訪問者のインタラクションには、通常2つのタイプがあります。

  • 単一環境:変換への道のりが同じデバイス、ブラウザ、またはドメインで開始および終了する場合。
  • クロス環境:ウェブサイトの訪問者が1つのデバイス、ブラウザ、またはドメインからクリックスルーしたが、別の環境でコンバージョンを達成した場合。

これらの用語を理解するための簡略化された式は次のとおりです。

環境=ドメインまたはデバイスまたはWebブラウザ

環境間の相互作用がはるかに一般的であるため、コンバージョンの追跡とアトリビューションは困難な場合があります。 では、カスタマイズされたエクスペリエンスを提供するために環境が変化したときに、これらのeコマースコンバージョンをどのように追跡できるでしょうか。 まず、環境のどのプロパティが変更される可能性があるかを理解してから、それらの変換を追跡するさまざまな方法を特定する必要があります。

オムニチャネルeコマースファネルで発生する可能性のあるさまざまなタイプの追跡を分析して、顧客が亀裂をすり抜けないようにしましょう。

隠れる
  • クロス環境トラッキングとは何ですか?
    • クロスドメイントラッキング
      • クロスドメイントラッキングがA/Bテストの重要な概念であるのはなぜですか?
      • サードパーティのCookieを使用したクロスドメイントラッキング
      • ローカルストレージを使用したクロスドメイントラッキング
      • クロスドメイントラッキングに関する誤解
        • 神話#1。 サブドメイン間でユーザーを追跡するには、クロスドメイン追跡が必要です
        • 神話#2。 ペイメントゲートウェイにはクロスドメイントラッキングが必要です
        • 神話#3。 複数のドメインがある場合は、クロスドメイントラッキングが必要です
    • クロスデバイストラッキング
      • 訪問者IDを使用したクロスデバイス追跡(決定論的)
      • デバイスIDに基づくクロスデバイストラッキング(確率的)
    • クロスブラウザトラッキング
  • サイトはいつ別のドメイン/デバイス/ブラウザでのトランザクションを選択しますか?
  • プライバシーの変更は環境間の追跡にどのように影響しますか?
    • GoogleIncognitoがサードパーティのCookieをブロックしました
    • MicrosoftEdgeのプライベートモードでの厳密な追跡防止
    • Mozilla Enhanced Tracking Protection(ETP)2.0
    • iOS 14、iPad 14、およびSafari14でのインテリジェントトラッキング防止
  • A / Bテストツールはeコマースのコンバージョンを追跡し、ユーザーのプライバシーを維持できますか?
    • Optimizely
      • オプション1:BYOIDを有効にして使用する
      • オプション2:CDNにoptimizelyEndUserIdを設定する
    • VWO
    • Googleオプティマイズ
    • カメレオン
  • Convert Experiencesは、環境間の追跡をどのように管理しますか?
    • ConvertExperiencesでのクロスドメイントラッキング
    • コンバージョンエクスペリエンスにおけるクロスデバイストラッキング
    • ConvertExperiencesでのクロスブラウザトラッキング
  • クロスドメイントラッキングが機能するかどうかをテストする方法は?
  • クロスドメイントラッキングを有効にする際の考慮事項

クロスドメイントラッキング

クロスドメイントラッキングは、複数のドメインにわたる訪問者を分析する方法です。

クロスドメイントラッキングがA/Bテストの重要な概念であるのはなぜですか?

クロスドメイントラッキングは、ユーザージャーニーが複数のドメインにまたがっている場合でも、コンバージョンと行動をキャンペーンに関連付けることができるすばらしい機能です。 それがなければ、複数のドメイン(別のショッピングドメインやチェックアウトドメインを持つサイトなど)を持っている私たちにとって、アトリビューションはほぼ不可能です。

クロスドメインでキャプチャできるコンバージョン指標の一部を次に示します。

  • コンバージョン
  • 変換イベント
  • クリックスルーコンバージョン
  • ビュースルーコンバージョン
  • 総コンバージョン
  • クリックスルーコンバージョンイベント
  • ビュースルーコンバージョンイベント
  • 合計コンバージョンイベント
  • 総収入

サードパーティのCookieを使用したクロスドメイントラッキング

クロスドメイントラッキングの最も一般的な形式は、サードパーティのCookieに依存しています。

Webサイトは、ファーストパーティのCookieを使用して、訪問者とそのセッションに関する情報を保存し、通常、次の属性を持っています。

  • クッキー名:クッキーの名前。
  • Cookieドメイン:Cookieが設定されているドメイン。
  • Cookieパス:Cookieが設定されているパス。 これは、ドメイン'/'のルートディレクトリとして設定されます。
  • Cookieの有効期限:Cookieの有効期限が切れるまでの秒数。

現在、これらはファーストパーティのCookieであるため、他のドメインと情報を共有することはできません。 ここで、クロスドメイントラッキングが役立ちます。 この場合、ドメインAのCookieの値をドメインBのCookieと共有し、ファーストパーティのCookieをサードパーティのCookieに変換するように指示する必要があります。

クロスドメイントラッキングは、デフォルトでクエリ文字列を使用してドメインが変更されるURLにドメインAのCookie値を追加します。 クエリ文字列のファンでない場合は、これをURLフラグメントに変更することもできます。 ドメインBは、これらのURLに追加されたこれらのパラメーターを認識して、Cookieがこれらの値を採用するようにします。

これがどのようになるかの例を見てみましょう。

オンラインでレンタカーを借りたいとしましょう。 さまざまなオプションを確認するには、レンタカーのWebサイトにアクセスする可能性があります(この例ではcar.comを使用します)。 このサイトには多数のサブドメイン(car.com、payment.car.com、pickup.car.comなど)と支払いを受け取るためのサードパーティドメイン(secure.booking.com)があるため、ユーザージャーニーはクロス-ドメイン。

car.comでのクロスドメイン追跡の例
car.comでのクロスドメイン追跡の例

クロスドメイントラッキングを使用して、Car.comのチームは、あるサブドメインから別のサブドメインに切り替わるユーザーを見つけ、さまざまなサブドメイン間で最も関連性の高い製品またはサービスのエクスペリエンス全体をパーソナライズできます。

ローカルストレージを使用したクロスドメイントラッキング

ただし、Cookieをクロスドメイントラッキングで使用する場合の大きな欠点が1つあります。それは、ストレージが限られていることです。

Cookieは、ローカルストレージよりもはるかに少ないデータを保持できます。Cookieストレージは4096バイトに制限されていますが、ローカルストレージはドメインあたり5MBです。 したがって、Cookieを使用する場合、訪問者のブラウザに保存するデータが多いほど、作成する必要のあるCookieも多くなります。

Cookieのもう1つの問題は、CookieによってWebサイトの速度が低下し、ユーザーエクスペリエンスが最適化されないことです。 HTTPリクエストごとに、Cookieがサーバーに送信されます。 クロスドメインの旅がある場合、これはさらに悪化します。 訪問者は異なるドメイン間を行き来し、ブラウザ内のHTTPリクエストとCookieの数を増やします。

上記の理由により、一部のサイトではCookieストレージの代わりにlocalStorageを使用しています。 つまり、基本的にドメインAでファイルをホストし、ドメインAからファイルを読み込むドメインBでiframeを使用します。このようにして、2つのドメイン間で訪問者データを1つの単一ドメインであるかのように共有します。

ファイル1.html:

 <html>
<head />
<iframe src ='http://127.0.0.1/test.html' />
</ html>

ファイル2.html:

 <html>
<head />
<スクリプト>
console.log(localStorage);
localStorage.setItem('test'、 '123');
</ script>
</ html>

クロスドメイントラッキングに関する誤解

クロスドメイントラッキングは、誤解されていることがよくあります。 これがあなたを驚かせるかもしれないそれについてのトップ3の誤解です!

神話#1。 サブドメイン間でユーザーを追跡するには、クロスドメイン追跡が必要です

多くのCRO専門家は、サブドメイン全体で訪問者を追跡するには、クロスドメイン追跡を有効にする必要があると考えています。 本当じゃない。 Cookieは、サブドメインとメインドメインの間で共有できます。

したがって、たとえば、Cookieがwww.convert.comに設定されている場合、クロスドメイントラッキングを有効にしなくても、blog.convert.comからアクセスできます。

神話#2。 ペイメントゲートウェイにはクロスドメイントラッキングが必要です

クロスドメイントラッキングに関する次の紛らわしい部分は、支払いゲートウェイ(PayPal.comなど)用にセットアップする必要があることです。

ただし、クロスドメイントラッキングは、両方のドメインを制御できる場合にのみ可能です。

ほとんどの場合、支払いゲートウェイでは、セキュリティ上の理由から、トラッキングコードをWebページに配置することはできません(これについては以下で詳しく説明します)。

神話#3。 複数のドメインがある場合は、クロスドメイントラッキングが必要です

他の誤解は、さまざまなドメインを使用しているときはいつでもクロスドメイン追跡が必要であるということです。 これは、同じユーザーがWebサイト間を移動していることを確認し、コンバージョンをトラフィックのソースに関連付けたい場合にのみ当てはまります。 その場合、クロスドメイントラッキングが必要になります。

それでも、ドメインAをドメインBへのトラフィックソースとして表示し、どのトラフィックソースからドメインAに到達したかを気にしない場合は、クロスドメイントラッキングは必要ありません。

クロスデバイストラッキング

今日、人々は複数のデバイスを所有しています。 つまり、訪問者は1つのデバイスでブランドを操作し(たとえば、Google広告をクリック)、別のデバイスに切り替えて製品のチェックを続けることができます。 クロスデバイスコンバージョンレポートのおかげで、マーケターは、ユーザーが実際にコンバージョンしたデバイスに関係なく、すべてのデバイス(タブレット、モバイル、デスクトップ)でキャンペーンの効果を確認できます。

クロスデバイスレポートは、Cookie(Webの場合)、デバイスID(モバイルアプリの場合)、および集約されたサインインデータをリンクして、さまざまなデバイス間でユーザーを識別します。 これにより、ウェブサイトの所有者は、最初にブランドとやり取りしたり、広告を見たりしてからコンバージョンに至るまで、ユーザーがたどった経路を特定できます。

マーケターが異なるルートを使用して目標到達プロセスに入る場合でも、特定のユニークなWebサイト訪問者を見つけるのに役立ちます。

クロスデバイストラッキング
クロスデバイストラッキング

クロスデバイストラッキングには、主に2つの方法があります。

1つの方法では、Webサイトの訪問者は固定の訪問者IDを介して追跡されます。 もう1つの方法は、デバイスIDを持つユーザーの動作に基づいています。

訪問者IDを使用したクロスデバイス追跡(決定論的)

この方法は、ユーザーがニュースレターまたはログインを介してサインアップするときによく使用されます。 Facebook、Instagram、TikTok、Twitterなどのソーシャルネットワークは、訪問者IDを割り当てることでデバイス間の追跡を行います。

この方法は、訪問者を登録したWebサイトに適しています。 訪問者が一意のIDでマークされると、訪問者がログインするたびに追跡プラットフォームに通知されます。同じ訪問者が後で別のデバイス、たとえばタブレットを使用し、問題のWebサイトをアプリとして開いてログインすると、追跡プラットフォームに通知されます。正確に追跡することができます。

この方法は、決定論的とも呼ばれ、非常に正確(ほぼ100%)であり、特定のユーザーを対象とした正確なキャンペーンを実行するために使用できます。

デバイスIDに基づくクロスデバイストラッキング(確率的)

クロスデバイストラッキングの2番目の方法は、ユーザーにタグを付けることでも機能しますが、今回は登録する必要はありません。 この方法は、訪問者が閲覧するIPアドレス、デバイス、ブラウザー、またはアプリから収集され、ユーザープロファイルに結合されるさまざまな属性に基づいています。 この方法の欠点は、訪問者IDを使用する場合ほど正確ではないことです。

確率的ターゲティングとも呼ばれます。 名前が示すように、Aがデスクトップ(Xデバイス)とスマートフォン(Yデバイス)を使用している可能性が高いことを示しています。 そのため、追跡を行うために、大量の属性を持つアルゴリズムが設計され、デバイス、地理的な場所、IPアドレス、およびその他の同様のコンテキスト全体で同様の動作に基づいてユーザーがセグメント化されます。 もちろん、この追跡の精度は100%に達することはできませんが、60〜70%が適切な目標です。

クロスブラウザトラッキング

最後に、クロスブラウザートラッキングを使用すると、Webサイトは、Chrome、Firefox、Microsoft Edge、Safari、Torなどのさまざまなブラウザー間でユーザーを追跡できます。

クロスブラウザ追跡の背後にある方法は、ブラウザフィンガープリントと呼ばれます。

これは、コンピューターのハードウェアとソフトウェアに固有の一連の特性を識別し、その情報を使用して、問題のシステムの「フィンガープリント」として機能します。

気づかないかもしれませんが、インストールされているアプリからブラウザの設定まで、すべてが組み合わされて独自のプロファイルが形成されます。 この指紋の識別可能性の程度は、各ブラウザのアルゴリズムによって異なります。

Firefoxでブラウジングしていて、広告を表示し、Chromeに移動して製品を購入し、リターゲティングキャンペーンのターゲットにならないようにしたとします。 ブラウザの設定でクロスブラウザトラッキングを無効にしない限り、ブラウザはキャンペーンでターゲットを設定できます。

ブラウザのフィンガープリント
ブラウザのフィンガープリント

サイトはいつ別のドメイン/デバイス/ブラウザでのトランザクションを選択しますか?

クロスドメイントラッキングは、サイト所有者が2つ以上のドメインまたはサブドメインで発生するセッションを追跡し、それらのセッションを単一のセッションとして扱いたい場合に特に役立ちます。

セッションは通常、次の場合に複数のドメインにまたがります。

  1. チェックアウトプロセスは別のドメインで設定されます(Shopifyなどのサードパーティのショッピングカートを使用している場合は非常に一般的です)。
  2. 目標の変換またはeコマーストランザクションは別のドメインで行われます(これはアフィリエイトWebサイトの場合にも非常に一般的です)。

クロスドメイントラッキングが理にかなっている典型的なシナリオは次のとおりです。サードパーティのショッピングカートを備えたeコマースプラットフォーム。

この状況では、ユーザーはメインサイトにアクセスして、PPCキャンペーンの商品を表示できます。 ユーザーがチェックアウトに向かうと、Shopifyなどを介して別のドメインのサードパーティのショッピングカートに移動し、トランザクションを完了します。

クロスドメイントラッキングがないと、ショッピング行動とチェックアウトはリンクされず、コンバージョンは異なるドメイン間でトラッキングされません。 したがって、これらのオンラインストアの所有者は、何らかの方法でドメインを接続する必要があります。 それ以外の場合、コンバージョンは元のトラフィックソースではなく、サードパーティのショッピングカートにクレジットされます。

したがって、クロスドメイントラッキングを使用すると、訪問者がサイトを離れた後でも、訪問者を確実に追跡できます。

クロスドメイントラッキングを実装するもう1つの利点は、1つのレポートでさまざまなドメインからデータを収集できることです。

トランザクションデータを一元化すると、最適化が容易になります。

  • 意思決定プロセスの継続的な改善をサポートし、
  • ビジネスプロセスのより良い追跡と最適化を強化し、
  • 不正確さや冗長性の悪影響を防ぎながら、組織のリスクを最小限に抑えます。

そして最後に、サイトの所有者は、追跡の制限のために、メインのマネーサイトですべての販売前のランディングページを実行することに制限する必要がなくなりました。 彼らは、より広く、追跡可能なマーケティングWebサイトの目標到達プロセスのために、複数のWebサイトに分岐することができます。

今日のオムニチャネルの世界では、消費者がデバイスやブラウザを使用する方法はさまざまなプラットフォームにまたがっています。Firefoxでタブレットで朝のニュースを読んだり、Chromeでスマートフォンで朝の通勤中にメールをチェックしたり、仕事でデスクトップPCを使用したりする場合があります。 夜になると、彼らはスマートウォッチを閲覧してその日のニュースに追いつくかもしれません。

典型的なシナリオは次のとおりです。

  • ユーザーが自分の携帯電話でニュースフィードを閲覧していて、製品に関する投稿をクリックしています。 ユーザーは興味を持っていますが、すぐにはサインアップしません。
  • その週の後半に、ユーザーは製品を再度チェックアウトすることを決定しますが、今回は別のブラウザーからコンピューターから直接ドメインにアクセスします。 次に、ユーザーはサインアップすることを決定します。
  • 数日で、ユーザーは自分の携帯電話からアプリにログインします。
  • 上記のデバイスとブラウザでの閲覧履歴はすべて、アカウントに適切に関連付けられている必要があり、ニュースフィードからの元のクリックは、コンバージョンに適切に起因している必要があります。

このテクノロジーは、サイト所有者が消費者の行動と購入へのマルチチャネルパスをよりよく理解するのに役立ちます。 これにより、顧客体験を向上させ、さまざまなタッチポイントにわたってターゲットを絞ったオムニチャネルマーケティング戦略を作成できます。 次のような質問に答えるのに役立ちます。

  • 私のPPCキャンペーンは、適切なタイミングで理想的な消費者に届いていますか?
  • キャンペーンを最適化し、そのソースに報酬を与えるために、どのデバイスが最も多くのコンバージョンをもたらすかを効果的に測定するにはどうすればよいですか?
  • Webサイトのエクスペリエンスをデバイスやブラウザー間でシームレスに実行し、消費者に一貫したブランドエクスペリエンスを提供するにはどうすればよいですか?
  • 使用しているデバイスに関係なく、消費者にリーチして、ブランドに関与するように動機付けるだけでなく、リピーターとして戻ってくるようにするにはどうすればよいですか?

プライバシーの変更は環境間の追跡にどのように影響しますか?

インターネットが日常生活にますます不可欠になるにつれて、人々がブラウジングするときに安全であると感じることが重要です。 ウェブサイト上で個人情報を非公開にするために、ますます多くのブラウザが追跡防止対策を講じています。 最新の追跡防止の変更の内訳と、それらが環境間追跡にどのように影響するかを次に示します。

以下の各更新について簡単に説明しますが、各更新の詳細と、Convertがそれらにどのように取り組んだかについては、2019年のトラッキングとCookieの変更方法と2020年のトラッキングとCookieの変更方法をご覧ください。

GoogleIncognitoがサードパーティのCookieをブロックしました

シークレットモードでは、Google Chromeはユーザーの閲覧履歴、フォーム情報、またはブラウザのCookieを保存しません。 Chrome 83以降、ブラウザはデフォルトでシークレットモードでサードパーティのCookieをブロックします。

ユーザーは引き続き特定のサイトでサードパーティのCookieを許可できますが、サードパーティのCookieに依存するクロストラッキング方法は、ブラウザの設定からWebサイトの訪問者が有効にする必要があるため、現在大きな課題に直面しています。

GoogleシークレットモードでブロックされたサードパーティのCookie
GoogleシークレットモードでブロックされたサードパーティのCookie

MicrosoftEdgeのプライベートモードでの厳密な追跡防止

Microsoft Edge 80では、デフォルトの動作により、ユーザーはInPrivateの閲覧中に厳密なモード保護が必要かどうかを決定できます。

MicrosoftEdgeの厳密な追跡防止モード
MicrosoftEdgeの厳密な追跡防止モード

これは、ユーザーがこの機能をオンにすると、クロストラッキングが不可能になることを意味します。

Mozilla Enhanced Tracking Protection(ETP)2.0

2019年以降、Firefoxの新規ユーザーはデフォルトでEnhanced Tracking Protection(ETP)がオンになり、昨年、Mozillaはリダイレクト追跡をブロックするEnhanced TrackingProtection2.0を備えたセキュリティレイヤーを追加しました。 ETP 2.0は、24時間ごとにサイトからCookieとサイトデータをクリアし、ユーザーが定期的にやり取りするサイトを除きます。

強化された追跡保護2.0
強化された追跡保護2.0

したがって、ETPによってブロックされるCookieに依存するクロストラッキング方法については忘れてください。

iOS 14、iPad 14、およびSafari14でのインテリジェントトラッキング防止

iOS 14、iPad 14、Safari 14のリリースに伴い、Appleは、ブロックされたトラッカーに関する情報をユーザーが確認できるプライバシーレポートや、iOSデバイス(v14以降)のすべてのWebブラウザーのITPなどの新しいプライバシー機能を追加しました。クロストラッキングの帰属を防ぎます。

A / Bテストツールはeコマースのコンバージョンを追跡し、ユーザーのプライバシーを維持できますか?

上記の追跡とプライバシーの更新により、複数の環境で追跡できる情報が制限されますが、ユーザーのプライバシーを維持し、カスタマイズされたエクスペリエンスを提供することは、相互に排他的ではありません。

クロス環境データ収集は、顧客の信頼を損なう、または顧客がWebサイトを最大限に活用することを妨げるような煩わしい方法で行われる必要はありません。両方の世界を尊重しながら、それを実行できる方法があります。

A / Bテストツールは、プライバシーを尊重しながら、ユーザーが何を望んでいるかを学習し、優れたオンラインエクスペリエンスを提供するのに役立つソリューションを提供できます。

市場で最も人気のあるA/Bテストツールのいくつかを見て、それらが提供するeコマースコンバージョントラッキングソリューションと、それらがどれほどプライバシーを尊重しているかを見てみましょう。

Optimizely

クロス環境コンバージョントラッキングを可能にするために、2つの異なるメソッドを最適化して構築しました。

オプション1:BYOIDを有効にして使用する

これは、Optimizelyで「BringYourOwnVisitorID」機能を有効にすることで実行できます。 この機能を使用すると、Cookie、localStorageキー、URLクエリパラメータ、またはjavascript変数のいずれかとして独自の訪問者IDを定義できます。 これには、ITP 2.xの緩和を超えたいくつかの利点があります。たとえば、ID永続化戦略を制御できること、複数のプラットフォーム間で訪問者IDを統一できること、Cookieの肥大化を減らすことなどです。

このオプションは、エクスペリエンスを実行しているクライアントまたはドメインごとに定義する必要がある、手動の面倒なプロセスです。 また、作成した一意のIDがOptimizelyAPIによって正常に取得されるように注意する必要があります。

オプション2:CDNにoptimizelyEndUserIdを設定する

BYOIDはより完全なアプローチであるため、この方法は通常はお勧めしません。 ただし、Cookieの作成を構成する別の方法は、CDNを使用することです。 これは、多くの場合、サーバー側のCookie作成のUIベースおよびUI管理の実装にとって実行可能なオプションです。 Optimizelyは現在、Akamaiの構成によるサーバー側のCookie作成に関するドキュメントを提供しています。

このプロセスに従っている場合は、上記のCDN設定の変更に加えて、プロジェクトJSでこれを実行して、訪問者IDCookieの自動有効期間延長も無効にする必要があります。

 window ["optimizely"]。push({
 "タイプ": "extendCookieLifetime"、
 "isEnabled":false
});

クロスドメイントラッキングが有効になっている場合、特に異なるドメインが訪問者IDの永続性について異なる戦略に従う場合、この戦略の機能も制限されます。

VWO

VWOは、サードパーティのCookieを使用してクロスドメイントラッキングをサポートします。

テストでサードパーティのCookieオプションを有効にすると、ドメインに属するCookieに訪問者データ(バリエーションが表示され、コンバージョン目標がトリガーされます)を保存するだけでなく、VWOはそのデータをサーバーにも送信します。 データが送信されると、VWOサーバーはドメインdev.visualwebsiteoptimizer.comにCookieを設定します。 テストに別のドメインが含まれる場合、次にページがテストデータを要求すると、VWOサーバーは訪問者データも送り返します。 ある意味で、サーバーは複数の異なるドメイン間のプロキシとして機能するため、コンバージョンを追跡できます。

VWOクロスドメイン
ソース

ただし、FirefoxおよびSafariブラウザはデフォルトでサードパーティのCookieをブロックします。 その結果、VWOはサードパーティのCookieにアクセスできないため、SafariおよびFirefoxブラウザでのクロスドメイントラッキングの動作が禁止されます。

Googleオプティマイズ

Google Optimizeのクロスドメイントラッキングを正常に実装するには、HTMLとJavascriptを知っているか、そのための専用のWeb開発者を取得する必要があります。

設定するには、Googleアナリティクスアカウントに単一のプロパティを作成します。

次に、リンクする両方のサイトで同じGoogleAnalyticsトラッキングIDを使用する必要があります。

GoogleOptimizeクロスドメイン
ソース
  1. ソースドメインは、宛先ドメインを指すURLを装飾して、ソースドメインのファーストパーティの測定Cookie値が含まれるようにします。
  2. 宛先ドメインは、リンクされた測定Cookieの存在を確認します。

リンカパラメータは、次の例のように、キー_glを使用してURLクエリパラメータで識別されます。

https://www.example.com/? _gl = 1〜abcde5〜

カメレオン

彼らのソリューションは、localStorageと自動的に同期するサーバー側のスニペットを作成します。 そのため、フロントエンドとバックエンドの間でkameleoonVisitorCodeCookieを自動的に同期するサーバー側スニペットをインストールすることをお勧めします。 これには、非常に重要なvisitorCode識別子が含まれています。

ITPはサーバー側のCookieに制限を課していないため、このCookieの有効期限はかなり先に設定されます。

スニペットは、Kameleoon Cookieが見つからない場合(つまり、フロントサイドでまだ作成されていない場合)にKameleoonVisitorCode cookieサーバー側を作成するか、ITPの問題を回避するために、既存の値を取得してcookieサーバー側を再作成します。 同期とは、7日後に識別子が削除されないだけでなく、Cookieを1つだけ保存するため、パフォーマンスやユーザーエクスペリエンスに影響を与えないことを意味します。

ただし、Kameleoonは他のデータをローカルストレージに保存するため、追加のサーバー呼び出しなしでリアルタイムの実験をトリガーするために必要なデータであるため、ローカルストレージの同期メカニズムも実装されています。

Safariでは、KameleoonがkameleoonVisitorCode Cookieを読み取ってvisitorCodeを取得すると、現在のローカルストレージが空かどうかを確認します。 その場合、おそらく最後の訪問が7日以上前であったことを意味し、サーバー同期呼び出し(SSC)を実行して、ローカルストレージに存在するすべてのデータをバックエンドサーバーからフェッチします。 この呼び出しが終了すると、ITPがデータをワイプしなかった場合とまったく同じ状態でデータが復元されます。 その後、通常の操作を再開できます。

Convert Experiencesは、環境間の追跡をどのように管理しますか?

Convert Experiencesはすべてのプライバシールールを尊重し、デフォルトでは、クロスドメイン、クロスデバイス、およびクロスブラウザーの追跡を許可しません

ただし、ユーザーが必要に応じて、プロジェクト設定でクロスドメイントラッキングを有効にし、Convertサポートチームにクロスデバイストラッキングのカスタムソリューションを依頼することができます。 クロスブラウザトラッキングはサポートされていません。

それでは、各タイプのトラッキングと、アプリでの設定方法について詳しく見ていきましょう。

ConvertExperiencesでのクロスドメイントラッキング

このセクションでは、ConvertExperiencesがクロスドメイントラッキングを処理する方法について説明します。 たとえば、Webサイトが複数のドメイン名にまたがっている場合。 これは、サードパーティのショッピングカートを使用している場合によくあります。

GDPRのため、ConvertExperiencesのすべてのプロジェクトでクロスドメイントラッキングがデフォルトでオフになっています。 ただし、「クロスドメインリンクを許可しない」設定のチェックを外して、追跡を可能にすることができます。

ConvertExperiencesでのクロスドメイントラッキング

Convert Experiencesアプリでは、実験はプロジェクト内で整理されます。 プロジェクトは、任意の数のエクスペリエンスを含むことができ、ドメイン(アクティブなWebサイト)を含むエンティティです。

コンバージョンエクスペリエンスにおけるクロスドメイントラッキング-アクティブなWebサイト

上記の「クロスドメインリンクを許可しない」プロジェクト設定を有効にしない限り、1つのConvertProject内のすべてのWebサイトがCookieを共有し、クロスドメイン追跡を可能にします。

ドメイン間でCookieを共有する方法は、訪問者がリンクをクリックしたりフォームを送信したりしたときに、同じプロジェクトに属するドメイン間でCookieを自動的に渡すことによって行われます。 これらのCookieは、GET変数を介して他のドメインに渡されます。

Cookieを渡すために、2つの変数がクエリ文字列に追加されます。

  • _conv_v
  • _conv_s

選択したリンクまたはフォームに手動でCookieを渡すことも可能です。 あなたがする必要があるのは、フォームのリンクまたはアクションのURLで_conv_v変数と_conv_s変数を渡すことだけです。

 <a href="http://www.myothersite.com/page.html"_conv_v"))+'&_conv_s='+escape(convert.getCookie("_conv_s"));falseを返す;" >>

それでは、ConvertExperiencesでのクロスドメイントラッキングのユースケースを見ていきましょう。

サブスクリプションを配置する必要があるイベントページから旅を始めたとしましょう。

https:// domainA .com / reports / WCI / cpc-bndl

支払いが必要になると、ドメインAはドメインBの下にある支払いカートページにリダイレクトし、クロスドメイントラッキングに必要な変換CookieをURLクエリパラメーターとして追加します。

 https://domainB.com/EWCIAH80/wci-cpc-bndl/?_conv_v=vi%3A1*sc%3A1*cs%3A1635157350*fs%3A1635157350*pv%3A2*exp%3A%7B100323139.%7Bv.1003114910- g。%7B10037703.1-10037704.1%7D%7D%7D&_conv_s = si%3A1 * sh%3A1635157349857-0.9940523874349994 * pv%3A2

支払いが完了すると、ドメインAのありがとうページに移動します。

 https://domainA.com/thanks/wci-cpc-bndl-thanks?_conv_v=vi%3A1%2Asc%3A1%2Acs%3A1635157350%2Afs%3A1635157350%2Apv%3A2%2Aexp%3A%7B100323139.%7Bv.1003114910 -g。%7B10037703.1-10037704.1%7D%7D%7D&_conv_s = si%3A1%2Ash%3A1635157349857-0.9940523874349994%2Apv%3A2

ここで、私は既存の訪問者と見なされるため、収益の変換は両方のドメインにわたって取得されます。

ConvertExperiencesログでのクロスデバイストラッキング

コンバージョンエクスペリエンスにおけるクロスデバイストラッキング

Convert Experiencesは、デフォルトでクロスデバイストラッキングをサポートしていません。 以下の方法は、カスタムソリューション用に設計されており、リーダープランの要求に応じて設計されています。 もはやアクティブではありませんが、教育目的でここに提示します。

さまざまなデバイスで訪問者を追跡し、使用しているデバイスに関係なく一貫したユーザーエクスペリエンスを提供するには、個人を特定できる(PII)データを含まない何らかの一意の識別子を使用してユーザーを「識別」する必要があります。 。

Convertは、顧客がデバイス間で訪問者を識別するこの一意の識別子を提示できるAPI関数を作成しました。 メインのConvertトラッキングスニペットの前に、ページ上で一意の識別子を「指定」する必要があります。

次のようになります。

 window._conv_q = window._conv_q || {};
_conv_q.push(["identify"、 "unique_hashed_id_here"]);

一意の識別子が提供されると、Convertは、サーバーにデータ(表示されたエクスペリエンス、実行された目標など)を照会して結果を返すまで、エクスペリエンスの表示を遅らせます。 結果が返されると、ユーザーが「識別」される前に持っていた最終的なバケットを置き換える長期Cookieに保存されます。 これは、各ページビューでのエクスペリエンスの表示の遅延を回避するために、データが長期Cookieでまだ利用できない場合にのみ実行されることを期待しています。

余分なネットワーク遅延を回避するために、応答を最小化して圧縮する必要があります。 最終的な解決策は、ページによって行われた2つの要求で構成されます。

  • 最初のリクエストは、メインのjsファイルの読み込み(データの読み込み)を担当します。CDNレベルでキャッシュされ、利用可能なすべての実験、jqueryライブラリの依存関係、目標、その他のutil関数、トラッキングが含まれますが、ユーザーバケットは含まれません。 このファイルは最小化および圧縮されて提供されます(gzip)。
  • 2番目の呼び出しは、サイズが数バイトです。 この特定のユーザーに以前に割り当てられたバケットを取得しようとします。 パフォーマンスの高いKey-ValueNoSQLデータベース(メモリキャッシュシステム内にキャッシュされている)にアクセスすることで、ユーザーが以前に割り当てられた実験IDと目標IDを読み込みます。 さらにパフォーマンスの向上が必要な場合、Convertはその前にあるCDNを使用して最適化します(この場合、各リクエストはユーザーごとにキャッシュされます)。 この応答も最小化および圧縮されて提供されます(gzip)。

新しい一意のWebサイト訪問者に一意の識別子が提供されると、エクスペリエンスのバケット化は次のように行われます。

  1. 新規ユーザーの場合—長期のCookieは保存されません。 一意の識別子が指定されている場合、2番目の呼び出しが戻るまで実験は延期されます。 その呼び出しは次のようになります。
    1. 一意の識別子に接続されている実験/バリエーションを返す場合、Convertは同じペアの実験/バリエーションをユーザーに表示します(前に表示された実験ページに戻る訪問者の場合と同じように動作します)
    2. または、その一意の識別子に何も接続されていない場合はデータを返しません。その場合、Convertは通常どおりランダム化を実行します。 その結果、新しいバケットが割り当てられると、発生したばかりの新しいバケットを保存するために、バックエンドへの追加の非同期呼び出しが発生します。
ConvertExperiencesステップでのクロスデバイストラッキング

既存のWebサイト訪問者に一意の識別子が提供される場合、エクスペリエンスのバケット化は次のように行われます。

  1. 既存のユーザー(識別子を持つ)の場合—Convertによって設定されたブラウザに長期Cookieがあります。 一意の識別子が提供されている場合、次の2つのケースのいずれかが発生する可能性があります。
    1. ブラウジングセッションが開始されていない(新しいセッションは、アクティビティがない状態で20分後に期限切れになるセッションCookieによって識別されます)、または長期Cookieに保存されている訪問者IDが一意のIDによって提供された訪問者IDと異なります。 この場合、前の例と同じことが起こります。サーバーからバケットが返されると、長期Cookieに保存されている現在のバケットが上書きされます。 サーバーがデータを返さない場合は、長期のCookieが優先されます。 This overwriting can become problematic when, for the same user, part of the session has a unique identifier and part of it does not.
    2. A current browsing session started and the visitor ID stored on the long-term cookie is the same as the unique identifier provided. In this case, the process is the same as usual: it's a user for which eventually the bucketing was restored at the first pageview of the user session, therefore, no additional requests are required (no second call to retrieve the data since it's already in the long-term cookie, nor a third call to save any bucketing that would've had happened otherwise).
Cross-Device Tracking in Convert Experiences Existing Visitor

Cross-Browser Tracking in Convert Experiences

Convert Experiences does NOT support cross-browser tracking.

How to Test if Cross-Domain Tracking Works?

Here are some tell-tale signs you can look for in your Convert reports that can indicate that cross-domain tracking isn't working right:

  • There is less traffic than you would expect,
  • Your conversions are not triggered/captured,
  • Traffic on one domain has various campaigns being attributed, while another domain includes less traffic.

Basically, if your Convert report is accounting for less traffic or fewer conversions than you'd expect, this could mean Convert is losing track of the attribution when your users switch domains. That might be an indication that cross-domain tracking isn't working properly.

Things to Consider When You Enable Cross-Domain Tracking

  • You do not need to enable cross-domain tracking for subdomains in your account.
  • Cross-domain tracking must be enabled when the original and variation URLs in a Split URL test are on different domains.
  • For enhanced privacy, the Firefox and Safari browsers block cross-domain tracking by default. As a result, Convert cannot access the third-party cookies, thereby prohibiting cross-domain tracking from working in Safari and Firefox browsers. However, the default browser settings can be disabled:
    • In the Safari browser, go to Preferences > Privacy and disable the Prevent cross-site tracking setting.
    • In the Firefox browser, go to Preferences > Privacy & Security > Custom and disable the “Cookies and Tracking Content” setting.
  • With the iOS 14 and macOS 11 upgrade, Apple introduced the Privacy Report feature in Safari. You can use this to examine a website's report to see which websites are tracking you and display the trackers that Safari has blocked. The report shows both cross-site tracking trackers and those detected by Apple's intelligent tracking prevention.
    Please note that this does not have any impact on your Convert experiences as our app only works with first-party cookies. Convert tracking would only be affected when you use the cross-domain tracking feature on Safari since the browser does not allow working with third-party cookies by default.

There are a lot of things to think about when it comes to tracking ecommerce conversions in A/B testing. It's not as simple as just looking at your web analytics reports or cookies, because customers may be seeing your digital marketing campaigns in one environment before converting on another. Today's consumers use an increasing number of touchpoints throughout their journey, which can get tracking info difficult for marketers.

Fortunately, A/B testing tools like Convert Experiences give users the ability to see how individuals interact with their online business, all while making sure that user privacy rights are upheld. Click the banner below to take a free trial and see for yourself how this works.