訪問スティッチングのシナリオ | ビジターのスティッチング

同一ユーザーが2つのメールアドレスで識別される場合、結果は各々のデバイスとブラウザに基づいています。

例えば、ユーザーが初めてウェブサイトを訪れ、フォームを提出する際にメールアドレスを提供します。メールアドレスはハッシュ化され、Email Address Hash 訪問ID属性を豊かにし、AudienceStreamに新しい訪問プロファイルが作成されます。

結果として得られる訪問プロファイルは以下のようになります：

属性	値
匿名ID	01754649ad73005a6d584d2732c401078005b0700093c
デバイス	ラップトップ
ブラウザ	Chrome 89
メールアドレスハッシュ	16c18d336f0b250f0e2d907452ceb9658a74ecdae8bc94864c23122a72cc27a5

シナリオ1: 同じデバイスとブラウザからの異なるメールアドレス

1週間後、ユーザーが同じデバイスとブラウザを使用してウェブサイトを訪れ、異なるメールアドレスでフォームを提出します。これには以下の2つの方法があります：

ケースA: 同じユーザーが異なるメールアドレスでフォームを提出します。
ケースB: 2人のユーザーがデバイスを共有し、異なるユーザーが異なるメールアドレスでフォームを提出します。

ケースA

匿名IDは同じなので、受信イベントはユーザーの最初の訪問時に作成されたプロファイルと一致します。しかし、訪問ID属性は変更できないため、新しいメールアドレスハッシュ値は使用されません。

ケースAの結果： 訪問ID属性が元のメールアドレスハッシュに構成された1つの訪問プロファイル。

ケースB

デバイスを共有し、異なるユーザー識別子（この場合はメールアドレス）を使用して同じウェブサイトを訪れるユーザーは、訪問切り替えと呼ばれます。Tealiumサポートまたはプロフェッショナルサービスが訪問切り替えを処理するソリューションの実装を支援できます。詳細については、以下のTealiumナレッジベース記事を参照してください：

シナリオ2: 異なるデバイスまたはブラウザからの異なるメール

1週間後、同じユーザーが異なるデバイスまたはブラウザを使用してウェブサイトを訪れ、異なるメールアドレスでフォームを提出します。匿名IDが異なるため、受信イベントはユーザーの最初の訪問時に作成されたプロファイルと一致しません。新しいプロファイルが作成され、このユーザーには2つのプロファイルがあります。訪問ID属性が一致しないため（メールアドレスが異なるため）、訪問スティッチングは発生しません。これらの2つのプロファイルは、後で2番目の訪問ID属性で一致した場合にスティッチングされる可能性があります。

結果： 各訪問ID属性が対応するメールアドレスハッシュに構成された2つの訪問プロファイル。

2番目の訪問ID属性で一致する2つの訪問プロファイルの例

この例では、ユーザーが2つの異なるデバイスからウェブサイトを訪れ、各訪問で顧客IDが割り当てられます。匿名IDが一致せず、2つの別々のプロファイルが作成されます。顧客IDは訪問ID属性#1をエンリッチするように構成されており、以下に示すように各プロファイルで訪問ID属性が豊かにされます。

このシナリオは、匿名ID（tealium_visitor_id）が不明であるか、2つのプロファイルで異なる場合にのみ発生します。匿名IDが一致する場合、ユーザーIDや訪問ID属性は評価されず、2番目のプロファイルは作成されません。

ユーザーが最初のデバイスから再びウェブサイトを訪れ、フォームを提出する際にメールアドレスを提供します。customer_emailアドレス属性は訪問ID属性#2をエンリッチするように構成されています。プロファイルAの訪問ID属性#2は、以下に示すようにメールアドレスで豊かにされます。

ユーザーが2番目のデバイスからウェブサイトを訪れ、フォームを提出する際に同じメールアドレスを提供すると、メールアドレスがプロファイルAの訪問ID属性#2と一致し、2つのプロファイルがスティッチングされてプロファイルCが作成されます。以下に示すようになります。

プロファイルCには新しいreplaces配列が含まれており、訪問ID属性にはもはや格納されていませんが、将来の訪問スティッチングには引き続き使用できます。プロファイルAとプロファイルBは匿名IDと訪問ID属性#1（顧客ID）の値が異なっていました。訪問ID属性ごとに1つの値しか構成できないため、2つの値をreplaces配列に移動する必要がありました。プロファイルBは新しいプロファイルであり、プロファイルAよりもイベントが少なかったため、プロファイルBの識別子がreplaces配列に移動されました。

