GoogleAnalyticsでのセッションステッチの4つの基本的な方法
公開: 2021-07-22ユーザーはシングルクリックでGoogleAnalyticsデータを破棄できます。AMPページからメインサイトまたはメインサイトから支払い処理業者に移動すると、1回の訪問が複数のセッションに変わり、途中でソースデータが台無しになります。
重要なことに、これらのクリックは、匿名の訪問者からログインしたユーザーへ、または購入前から購入後まで、価値の高い移行ポイントで発生することがよくあります。
セッションスティッチングは、技術的な障害ラインを修復し、クリーンな分析データを保持し、帰属情報を救出します。 この投稿では、4つの一般的な使用例について説明します。
- ユーザーIDの追跡
- AMP追跡
- サブドメインの追跡
- クロスドメイントラッキング
セッションステッチとは何ですか?
Google Analyticsでは、セッションスティッチングは、単一のセッション内で発生するユーザーアクティビティを接続しますが、技術的な追跡の制限により、複数のセッションを誤って生成します。
セッションをつなぎ合わせるためのあらゆる努力は、SimoAhavaが詳述する2つの要素にかかっています。
- 同じGoogleAnalyticsプロパティID(UA-XXXXXX-Y)を追跡するトラッカーオブジェクト
- 同じクライアントIDを持つ_gaCookie
最近のブラウザでは、あるドメインのサイトが別のドメインとCookieを共有することはできません。 その制限を克服することは、さもなければばらばらになるセッションを一緒にパッチすることの中心です。
「セッションスティッチング」という用語は、Googleよりもデジタルマーケティング担当者によって頻繁に使用されています。Googleは最近、他の2つの用語を好んで使用しています。
- セッションの統合。 「セッションの統合により、ユーザーIDが割り当てられる前に収集されたヒットをIDに関連付けることができます。」
- サイトリンク。 「クロスドメイントラッキングにより、アナリティクスはこれを1人のユーザーによる1つのセッションと見なすことができます。 これは、サイトリンクと呼ばれることもあります。」
特に、セッション統合に関するGoogle Analyticsのサポート記事では、画像の代替テキストとタイトルに「セッションスティッチング」というフレーズが保持されています(好奇心旺盛な方のために)。 セッションスティッチングへの誤った参照は、GoogleAMPクライアントIDAPIのサポート記事にも記載されています。
この記事では、セッションスティッチングは、単一のセッション内で発生するユーザーアクティビティを正しくグループ化するためのすべての取り組みを含む包括的な用語です。 Yehoshua Corenが指摘しているように、基礎となる技術的現実は、用語よりも重要です。 これはclientIdの整合性の問題です。」
この課題は、何と呼んでも、ほぼすべてのサイトのデータ品質と帰属に影響を与えます。
誰がセッションスティッチングを最も気にする必要がありますか?
セッションスティッチングはすべてのサイトで役立ちますが、いくつかのサイトでは不可欠です。
- ログインのあるサイト。 ログインのあるサイトは、「セッション統合」に依存して、ユーザーログインにつながるイベントに関するデータを収集します。
- AMPが多いサイト。 適切なトラッキングにより、ユーザーがAMPページからローカルでホストされている非AMPページに移行するときにアトリビューションデータが保持されます。
- 大規模なマルチドメイン組織。 複数のドメインでは、ユーザーがドメイン(またはサブドメイン)間で移行するときにアトリビューション情報を保持するために、クロスドメイントラッキングが必要です。
- サードパーティの支払い処理業者がいるサイト。 セッションスティッチングがないと、サードパーティの支払い処理業者に依存しているサイトは、eコマースコンバージョンのアトリビューションデータを失う可能性があります。
- ソーシャルログインを使用するサイト。 サードパーティの支払い処理業者と同様に、ソーシャルログインは、ログイン後のユーザーをソーシャルネットワークからの紹介として誤って再分類する可能性があります。
- iframeフォームのあるサイト。 Iframeは、サイトのページ内にクロスドメイントラッキングチャレンジを埋め込みます。
1.ユーザーIDの追跡
ログイン機能を備えたサイトの場合、ユーザーIDトラッキングは、時間の経過とともに複数の訪問を結び付けます。これにより、たとえば、どのSaaS機能が顧客の共感を呼んでいるかを企業が確認できます。
セッション統合は、ログイン前のアクティビティをログイン後のユーザーIDと結合し、2つから1つのセッションを作成します。 このようにして、ログインに先行する動作を確認できます。これは、そのログインが変換のポイントを表す場合に特に価値があります。
したがって、2番目のセッション(最初の画像)の一部のみをキャプチャする代わりに、セッション統合は、ログイン前のヒット(白)とログイン後のヒット(青)を結合します。


