CRM データを Google アナリティクスと統合して、Google 広告のリマーケティング オーディエンスを作成します

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このガイドでは、CRM ユーザーデータと Google アナリティクスの統合方法と、そのデータを使って Google 広告のリマーケティング オーディエンスを作成する方法について説明します。

さまざまな統合オプションの概要

ユニバーサル アナリティクスを使用すると、ウェブマスターは、ユーザーに関する CRM データを Google アナリティクスに送信し、セグメントの作成、レポート作成、リマーケティング リストの作成を行うことができます。リマーケティング リストは、ディスプレイ キャンペーンや、検索広告向けリマーケティング リスト(RLSA)でも使用できます。

Google アナリティクスに CRM データを送信する方法は 3 つあります(相互に排他的ではありません)。

これら 3 つのデータの送信方法には若干のトレードオフがありますが、いずれの場合も、CRM データはカスタム ディメンションとして Google アナリティクスに保存されます。

ユーザーに関する CRM データを Google アナリティクスに送信する主な要件は、CRM データの送信先となるユーザーごとに、お客様と Google アナリティクスの両方で認識されている共通の ID が必要であることです。このユーザー識別子は、ユーザーのために生成する自社 ID か、Google アナリティクスが生成した識別子です。 いかなる場合も、メールアドレス、ユーザーのログイン情報、社会保障番号、電話番号などの個人情報は禁止されています。独自のユーザー ID を使用する場合は、使用できるユーザー ID とはを必ずご確認ください。

Google アナリティクスと CRM データの統合を計画する最初のステップは、データと Google アナリティクスで共通する鍵として使用する識別子を決定することです。

データ インポートを使用して CRM データを送信する場合は、専有の訪問者 ID を使用する必要があります。これは、Google アナリティクスで生成されたクライアント ID をユーザー検索キーとして使用して CRM データを結合できないためです。

一方、Measurement Protocol を使って CRM データを送信する場合は、Google アナリティクスの cid を訪問者 ID として使用することをおすすめしますが、独自のユーザー ID を使用することもできます。独自のユーザー ID で Measurement Protocol を使う場合は、Google アナリティクスのユーザー ID のオーバーライドも実装する必要があります。

データのインポートによる CRM データの送信

データ インポートを使用すると、ユーザー インターフェースから手動で、または Google Analytics Management API によってプログラムによって Google アナリティクスにアップロードされたファイルを使用して、CRM データをアップロードできます。前述のように、この方法では独自のユーザー ID を使用して CRM データを Google アナリティクスのユーザーデータと結合する必要があります。

独自の訪問者 ID とデータ インポートを使用して CRM データを Google アナリティクスに送信するプロセスの概要を次に示します。

1. CRM ユーザー ID を Google アナリティクス タグに送信します。
       2. CRM から訪問者 ID に基づいて訪問者属性を取得します。3. CRM ユーザー属性を CSV ファイルで Google アナリティクスにアップロードします。4. CRM 属性は、Google アナリティクスのサイト アクティビティ データとマージされます。

このアプローチの主な利点は、既存のユーザー認証テクノロジーを活用でき、独自のユーザー ID のみを使用できることです。

クエリタイム データ インポートを使用して、離脱の傾向、顧客の価値、ライフタイム バリューなどの顧客価値データを取得し、GDN、ディスプレイ &ビデオ 360、Google アド マネージャー、RLSA、リマーケティング オーディエンス リストの最適化を行うことができます。このリストは、「プラチナ カード ユーザー」の類似ユーザーなど、類似ユーザーを生成するためにも役立ちます。

Google アナリティクスでは、クエリタイム ディメンション拡張(QTDW)によって、ユーザーがサイトにアクセスした後にデータをインポートできます。QTDW は、新しいクエリタイム データ インポートのデータセットがアップロードされるとオーディエンス リストに自動入力し、過去 30 日間の DCLK(またはオプティマイズの場合は Google アナリティクス)の Cookie を振り返ります。

CRM ファイルでクライアント データベース全体をアップロードし、新しいクライアントで定期的に増分 CRM データファイルをアップロードできる場合は、問題になりません。これにより、既知のユーザーがサイトにアクセスすると、以前に Google アナリティクスにアップロードされた CRM データがある場合、Google アナリティクスがそのタグを介してユーザーに渡された CRM ユーザー ID に基づいてリアルタイムで CRM 属性を関連付けることができます。

一方、ユーザーがサイトを訪れ、Google アナリティクスにアップロードされたデータファイルから一致する CRM データが Google アナリティクスで見つからない場合、そのユーザーの CRM ID 情報を含むデータファイルをアップロードしても、そのユーザーは CRM 属性を Google アナリティクスで関連付けられません。

Measurement Protocol を使って CRM データを送信する

CRM データを Google アナリティクスに送信する 2 つ目のオプションは、Measurement Protocol を使用する方法です。このオプションでは、Google アナリティクスで生成されたクライアント ID または独自のユーザー ID をルックアップ キーとして使用して、データを Google アナリティクスのデータと結合できます。

まず、Google アナリティクスのクライアント ID を使用した場合の実装について確認しましょう。このアプローチでは、ウェブサイト訪問者用に生成されたクライアント ID を追跡し、この ID を同じユーザーの対応する CRM ユーザー ID にマッピングする必要があります。

Google アナリティクス ユーザー ID を使用した Measurement Protocol

Google アナリティクス タグが設定されたサイトにアクセスすると、Google アナリティクス タグでは cid(クライアント ID)という ID が作成され、Cookie に保存されます。次の図は、CRM と Google アナリティクス間で共通のユーザー ID として cid を使用し、Measurement Protocol 経由で CRM データを送信するために必要な手順を示しています。

