Optimizely ODP によるデバイス間の匿名追跡

この記事では、Optimizely Data Platform (ODP) を使用して、さまざまなセッションやデバイス間の匿名ユーザーのやり取りを効果的に追跡する方法について説明します。 ここで重要な点は次のとおりです 匿名 ユーザー。 ODP を使用すると、電子メール アドレスを使用して顧客レコードを簡単に結合できますが、訪問者に関する個人識別情報 (PII) を知らない (または知りたくない) 場合、克服すべき課題がいくつかあります。

Microsoft Dynamics 365 のパーソナライズされた電子メールの例を使用して、外部システムから顧客をサイトにリンクしてこれを実現する方法を示します。

デフォルトで追跡する

訪問者が Optimizely サイトに到着すると、「訪問者固有識別子」(VUID) が作成され、「ページ ビュー」イベント中に ODP に渡されます。 VUID は Cookie にも保存されるため、後続のイベントでは同じ値が渡されます。 このメカニズムにより、すべてのインタラクションは ODP の同じ顧客レコードに起因すると考えられます。

同じ人が別のデバイスでサイトにアクセスした場合 (または Cookie をクリアした場合)、その人には新しい VUID が割り当てられ、それらの間にリンクのない新しい顧客レコードが ODP に作成されます。

ここでの問題は、実際よりも多くの訪問者の記録が蓄積されており、これらの記録からは訪問者のやり取りの完全な把握が得られないことです。 これにより、レポート生成時にデータが歪められ、ユーザーベースをセグメント化し、パーソナライズされたエクスペリエンスを提供する能力が損なわれます。

追跡 知られている 訪問者はメールアドレスで

私たちが気にしなかったら 匿名 ユーザーにとって、ODP はこれを「すぐに使える」状態で処理します。 通常、特別な識別子である電子メール アドレスを使用して、異なる顧客レコードの問題に対処します。 2 つのレコードが同じ電子メールを共有している場合、ODP は高い自信を持ってそれらが同じ人物を参照していると判断できます。

サイトにログインがある場合は、訪問者の電子メールをキャプチャし、VUID に加えてこれを ODP に渡す効果的な手段があります。 ODP がこのイベントをキャプチャすると、同じ顧客レコードの下でこれら 2 つの識別子が調整されます。 次に、同じユーザーが別のデバイスにログインし、再度電子メールと VUID を渡すと、2 つの顧客レコードが 1 つのレコードの下に「結合」されます。

匿名の訪問者を追跡する – なぜ?

では、ODP が既知の訪問者に対してこの問題を解決したのであれば、なぜ匿名で訪問者を追跡することに決めたのでしょうか? この決定は多くの場合、ユーザーのプライバシーと規制遵守への取り組みに根ざしています。 データ収集を匿名化することで、複雑なプライバシー規制に対処しながら、ユーザーの機密性を尊重することができます。

もう 1 つの正当な理由は、単に選択の余地がないということです。 サイトにログインがない場合、ユーザーの電子メール アドレスを取得する効果的な手段がありません。

匿名の訪問者を追跡する — どのように?

ログインや電子メールがなければ、ODP はどのようにして顧客記録をつなぎ合わせるのでしょうか?

ODP は、「カスタム識別子」を使用してこれに対処します。 ODP の管理者は、電子メール アドレスとほぼ同じように動作する識別子フィールドを作成できます。つまり、カスタム識別子を共有する 2 つのレコードが結合されます。

サイトにリンクする外部システム (電子商取引プラットフォーム、CRM、電子メール マーケティング プラットフォーム、場合によってはモバイル アプリなど) がある場合は、ユーザーに対して何らかの識別子 (既知または匿名のいずれか) を持っている可能性があります。 ）。

キャンペーン電子メール、プッシュ通知、または SMS などによって、サイトに誘導するリンクをユーザーと共有するときは常に、この識別子をリンク URL のクエリ パラメーターとして渡すことができます。 その後、Web アプリケーションはこの値を読み取り、ODP でユーザーのカスタム識別子として設定できます。 訪問者がこれらのリンクのいずれかを 2 つのデバイスで開くと、各デバイスに対して作成された顧客レコードが結合されます。

透明性と同意

仕組みを詳しく説明する前に、あらゆる種類のユーザー追跡はオープンに実施されるべきであることを述べておく必要があります。 ユーザー データを ODP に追跡し、セッションとデバイス間でその記録をつなぎ合わせている場合は、プライバシー ポリシーまたは Cookie 同意バナーでそのことについて言及することを検討する必要があります。 これは、お客様の管轄区域の法律および規制、つまり EU の GDPR およびカリフォルニア州の CCPA への準拠に影響を与える可能性があります。

1) ODP で識別子を作成します

最初のステップは、ODP で新しい「識別子」を作成することです。 これを行うには、[設定]、[オブジェクトとフィールド]の順に移動し、[新しいフィールドの作成]の横にある矢印をクリックして、ドロップダウンから[識別子]を選択します。

ODP アカウントに対する管理者権限がない場合は、Optimizely サポートに設定を依頼する必要があることに注意してください。

次に、識別子のタイプ (ID、キー、ハッシュなど) を選択し、名前を付けます。 この例 (下の画像を参照) では、「MA」(マーケティング オートメーション) という名前を使用し、「ID」を選択しました。 ODP によって残りのフィールドが自動入力されます。「Singular Field Name」の値が「ma_id」に設定されていることに注意してください。

警告: 識別子名に「ID」という単語を使用しないでください。 たとえば、タイプ「ID」を選択し、識別子を「MA ID」とすると、ODP は自動生成フィールドに「ID」を追加します。 あなたのIDは「ma_id_id」になります。