重要なことに、セッションの統合は、「特定のID値が初めて割り当てられた同じセッション内でヒットが発生した」場合にのみヒットを接続します。 つまり、以前のセッションではなく、ログインに先行するセッションからのデータが含まれます。
Google Analyticsは、毎日の分析処理中にセッション統合を適用します。「プロパティに関連付けられているレポートビューで選択された最西端のタイムゾーンに基づいて、毎日午前5時に」。
そのタイムラグは、「日中の直接セッションと直接収益の増加につながる可能性があります。 。 。]キャンペーンの紹介情報は、ユーザーがまだログインしていないセッションの最初のヒット時に送信されます。」
デフォルトでは、ユーザーID追跡を設定すると、セッション統合がオンに切り替わります。 なぜあなたはそれをオフにしたいのですか? Speeroエージェンシーアナリストの1人であるSilverRingveeに聞いた。 彼は明らかなユースケースを見ていませんでしたが、潜在的なユースケースについて推測しました。
ただし、実際にログインしているユーザー(旅行のある時点でログインしたユーザーではなく)に本当に焦点を合わせたい場合もあります。 したがって、IDを取得する前に何が起こったのかを気にしない場合は、IDをオフにすることをお勧めします。
[管理]> [プロパティ]> [追跡情報]> [ユーザーID]でセッションの統合をオフにできます。

ユーザーIDの追跡は、ログインが予想されるサイト(SaaS、eコマースなど)に最も関連性がありますが、ログインを奨励する方法は他にもあります。 たとえば、QuoraやGlassdoorのようなサイトは、ログインの壁の後ろに価値の高いコンテンツをゲートします。
これらのログインタイプの場合、セッションの統合により、最も魅力的なコンテンツに関する重要なデータ(ログインとサインアップを促進する回答または記事)が提供されます。
2.AMPトラッキング
GoogleのAMPロールアウトにより、追跡の問題が発生しました。検索からのAMPクリックにより、ユーザーはGoogleのCDNでホストされている「AMPoncache」バージョンに移動します。
PerficientのEricEngeが私に言ったように、「多くの人々はまだこれを正しく理解していません。 ほとんどのサイト運営者では、クロスドメイン(Googleキャッシュから実際のドメインまで)を追跡する微妙な点が失われています。」
最終的に、ユーザーは3つの方法のいずれかでAMPページにアクセスできます。 それぞれがクライアントIDの保存場所に影響します。
- Google検索。 AMPページはGoogle検索結果からアクセスされ、「AMPビューア」内に表示されます。 クライアントIDはgoogle.comに保存されています。
- プロキシ/キャッシュ。 AMPページはプロキシ/キャッシュからアクセスされます。 クライアントIDはcdn.ampproject.orgに保存されています。
- ダイレクトAMP。 AMPページには、サイト運営者のドメインから直接アクセスします。 クライアントIDはパブリッシャードメインに保存されます。
最初の2つのケースでは、AMPページからサイト運営者のサイトの別のページにクリックすると、クリックが1回のセッションの2回目のインタラクションとしてカウントされるのではなく、紹介と新しいセッションが生成されます。

管理されないままにすると、結果の分析データにはいくつかの問題があります。
- 膨らんだセッション数
- AMPページでの高いバウンス率
- AMPページのセッション/セッション期間あたりのページ数が少ない
他のセッションスティッチングの問題と同様に、解決策は、異なるドメインのページ間で同じクライアントIDを渡すことです。これは、GoogleがAMPクライアントIDAPIを介して可能にします。
Google AMPAPIを使用して同じクライアントIDを渡す方法
AMPトラッキングの設定には、アナリティクスコードの変更と紹介の除外の2つのステップがあります。

