訪問のスティッチングシナリオ

同じユーザーが2つのメールアドレスで識別された場合、結果はそれぞれのデバイスとブラウザに基づきます。

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

以下は、作成された訪問プロファイルの例です：

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

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

1週間後、同じユーザーが同じデバイスとブラウザを使用してウェブサイトを訪れ、異なるメールアドレスでフォームを送信します。匿名IDは同じなので、受信イベントは最初の訪問時に作成されたプロファイルと一致します。ただし、訪問ID属性は変更できないため、新しいメールアドレスのハッシュ値は使用されません。

結果: 元のメールアドレスのハッシュ値が構成された1つの訪問プロファイル。

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

1週間後、同じユーザーが異なるデバイスまたはブラウザを使用してウェブサイトを訪れ、異なるメールアドレスでフォームを送信します。匿名IDが異なるため、受信イベントは最初の訪問時に作成されたプロファイルと一致しません。新しいプロファイルが作成され、2回目の訪問後にこのユーザーには2つのプロファイルがあります。訪問ID属性が一致しないため、訪問スティッチングは行われません（メールアドレスが異なるため）。これらの2つのプロファイルは、2番目の訪問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には、訪問ID属性には保存されていない値を保持する新しい replaces 配列が含まれていますが、将来の訪問スティッチングに使用することができます。プロファイルAとプロファイルBは匿名IDと訪問ID属性＃1（顧客ID）の値が異なっていました。訪問ID属性ごとに1つの値しか構成できないため、2つの値は replaces 配列に移動する必要がありました。プロファイルBは新しいプロファイルであり、プロファイルAよりもイベントが少なかったため、プロファイルBの識別子が replaces 配列に移動されました。

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

Webまたは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ハンドルは同じですが、メールアドレスは異なります。今後どうなるでしょうか？

回答

2つのデバイスからの2つのプロファイルは、Twitterハンドルに基づいてスティッチングされます。

マスタースティッチングプロファイルが作成されると、Twitterハンドルとメールアドレスの2つのセカンダリIDが作成されます。TwitterハンドルのセカンダリIDは、両方のデバイスで同じハンドルが使用されているため、marketerxyzに構成されます。

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

将来的には、どちらのメールアドレスでも訪問プロファイルにスティッチングすることができます。これは、2つの別々のデバイスがあり、異なるメールアドレスとプロファイルが後でTwitterハンドルに基づいてスティッチングされた場合にのみ適用されます。

異なる属性値を持つ2つの訪問プロファイルがスティッチングされた場合はどうなりますか？

2つの訪問プロファイルがスティッチングされ、各プロファイルに属性が存在するが、値が異なる場合はどうなりますか？

例えば：

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

回答

まず、いくつかの重要なシステム機能について説明します。

• AudienceStreamにイベントがフィードされると、これらのイベントは訪問プロファイルを作成するために使用されます。
• 訪問の訪問が期限切れになると、訪問とその訪問のすべてのイベントは、EventStoreログとは別の2つの異なるDBコレクションに格納されます。
• 訪問の寿命にわたって、何百、何千というイベントが発生することがあり、そのうちの大部分は使用されず、訪問プロファイルの期限切れ時に期限切れになります。

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

では、Opt-In StatusフラグがTrueまたはFalseに構成されるかどうかですが、それはAudienceStreamがこれらの訪問の過去のすべてのイベントを再処理する際に行われるすべての補完の結果に依存します。

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

listおよびtallyなどのより高度な属性についても興味があるかもしれません。tallyおよびlist属性は、加算的な補完（リストへの追加、集計の増加など）を使用して構成されているため、通常は正しくスティッチングされています。

イベントの数によっては、スティッチングには時間がかかる場合があります。スティッチングは非常に複雑でCPUを多く使用するタスクであるため、最適化が行われていますが、通常は非常に迅速なプロセスです。

これはスティッチングが後方互換性があることを意味しますか？イベントのシナリオを想像してみてください。

• 顧客がデスクトップでウェブサイトに登録する

  • customer_typeがASに渡される
  • customer_emailがASに渡される

• AudienceStream内で

  • 訪問IDがcustomer_emailを使用して割り当てられる
  • customer_typeは無視される

• 1週間後にcustomer_typeを格納するTraitが作成される

• 2週間後に顧客がモバイルで認証し、同じcustomer_email値を使用します（ただし、customer_typeは渡されません）

• デスクトップとモバイルのプロファイルをスティッチングします

customer_typeをキャプチャするTraitは、どちらのデバイスの訪問プロファイルにも存在しませんでした。ただし、AudienceStreamはすべてのイベントを再処理する際に、最新のAudienceStreamプロファイル定義を使用してTraitの補完を再評価します。つまり、マスター訪問プロファイルには、customer_typeを格納するTraitが含まれるようになります。

これはオムニチャネルデータにどのように影響しますか？

オムニチャネルデータはイベントデータと見なされ、イベントデータは同じように動作します。つまり、イベントデータはイベントデータベースに永続的に保存され、オンラインイベントデータの一部として時系列になります。

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

タイムスタンプは、単一のイベントが発生した時点を表します。スティッチングイベントが発生した時点ではありません。