サーバーGTMを使ったクックレスGA4トラッキング

絶えず進化するデジタル環境の中で、ユーザートラッキングとデータプライバシーへのアプローチは大きな変化を遂げています。ウェブブラウザがサードパーティクッキーを段階的に廃止し、厳格なデータプライバシー法が導入される中で、従来のユーザートラッキングの方法は急速に非効果的になりつつあります。

こうした変化に適応することは、データ駆動の洞察に依存するビジネスやマーケティング担当者にとって必要不可欠です。

昨今のトラッキングの課題に適応する方法の1つは、クッキーレス・トラッキングへの切り替えです。最新のGoogle Analyticsは、多くの懸念や不満もあるものの、依然として最も人気のある分析プラットフォームです。ですので、この記事ではGoogle Tag Managerを使用したGoogle Analytics 4のクッキーレス・トラッキングの設定方法について取り上げます。

ウェブサイトがユーザーに関する情報を覚えておきたい場合（ショッピングカートの内容や、そのサイトにアクセスする前にクリックした広告など）、しばしば「クッキー」と呼ばれる小さなデータが使用されます。

しかし、今では多くのウェブサイトがクッキーを使用せずにユーザーのアクティビティを追跡する方法に移行しています。代わりに、ユーザーのブラウザにデータを保存することに依存しない新しい手法を使用しています。これを「クッキーレス・トラッキング」と呼びます。

トラッキングがクッキーに依存しない場合、ファーストパーティのユーザーデータが使用されます。この情報を収集して安全に取り扱う最善の方法は、サーバーサイド・トラッキングの使用です。そうすれば、ファーストパーティのユーザーデータフローを追跡、保存、拡張、変換し、厳密に制御することができます。

こうして、クッキーに依存せずにトラッキングがより正確になるだけでなく、コンプライアンスを向上させ、ユーザーデータのより厳密な管理につながります。

クッキーレス・トラッキングは、最近のトラッキングに関するプライバシーや制限の変更に適応するのに役立ちます。以下はその一例です。

1. 1.
   法規制：ヨーロッパやその他の国々のデータ保護規制当局は、ユーザーの同意なしにクッキーを使用することを制限しています。クッキーを拒否するユーザーの割合は国、年齢、クッキーバナーの要件によって異なります。しかし全体としては、約50％の人がマーケティングや分析用のクッキーを拒否しています。
2. 2.
   サードパーティクッキーの非推奨： SafariやFirefoxはすでにサードパーティクッキーを制限しており、Braveはサードパーティクッキーをサポートしていません。Chromeも2024年からサードパーティクッキーの段階的廃止を計画しています。アドネットワークはサードパーティクッキーを使用し、ユーザーがサイトにアクセスする前にクリックした広告を区別しています。また、分析プラットフォームはサードパーティクッキーを使用してサイトを訪れたことがあるユーザーを追跡し、ユーザーの完全な行動履歴を表示しています。クッキーがない場合、適切なコンバージョンの帰属や新規ユーザーとリピーターの区別が非常に難しくなります。
3. 3.
   トラッキングの制限：Appleはトラッキング制限の面でプライバシーをリードしています。すべてのiOSアプリでは、ユーザーにトラッキングの許可を求める必要がありますし、iOSユーザーはいつでもその許可を取り消すことができます。もう一つの傾向はAdBlockerの使用です。広告ブロッカーが有効になっている場合、マーケティングや分析のツールはユーザーに関する情報を受け取れません。

Google Analytics 4（GA4）は、分析用クッキーに同意しなかったユーザーの行動をモデル化するために機械学習を使用しています。分析用クッキーに同意した類似のユーザーの行動を使用して、同意しなかったユーザーの行動をモデル化しています。

機械学習の対象となるには、GA4プロパティが次の特定の条件を満たす必要があります。

• 同意モードがすべてのページで有効になっている
• 同意ダイアログが表示される前にタグがトリガーされる
• ユーザーが同意しなくても、Googleのタグが常に読み込まれる
• analytics_storage='denied'の設定で最低7日間、1 日あたりのイベント数が1,000件ある
• analytics_storage='granted' の設定で過去28日間のうち最低 7 日間、イベントを送信しているユーザーが毎日1,000 人いる

もしGA4プロパティが機械学習の対象にならない場合、または機械学習が正確な結果を提供していないことがわかった場合は、ユーザーが分析用クッキーを拒否した際にファーストパーティデータに依存してクッキーレスのGA4トラッキングを実装するという選択肢があります。

GA4を正しく動作させ、戻ってきたユーザーを認識するには、GA4 に次の情報を提供する必要があります。

• クライアントID (cid)
• セッションID (sid)
• セッション数 (sct)
• 初回訪問 (_fv)
• ユーザーエンゲージメント (seg)

ユーザーが同意しない場合に GA4のクッキーレス・トラッキングを設定するには、次のツールを使用します。

1. 1.
   Server Google Tag Manager.
2. 2.
   Server GA4.
3. 3.
   GA4のgscパラメーターを使用してユーザーの同意を区別する.
4. 4.
   Googleサービスアカウントをstapeに接続.
5. 5.
   Firestoreにデータを書き込む
6. 6.
   Firestoreからデータを読み込む
7. 7.
   Stapeのuser ID power-up

同意が得られたかどうかを判断するには、gcsパラメーターを使用します。 デフォルトのGA4同意設定はリクエストをsGTMに送信しますが、そのリクエストにはいくつかの情報が不足しています。 すべてのGA4リクエストはFirestoreに書き込まれます。