HTTP APIおよびファイルインポートデータソース

ウェブまたはHTTP APIデータソースの場合、このシナリオは訪問ID属性#1（顧客ID）の属性ID値が訪問ID属性#2（ハッシュ化されたメール）より低い場合にのみ発生します。

ファイルインポートでは、訪問IDマッピングをカスタマイズでき、ユーザー識別子の豊か化はマッピングされた順序で発生します。このシナリオは、セットアップに応じていくつかの異なる方法で達成できます。

詳細については、Tealium Collect HTTP API、インカミングウェブフックについて、またはファイルインポートについてを参照してください。

状態のないイベント

HTTP APIとファイルインポートは、tealium_visitor_id値が自動的に割り当てられないため、状態のないイベントを送信します。HTTP APIリクエストの場合、各イベントはtealium_visitor_idが構成されていない限り、新しい訪問プロファイルを生成します。この場合、tealium_visitor_idの匿名値を生成することをお勧めします。

ファイルインポートデータソースは通常、訪問ID属性にマッピングされるユーザー識別子を含んでいます。

HTTP APIリクエストまたはファイルインポートマッピングにtealium_visitor_id値が含まれていない場合、AudienceStreamは匿名IDにランダム値を割り当て、訪問スティッチングの前に新しい訪問プロファイルを作成します。

追加のシナリオ

ステッチイベント中に2つの異なる訪問ID属性値がある場合はどうなりますか？

2つの訪問ID属性が定義されています。1つの訪問ID属性はメールアドレスをキャプチャし、もう1つはXハンドルをキャプチャします。

ユーザーがコンピュータからサイトを訪れ、marketer@xyzcorp.comメールアドレスでニュースレターにサインアップします。同じセッション内で、ユーザーは製品を見て、marketerxyz Xハンドルを使用してツイートします。その後、ユーザーはタブレットを使用してname@xyzcorp.comメールアドレスで注文を提出します。ユーザーは注文についてmarketerxyz Xハンドルを使用してツイートします。

Xハンドルで訪問スティッチングの一致が発生します。Xハンドルは同じですが、メールアドレスは異なります。今、何が起こるでしょうか？

回答

2つのデバイスからの2つのプロファイルは、Xハンドルに基づいて結合されます。

主要な結合プロファイルが作成されると、Xハンドルとメールアドレス用に2つのセカンダリIDが作成されます。XハンドルのセカンダリIDは、両方のデバイスでハンドルが同じであるため、marketerxyzに構成されます。

訪問の結合中に、プロファイルの過去のイベントがすべて時系列順に並べ替えられ、再処理されます。メールのセカンダリIDは、再処理中に最初に遭遇したメールアドレス、この場合はmarketer@xyzcorp.comに構成されます。

将来的には、どちらのメールアドレスも訪問プロファイルに結合するために使用できます。これは、異なるメールアドレスとプロファイルを持つ2つの別々のデバイスが後でXハンドルに基づいて結合されたために適用されます。

2つの訪問プロファイルが異なる属性値で結合された場合はどうなりますか？

2つの訪問プロファイルが結合され、それぞれのプロファイルに異なる値を持つ属性が存在する場合はどうなりますか？

例えば：

デスクトップデバイスでは、「オプトインステータス」フラグが「True」
モバイルデバイスでは、「オプトインステータス」フラグが「False」

回答

まず、いくつかの重要なシステム機能について注意することが重要です。

イベントがAudienceStreamにフィードされると、これらのイベントは訪問プロファイルを作成するために使用されます。
訪問の訪問が期限切れになると、訪問とその訪問のすべてのイベントは、EventStoreログとは別の2つの異なるDBコレクションに保存されます。
訪問の生涯にわたって、何百ものイベントが発生することがあり、そのほとんどは訪問プロファイルが期限切れになるときに使用されることはなく、期限切れになります。

この基盤を構成した上で、結合イベントが発生した際に何が起こるかについて議論することができます。一致するプロファイルが見つかると、AudienceStreamはすべての訪問の過去のイベントを読み込み、各イベントを時系列順に並べ替え、すべてのイベントを再生して主要な結合プロファイルを作成します。

したがって、質問に戻ると、「オプトインステータス」フラグが「True」または「False」に構成されるかどうかは、AudienceStreamがこれらの訪問の過去のイベントをすべて再生する際に再処理されるすべてのエンリッチメントの結果に依存します。