1. Google アナリティクスのお客様 ID を取得し、CRM ユーザー ID にマッピングします。
2. CRM 訪問者 ID に基づいて訪問者属性を取得します。
       3. Measurement Protocol を使って CRM ユーザー属性を送信する。4. CRM 属性は、Google アナリティクスのサイト アクティビティ データとマージされます。

このアプローチの主なメリットは、Measurement Protocol リクエストを介してカスタム ディメンションとして送信された CRM データが、適用先の Google アナリティクス ユーザーにすぐに関連付けられていることです。つまり、Google アナリティクスは、ユーザーに関連付けられた新しい CRM データに基づいて、CRM データが設定されている各訪問者がリマーケティング リストに追加されることが可能かどうかを確認します。

このアプローチの欠点は、サイト訪問者ごとに Google アナリティクスのクライアント ID をトラッキングし、Google アナリティクスのクライアント ID と独自の CRM ユーザー ID のマッピングを作成できることです。

独自のユーザー識別子を使用した Measurement Protocol

独自のユーザー識別子を使用して Measurement Protocol 経由で訪問者データを送信するには、Google アナリティクス タグも調整して、ユーザー ID のオーバーライドと呼ばれる機能を実装する必要があります。

つまり、Google アナリティクスのタグイベント(ページビュー ヒット、カスタム イベントヒット、e コマースヒット)ごとに、独自のユーザー ID を Google アナリティクス タグに渡す必要があります。

Google アナリティクス プロパティのユーザー ID を有効にすると、そのプロパティに 2 つのプロファイルが作成されます。1 つは Google アナリティクスの識別子(cid)でセッションが、もう 1 つはユーザー ID(uid)でセッションされます。ユーザー ID に基づいてセッション化されるプロファイルには、ユーザー ID を設定したユーザーのデータのみが含まれることに注意してください。ユーザー ID が設定されていないヒットは、ユーザー ID プロファイルから破棄されます。このルールの例外は、セッション中に訪問者のユーザー ID を渡し始めた場合(たとえば、ユーザーがログインまたは登録したとき)です。 このシナリオでは、Google アナリティクスは、認証前に送信されたタグイベントを、その訪問者向けに設定されたユーザー ID に関連付けます(ヒット合成と呼ばれることもあります)。

このアプローチでは、独自のユーザー識別子を使用できるという利点がもたらされ、各ユーザーに対する Google アナリティクスお客様 ID の追跡を心配する必要がありません。CRM データを送信したら、すぐにリマーケティング リストの追加をトリガーすることもできます。さらに、クロスデバイス アトリビューション、クロスデバイス ユーザーパスなど、ユーザー ID のオーバーライドのメリットも享受できます。ユーザー ID 機能のメリットについて詳しくは、こちらをご覧ください。

この方法の唯一の注意点は、ウェブ アクティビティの Google アナリティクス ビューが 2 つのプロファイルに分割されることです。1 つはすべてのトラフィックを持ちますが、クロスデバイス アクティビティに関するインサイトはありません。もう 1 つは、ユーザー ID トラフィックに関するデータのみを持ちますが、クロスデバイス アクティビティに関するインサイトを持ちます。

使用できるユーザー ID の構成

独自のユーザー識別子を使用してオフライン データを Google アナリティクスのデータと結合する予定がある場合は、ユーザー ID として使用する値を選択する際に留意すべき点がいくつかあります。

まず、Google アナリティクスの利用規約により、個人を特定できる情報(PII)を含む識別子を使用することはできません。 これにより、メールアドレス、ユーザー ログイン、社会保障番号、電話番号、または「PII」とみなされるデータを除外します。

訪問者用に作成する、難読化されていない英数字のデータベース ID を使用できます。もう 1 つの有効な方法は、適切な暗号化レベルを使用している限り、HIPAA で定義されている保護対象保健情報以外の PII に基づく暗号化された識別子を Google アナリティクスに渡すことです。Google では、SHA256 の最小ハッシュ要件に従い、8 個以上のソルトを使用することを強く推奨しています。

Google アナリティクスの CRM データ統合オプションの概要

次の表は、利用可能な統合方法の長所と短所をまとめたものです。

統合方法 ユーザー識別子 長所 短所
ユーザーデータのインポート カスタム ディメンションを通じて Google アナリティクス タグに渡される、任意のユーザー識別子
  • 独自の認証テクノロジーの使用
  • API の統合は不要
  • ファイルで簡単にデータをアップロード
  • リマーケティング リストの追加をすぐにトリガーできる
  • データ アップロードまでの 30 日以内にサイトにアクセスしたことのないユーザーは、次回のサイト訪問時にリマーケティング リストに追加されます。
cid を使用した Measurement Protocol 独自の CRM データベースにリンクする必要がある Google アナリティクスの訪問者 ID(cid)
  • リマーケティング リストの追加をすぐにトリガーできる
  • CRM データはすぐにユーザーに関連し、セグメンテーションとレポートに使用できます
  • Google アナリティクスのお客様 ID から CRM ユーザーデータへのマッピングが必要
  • Measurement Protocol リクエストを起動するには、サーバー間の API 統合が必要です
UID を使用した Measurement Protocol ユーザー ID のオーバーライドを使って Google アナリティクス タグに渡す、任意のユーザー識別子
  • リマーケティング リストの追加をすぐにトリガーできる
  • CRM データはすぐにユーザーに関連し、セグメンテーションとレポートに使用できます
  • ユーザー ID 機能のすべてのメリット
  • ユーザー ID に基づく Google アナリティクス プロファイルには、認証済みユーザーのアクティビティのみが表示されます