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

同じユーザーが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回目の訪問後にこのユーザーの2つのプロファイルがあります。ビジターID属性が一致しない（メールアドレスが異なる）ため、ビジタースティッチングは発生しません。これら2つのプロファイルは、後で2つ目のビジターID属性で一致した場合にスティッチングされる可能性があります。

結果： 2つのビジタープロファイルがあり、それぞれのビジターID属性が対応するメールアドレスハッシュに構成されています。

2つのビジタープロファイルが2つ目のビジターID属性で一致する例

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

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

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

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

Profile Cには新しいreplaces配列が含まれており、これはビジターID属性には保存されていないが、将来的にビジタースティッチングに使用できる値を保持しています。Profile AとProfile Bは匿名IDとビジターID属性＃1（顧客ID）の値が異なっていました。ビジターID属性ごとに1つの値しか構成できないため、2つの値をreplaces配列に移動する必要がありました。Profile Bは新しいプロファイルで、Profile Aよりもイベントが少なかったため、Profile 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つの訪問プロファイルがステッチされ、それぞれのプロファイルに属性が存在するが値が異なる場合、何が起こるでしょうか？

例えば：

デスクトップデバイスでは、「Opt-In Status」フラグが「True」
モバイルデバイスでは、「Opt-In Status」フラグが「False」

回答

まず、いくつかの重要なシステム機能について注意しておく必要があります。

イベントがAudienceStreamにフィードされると、これらのイベントは訪問プロファイルを作成するために使用されます。
訪問の訪問が期限切れになると、訪問とその訪問のすべてのイベントが2つの異なるDBコレクションに保存されます（EventStoreログとは別に）。
訪問の寿命の間には数百、あるいは数千のイベントが発生することがあり、これらの永続化されたイベントの大部分はほとんど使用されず、訪問プロファイルが期限切れになると期限切れになります。

この基礎が整ったところで、スティッチングイベントが発生したときに何が起こるかを説明できます。一致するプロファイルが見つかると、AudienceStreamはスティッチングされるすべての訪問のすべての過去のイベントをロードし、各イベントを時系列に並べ替え、すべてのイベントを再生して主要なスティッチングプロファイルを作成します。

したがって、質問に戻ると、「Opt-In Status」フラグが「True」に構成されるか「False」に構成されるかは、AudienceStreamがこれらの訪問の過去のイベントをすべて再処理するときに再処理されるすべてのエンリッチメントの結果によります。

その他の注意事項と可能な質問

listやtallyのようなより高度な属性についても興味があるかもしれません。tallyやlistの属性はマージされているように見えますが、これは加算エンリッチメント（リストに追加、tallyを増やすなど）を使用して構成されているためです。これらは通常、過去に正しくステッチされています。

イベントの数によっては、スティッチングは非常に複雑でCPUを大量に消費するタスクを実行するため、実行に時間がかかることがあります。しかし、過去数年間でエンジニアリングはこのスティッチングプロセスをより効率的にするための多くの最適化を行ってきました。通常、これは非常に迅速なプロセスです。

これはスティッチングが後方互換性を持つことを意味するのでしょうか？以下のようなイベントのシナリオを想像してみてください：

顧客がデスクトップでウェブサイトに登録
- customer_typeがASに渡される
- customer_emailがASに渡される
AudienceStream内
- Visitor IDはcustomer_emailを使用して割り当てられる
- customer_typeは無視される
1週間後にcustomer_typeを保存するTraitが作成される
2週間後に訪問が同じcustomer_email値でモバイルで認証する（ただしcustomer_typeは渡されない）
デスクトップとモバイルのプロファイルをスティッチングする

customer_typeをキャプチャするTraitは、どちらのデバイスの訪問プロファイルにも存在していませんでした。しかし、ASがすべてのイベントを再処理するとき、AudienceStreamは最新のAudienceStreamプロファイル定義を使用し、Traitのエンリッチメントを再評価します。これは、主要な訪問プロファイルがcustomer_typeを保存するTraitを持つことを意味します。

これはどのようにOmnichannelデータに影響しますか？

Omnichannelデータはイベントデータと見なされ、同様の方法で動作します。つまり、イベントデータはEvent Databaseに永続化され、時系列にオンラインイベントデータの一部となります。

これはどのようにAudienceStoreのタイムラインのタイムスタンプと参加/離脱日に影響しますか？

タイムスタンプはスティッチングイベントが発生したときではなく、単一のイベントが発生したときを表します。