ビジタースティッチングのシナリオ | ビジターのスティッチング |Tealiumドキュメント

同じユーザーが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属性で一致した場合にスティッチングされる可能性があります。

結果： それぞれのメールアドレスハッシュに構成されたビジターID属性を持つ2つのビジタープロファイル。

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

この例では、ユーザーが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つはTwitterハンドルをキャプチャします。

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

twitterハンドルでビジタースティッチングマッチが発生します。twitterハンドルは同じですが、メールアドレスは異なります。今、何が起こりますか？

回答

二つのデバイスからのプロファイルは、Twitterのハンドルに基づいて一緒に縫い合わせられます。

マスターの縫い合わせられたプロファイルが作成されると、Twitterのハンドルとメールアドレスの二つのセカンダリIDが作成されます。TwitterのハンドルのセカンダリIDは、両方のデバイスでハンドルが同じであるため、marketerxyzに構成されます。

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

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

二つの訪問プロファイルが異なる属性値で縫い合わせられた場合、何が起こるのでしょうか？

二つの訪問プロファイルが縫い合わせられ、それぞれのプロファイルに属性が存在するが、値が異なる場合、何が起こるのでしょうか？

例えば：

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

回答

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

イベントがAudienceStreamにフィードされると、これらのイベントは訪問プロファイルを作成するために使用されます。
訪問の訪問が期限切れになると、訪問とその訪問のすべてのイベントが二つの異なる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のタイムラインのタイムスタンプと参加/離脱の日付にどのような影響を与えるのでしょうか？

タイムスタンプは、単一のイベントが発生したときを表し、縫い合わせイベントが発生したときを表すものではありません。