同意のないユーザーがGA4でアクティブなセッションを持っているかどうかを判断するには、前回の訪問と現在の訪問とのタイムスタンプの差を使用します。 差が30分を超える場合は、Firestoreのセッションパラメータが更新されます。

FirestoreはユーザーIDをドキュメント名として使用し、ユーザーセッションの詳細をドキュメント内に保存します。 これはFirestoreを整理する簡単な方法ですが、Firebaseで完全なユーザーエクスペリエンスのデータを維持する方法は他にも多数あります。

1.1 デフォルトのGA4サーバーサイド設定を使用します。

1.2 必要に応じて、データをFirestoreに書き込みます。ここではFirestore Writerタグを使用しました。詳しくはFirestore Writerタグのガイドをご確認ください。コレクションのユーザーIDを使用します。各ユーザーIDごとに、cidをドキュメント名として使用する新しいドキュメントを作成します。

1.3 GA4のサーバーサイドタグには標準の構成があり、GA4クライアントが要求されてユーザーが分析用クッキーに同意するとトリガーされます。

2.1.1 分析用クッキーへの同意がない場合、StapeのUser ID power-upを使用してsGTMリクエストヘッダーにユーザーIDを追加します。

2.1.2 Firestore Writer tagを使用して、データをFirestoreに書き込み、StapeのUserIDをドキュメント名として使用します。

2.1.3 セッションがアクティブであることを確認するには、Firestore Reader変数を使用し、ユーザーのFirebaseへの前回の訪問に関連付けられたタイムスタンプを抽出します。 次に、ユーザーの前回と今回とのセッションタイムスタンプの差を確認します。 タイムスタンプが30分未満の場合、ユーザーには既存のセッションがあります。

2.1.4 パラメータは次のように更新されます。

• cidとclient_id：Stape UserIDの値
• ga_session_number：Firestore内のga_session_numberの値
• ga_session_id：Firestore内のga_session_idの値
• x-ga-mp2-seg（エンゲージメントセッション）：１に設定
• x-ga-system_properties.fv（初回訪問）、x-ga-system_properties.ss （セッション開始）x-ga-system_properties.nsi（新しいセッションID）は削除されました。

2.1.5 GA4に修正されたデータを送信します。GA4に送信する前にデータを更新するには、変換を使用します。

2.2.1 分析用クッキーへの同意が得られなかった場合、StapeのUser ID power-upを使用してを使用してsGTMリクエストヘッダーにユーザー IDを追加しました。

2.2.2 Firestore writerタグを使用して、StapeのUserIDに基づいてユーザーデータを Firestoreに再度書き込みます。 

2.2.3 セッションがアクティブかどうかを確認するには、Firestoreリーダー変数を使用し、Firebase内のこのユーザーに関連するタイムスタンプを抽出します。次に、ユーザーの最後のセッションタイムスタンプと現在のタイムスタンプの差を確認します。タイムスタンプが30分以上の場合、新しいセッションが開始されています。

2.2.4 パラメータは次のように更新されます。

• cidとclient_id：Stape UserID の値
• ga_session_id：Firestoreのga_session_id値で、以前は秒単位のタイムスタンプに設定されていた。
• ga_session_number：Firestore内のga_session_number番号に１を加えたもの。
• x-ga-system_properties.ss (セッション開始) ： 1 に設定

• x-ga-mp2-seg (エンゲージメントセッション) ： 1 に設定
• x-ga-system_properties.fvは削除されました。

2.2.5 GA4に変更されたデータを送信します。GA4に送信する前にデータを更新するには、変換を使用します。GA4クライアントが要求され、同意が得られず、セッション間の時間差が30分以上の場合に、タグがトリガーされます。

2.3.1. 分析用クッキーが許可されていない場合、StapeのUser ID power-upを使用してユーザーIDを生成します。

2.3.2. Firestore内に同じユーザーIDを持つユーザーが存在するかどうかを確認します。同じユーザーIDのユーザーが見つからない場合、Firestore Writer tagを使用し、データベースにセッションの詳細を持つユーザーを作成します。

2.3.3 パラメータは次のように更新されます。

• cidとclient_id：Stape UserIDの値。
• ga_session_id：Firebaseのga_session_id。
• ga_session_number：Firestoreにあるga_session_numberの値。
• x-ga-system_properties.ss（セッション開始）：1に設定。
• x-ga-mp2-seg（エンゲージメントセッション）：1に設定。
• x-ga-system_properties.fv（最初の訪問）：1に設定。

2.3.4 GA4に変更されたデータを送信します。

Server Google Tag Managerを介したGoogle Analytics 4のクッキーレス・トラッキングの実装は、オンラインのデータプライバシーやユーザーの好みが変化する状況に適応するための重要な一歩となります。デジタルの世界が進化する中で、クッキーに頼らずに貴重なインサイトを収集することが不可欠になっています。

サーバーサイド・トラッキングとGoogle Tag Managerの機能を活用することで、企業はGA4が提供する重要なデータインサイトを利用しつつ、データプライバシーへの取り組みを維持できます。この手法は新たな規制への適合するだけでなく、オンライン・プライバシーに関心を持つユーザーとの信頼を築くことも可能です。クッキーレスな未来へと進む今、サーバーサイドのトラッキングやGA4のような革新的なソリューションを取り入れることで、企業はデジタルな競争力を維持することができます。