1.分析コードの変更。 適切なAMPトラッキングは、AMPページと非AMPページのGoogleアナリティクスコードに少し追加することから始まります。 Googleは、analytics.js、gtag.js、およびGoogle TagManagerに変更を加える方法の詳細を提供します。
一部のブラウザはサードパーティのCookieを拒否するため、Googleは2018年9月にAMPリンカーを発表しました。これは、Cookieベースの制限を回避して、URLをクライアントID情報で装飾します。 GoogleAMPクライアントIDAPIを既に有効にしている場合、AMPリンカーは追加の設定を必要としません。

2.紹介の除外。 さらに、ampproject.orgを紹介除外として追加する必要があります。 複数のサブドメインからAMPコンテンツを提供する場合は、それぞれに紹介除外を追加することをお勧めします。

Engeが詳しく説明しているように、現在のソリューションは完璧ではありません。「自分でホストしているAMPページとGoogleCDNでホストしているページの違いはわかりません。」
この制限は、「正規のAMPページ」(モバイルページの標準(正規)バージョンであるサイト運営者ドメインでホストされているAMPページ)のあるサイトに影響します。 同じ記事が提供する解決策は、ヒットレベルのカスタムディメンションを作成することです。
初期インストール後、変更は短期的なGoogleアナリティクスデータに影響します。
- ユーザーとセッションの総数は減少します。 AMPセッションと非AMPセッションをつなぎ合わせると、誤って分離されたユーザーとセッションが結合されます。
- 関連するメトリックがより正確になります。 たとえば、AMPページのバウンス率は低下します。
- 新規ユーザーが増えるでしょう。 Google AMP APIは、AMP訪問者のクライアントIDを1回リセットします。 Googleは次のように述べています。「ユーザーがサイトにアクセスする頻度によっては、これにより、新規ユーザーの指標と関連するレポートに顕著な一時的な変動が生じる可能性があります。」
3.サブドメインの追跡
サブドメインの追跡が大幅に容易になり、Cookieドメインの設定に依存しています。 以前は手動の手順でしたが、Cookieドメイン(cookieDomain)を「自動」に設定することが、GoogleAnalyticsスクリプトのデフォルトオプションおよびGoogleTagManagerのGoogleAnalytics設定変数になりました。
Simo Ahavaは、Cookieドメインを「自動」に設定すると、再帰的アルゴリズムが適用されると説明しています。
最も一般的なドメインレベル(トップレベルドメイン)から開始し、成功すると停止して、Cookieを書き込もうとします。 残しておくべきものはルートドメインであるため、Cookieはすべてのサブドメインで利用できます。
アルゴリズムはCookieを可能な限り高いレベル(ルートドメイン)に設定するため、サブドメインに到達し、後でコアドメインに移行するユーザーは、新しいクライアントIDを生成したり、新しいセッションを開始したりしません。

2番目のステップは、ルートドメインを紹介除外リストに追加して、サブドメインとコアドメイン間のアクセスが新しいセッションを開始しないようにすることです。 (最初のステップでは、Googleが訪問者を同じユーザーとして認識していることのみを確認します。 )Google Analyticsプロパティを作成すると、Googleはルートドメインを紹介除外リストに自動的に追加しますが、設定を再確認する価値があります。
理論的には、これらの更新によりサブドメインの追跡が自動化されます。Cookieドメインリストと参照除外リストは、デフォルトで正しい値に設定されています。
4.クロスドメイントラッキング
クロスドメイントラッキングは、多くのソリューションが特注されているため、セッションステッチングプロセスの中で最も複雑です。適切な実装は、サイト、支払いプロセッサ、ログインツール、または主がiframeのセットアップに依存します。
複数のサイトが同じトラッキングコードを共有しているが、他の技術的な変更が行われていない場合:
- Analyticsはドメイン間でセッションを複製します(クライアントIDが一方から他方に転送されないため)。
- 元の帰属情報は失われ、他のドメインからの紹介に変換されます。他のドメインは同じトラッキングコードを共有しているため、自己紹介として表示されます。
AMPトラッキングと同様に、クロスドメイントラッキングを成功させるには、Cookie自体を渡さずに、あるサイトから別のサイトにクライアントIDを渡す必要があります。 いくつかの主要なユースケースがあり、それぞれに独自のソリューションがあります。
企業内クロスドメイン追跡