最後に、「識別子の信頼性」を「高」に設定します。 これは、その識別子が 1 人の訪問者を指しているという確信度が高いことを意味します。 これらのタイプの識別子は、ODP での ID 解決プロセス中にイベントとプロファイルをマージします。 外部システムから選択した識別子が訪問者にとって一意であることを確認するかどうかは、あなたの責任です。

識別子の信頼性の詳細については、Optimizely の優れたサポート記事をご覧ください。 ここ

識別子に設定したフィールドに問題がなければ、「保存」を選択します。 この変更は元に戻せないことを示す警告が表示されます。 これは本当です。 ここでの間違いを元に戻す唯一の方法は、Optimizely がインスタンスを完全にリセットし、あらゆるデータと構成を失うことです。 気をつけて。

識別子を保存すると、「オブジェクトとフィールド」の下にその識別子がリストされるはずです。

2) 外部識別子を渡す

次のステップは、Web サイトに直接戻るパーソナライズされたリンクに、外部システムからの一意の識別子を渡すことです。

Microsoft Dynamics 365 からのパーソナライズされた電子メールでカスタム ID を渡す例を見てみましょう。

2.1) リンクのセットアップ

Dynamics の電子メール テンプレート エディターで、サイトに戻るリンクを更新します。 新しい識別子を表すクエリ パラメータを各リンクに追加します (例: 「?ma_id=」)。

簡単にするために、ODP のカスタム識別子の名前と一致するクエリ文字列キーを選択したことに注意してください (ただし、何でも構いません)。

次に、「個人設定」ボタンを押します。

次のダイアログで、識別子として使用する個人用フィールドを選択できます。 これは、ユーザーを一意に識別する任意の値にすることができますが、ユーザー名や電子メールなどの個人を特定できる情報 (PII) を表すものではないことが理想的です。 ここではアカウント ID を選択しています。

関連するフィールドを選択すると、電子メール テンプレートの URL に口ひげテンプレート コードがクエリ文字列値として入力されていることがわかります。

電子メールが生成されてユーザーに送信されると、リンクが更新され、Dynamics 365 からのユーザーの一意の識別子とともに新しいクエリ パラメーターが含まれます。例: https://mysite.com/?ma_id=1234

2.2) クエリ文字列から ID を取得する

ユーザーが電子メール内のこれらのリンクのいずれかをクリックすると、Web アプリケーションにリダイレクトされ、そこで URL からカスタム ID を取得できます。

次のコード例では、Web アプリケーションのデフォルトの ODP 追跡スクリプトを変更して、ブラウザの現在の URL から「ma_id」を読み取り、ページの読み込み時にこれを ODP に渡します。

このイベントが発生すると、ODP イベント ビューアーで、クエリ文字列からユーザーのマーケティング オートメーション ID (ma_id) がユーザーの Cookie からの訪問者 ID (VUID) とともにキャプチャされたことがわかります。

ODP には、顧客記録を結合するために必要なものがすべて揃っています。 同じユーザーが最初にデスクトップでリンクを開いた後、モバイル デバイスでパーソナライズされたリンクをクリックした場合、ODP は両方のデバイスにわたるユーザーのすべてのインタラクションを調整します。

それでおしまい。

欠点…メールの転送

電子メール追跡における一般的な落とし穴は、電子メールの転送です。 電子メールが転送されると、特に複数回転送されると、追跡データが歪む可能性があります。 これはすべてのマーケティングオートメーションプラットフォームに当てはまります。 私の例では、複数のユーザーが共有電子メール内のリンクをクリックし、これらのユーザーが ODP の 1 つの顧客レコードの下にまとめられるというリスクも伴います。

利点…サードパーティデータのリンク

マーケティング オートメーション ID を顧客レコードの一部に取得したので、これを使用して ODP データをさらに充実させ、さらにパーソナライズされたエクスペリエンスを提供できるようになります。

Dynamics 365 の使用例を見てみましょう。おそらく、旅行会社を経営しており、Dynamics インスタンスが過去 12 か月間に海外旅行したユーザーを記録しているとします。

このコホートのアカウント ID のリストをエクスポートし、ODP のカスタム リストにインポートできます。 次に、インポートされたリストに存在するユーザーのセグメント (またはリアルタイム セグメント) を作成し、これを使用して Web サイトのパーソナライゼーションを推進できます。 たとえば、これらの訪問者がサイトにアクセスしたときに、「最後の海外冒険のことをまだ考えていますか?」などのカスタム バナーを表示できます。

これは、外部システムから PII を持ち込む必要がなく、ID のリストだけで実行できることに注意してください。

まとめ

この記事では、PII データを取得したり依存したりせずに、セッション間および複数のデバイス間で ODP するユーザーを追跡する方法を説明しました。

Microsoft Dynamics 365 で電子メール テンプレートを使用する例を示しましたが、CRM、e コマース、またはマーケティング オートメーション プラットフォームから同じリンクを実行することもできます。 UI 内のリンクまたはプッシュ通知を使用して、モバイル アプリから Web サイトに識別子を渡すこともできます。 一般的に言えば、ユーザーを Web サイトにリンクさせる外部システムがあればどこでも可能です。

これだけの設定が完了すると、訪問者についてさらに詳しく知ることができるようになります。あとは、訪問者にリンクをクリックしてもらうだけです。 ユーザーが共有リンクを操作するように誘導すると、ODP がより多くの顧客レコードをつなぎ合わせることができます。 これにより、サイト訪問者に関するより正確なデータが得られ、より正確なレポートとより適切なパーソナライゼーションを作成できるようになります。

Optimizely と ODP についてさらに詳しく知りたい場合、または実装に関してサポートが必要な場合は、次のアドレスまでご連絡ください。 オーチャード を通して [email protected]。