大規模な組織は多くの場合、複数のドメインを管理しますが、訪問者が1つのドメインから別のドメインに移動するときに訪問者を追跡したいと考えています。 サイトが同じGoogleAnalyticsコードを共有していると仮定すると、複数のドメインにわたってユーザーを追跡するには、さらに3つのステップがあります。
最初の2つの手順では、トラッキングコードを変更して、ドメインがリンクを介してクライアントIDを送受信できるようにします。
- 自動リンクドメイン。 すべてのドメインをGoogleタグマネージャーのGoogleAnalytics設定変数内にカンマ区切りのリストとして追加するか、GoogleAnalyticsコードを修正してそれらのドメインを含めます。

- allowLinker。 ドメインがリンクを介して渡されたクライアントIDを確実に受信できるようにするには、GoogleタグマネージャーのGoogle Analytics Settings変数に「allowLinker」という名前のフィールドを追加し、値を「true」に設定します。 (ユーザーフローが一方向である場合は、ソースドメインではなく宛先ドメインでのみリンカーを許可する必要があります。)

リンカは、クライアントIDを検証するためにタイムスタンプとその他のメタデータを追加します。これにより、クライアントIDとの共有リンクがAnalyticsデータに影響を与える可能性が低くなります。
最後のステップは、すべてのドメインを紹介除外リストに追加することです。 それ以外の場合は、自己参照の山が生成されます。GoogleAnalyticsは、ドメイン間で1人のユーザーを正しく認識しますが、それでも新しいセッションを生成します。
クロスドメイントラッキングから収集されたデータを効率的に分析するには、URLパスの前にホスト名を追加します。 それ以外の場合、複数のドメインで共有されるパスはグループ化されます。 以下の両方のURLは、ページレベルのレポートでは/ about-us /としてのみ表示されます。
次の値を使用してカスタムフィルターを設定することにより、ホスト名を付加できます。

(適切にフィルタリングされなかった履歴データをレスキューしようとしている場合は、ホスト名で2次ディメンションを使用して、ビュー内のURLを区別できます。)
サードパーティの支払い処理
サードパーティの支払い処理では、正しい設定が不可欠です。設定がないと、すべてのトランザクションのアトリビューションデータが失われ、支払い処理業者からの紹介として表示されます。 ただし、支払い処理業者のページに対する制御は制限されています。
1つの解決策は、支払い処理業者のドメインの紹介除外を設定することです。 ただし、その作業(手動による作業)は、次の場合にモグラたたき作業になる可能性があります。
- あなたは多くの支払い処理業者と協力しています。
- 支払い処理業者は頻繁にドメインを変更します。
- 処理者のドメインを除外すると、「実際の」紹介トラフィックも除外されるリスクがあります(たとえば、PayPalのブログのリンクから紹介訪問を取得します)。

Ahavaは、創造的で包括的なソリューションについて詳しく説明しています。領収書または「ありがとう」ページへのすべてのトラフィックに対して紹介除外を作成します。 紹介の除外により、元のソースデータが保持され、ユーザーが支払い処理業者のドメインからサイトに戻ったときにGoogleアナリティクスが新しいセッションを生成するのを防ぎます。
Ahavaのソリューションの実装には、次の2つのステップがあります。
- カスタムJavaScript変数の作成。 サンキューページのURLにリファラー値「null」を設定します。
- サンキューページで起動するタグの変更。 サンキューページで起動するタグについては、「リファラー」フィールドを最近作成された変数に設定します。
特定のページへの紹介を全面的に禁止することは危険に思えるかもしれませんが、サンキューページはチェックアウトファネル内でのみアクセス可能(またはアクセス可能である必要があります)です。サンキューページでユーザージャーニーを開始することはありません。したがって、貴重品を失うリスクはありません。ソースデータ。
ソーシャルログイン

ソーシャルログインは包括的ドメインの紹介除外に依存することはできません。Googleログインはaccounts.google.com(安全に除外できるサブドメイン)から取得できますが、Facebookなどの他のログインはfacebook.com経由で取得でき、ほとんどすべてのサイトにFacebookからの非ログイン参照トラフィック。
一般的な解決策は、新しいタブまたはウィンドウで認証を開くことです。これにより、サイトのセッションの継続性が維持されます。 ただし、広告ブロッカーがこのプロセスを妨げる可能性があります。または、ユーザーエクスペリエンスのために、新しいウィンドウを開かない方がよい場合があります。
別の解決策は、Ahavaのサンキューページの戦略と同様に、サイトでホストされているログイン後のページのリファラー情報を上書きまたは無視することです。 リファラー値を独自のドメインまたは「null」に設定すると、ソースがDirectとして登録され、単一のセッションが維持されます。 この戦略は、ログイン後のページに一意のURLがある場合にのみ機能します。
Iframe
iframeは通常、Analyticsタグが起動する前に読み込まれるため、 iframeはセッションスティッチングの課題です。 つまり、Googleの開発者ガイドで詳しく説明されているように、URLにクライアントIDを追加するなど、従来の追跡ソリューションでは調整が必要です。
この問題を解決するには、iframe内のページを構成して、親ページからクライアントIDデータを受信するまでトラッカーの作成を遅らせることができます。 また、親ページで、postMessageを使用してクライアントIDをiframeページに送信するように構成します。
iframeでのクロスドメイントラッキングは苦痛を伴う可能性があります—Ahavaはそれらを「ウェブサイト間の隙間に存在する追跡不可能な小さなたわごとモンスター」と呼んでいます—フォームの移動に重点を置くベンダーによってウェブフォームで(あまりにも)頻繁に使用されていますGoogle Analyticsでこれらのインタラクションを追跡可能にするよりも、データをCRMに変換します。
Bounteousは、クロスドメインiframeトラッキングでpostMessageを使用するプロセスについて説明しています。
子iframeにメッセージを送信させることができます。このメッセージを「リッスン」して、重要な相互作用が発生したことをGTMに通知するために使用できます。 これは、iframe内の単純なフォーム送信などを追跡するのに最適です[。 。 。]次の手順を実行する必要があります。
1.)子iframeからのメッセージを投稿する
2.)親フレームでメッセージをリッスンします
3.)メッセージをキャッチしたら、イベントをGTMデータレイヤーにプッシュします
重要な注意点があります。iframeにコードを追加できる必要があります。 そうでない場合、プロセスは機能しません。
Ahavaは、クロスドメインiframeトラッキング用の2つのソリューションを作成しました。最新のソリューションでは、customTaskを使用しています。
customTask APIは、Universal Analyticsライブラリの機能です(Google Tag Managerのタグでも使用されます)。 生成中の(測定プロトコル)ヒットとの間で値を取得および設定できます。
クロスドメインiframeトラッキングの場合、「customTaskはsetInterval()スクリプトを利用して、ターゲットiframeが見つかるか、タイムアウトに達するまでページを定期的にポーリングします。」

Google Analyticsが親ページにヒットを登録すると、AhavaのソリューションはcustomTaskに、事前設定されたCSSセレクターに一致するiframeを探し、最初のヒットのクライアントIDでiframeURLを装飾するように求めます。
ただし、その解決策でさえ、特にiframeにリダイレクトが含まれている場合は脆弱です。実際には「追跡不可能なたわごとモンスター」です。
結論
セッションスティッチングは、Googleアナリティクスのデータを、私たちが真実であると知っているものと一致させます。ユーザーは、一度にドメイン間を移動したり、購入を完了したり、別のドメインとの間で簡単に移行するフォームに入力したりします。
ログイン前とログイン後、匿名の訪問者と既知のリード、潜在的な顧客と過去の購入者など、これらのやり取りの重要な性質により、セッションのステッチングは努力する価値があります。
ユーザーインタラクションを織り交ぜることで、アトリビューションデータが強化され、ユーザージャーニーの重要な分岐点での死角が減少します。