ユーザー識別子の選択に関するベストプラクティス

ユーザー識別子について

ユーザー識別子は、デバイス、プラットフォーム、ブラウザー間でユーザーを一意に識別するTealiumインストールのデータレイヤー変数です。

ユーザー識別子は、訪問プロファイルの訪問ID属性を構成するために使用されます。訪問スティッチングは、訪問ID属性を使用して、一致する訪問ID値を持つ複数のデバイスおよびブラウザーからの訪問プロファイルを組み合わせます。

次の図は、ユーザー識別子 hashed_email_address（イベント属性）によって構成される Hashed email address という訪問ID属性の例を示しています：

ユーザー識別子はTealiumによって自動的に作成または構成されるものではありません。これらの属性は、使用事例に基づいて構成する必要があります。

要件

ユーザー識別子は、以下の要件を満たす必要があります：

• 各訪問に対して一意であること。
• 最小6文字の長さで、少なくとも3つの一意の文字を含むこと。
• プラットフォーム、デバイス、ブラウザー間で一貫した大文字小文字を持つこと。
• すべてのデータソースで持続すること。

ユーザー識別子が一意でない場合、訪問スティッチングプロセスは誤って2つの関連性のないプロファイルを組み合わせる可能性があり、これは元に戻すことができません。

詳細については、訪問スティッチングについておよび訪問ID属性を参照してください。

ユーザー識別子の選び方

ユーザー識別子を選択するには、ウェブサイト、アプリ、または店舗の訪問に対して現在収集している識別子のリストを作成します。次に、各識別子について以下を決定します：

• 各訪問に対して値が一意であるか？
• すべてのデータソースから利用可能か？

ビジネスのすべての領域に共通の識別子を選択し、各訪問に対して一意の値を持つものを選びます。たとえば、メールアドレスや電話番号は、ウェブサイト、モバイルアプリ、またはビジネスでの対面のやり取りから得られる可能性があります。

識別子は、オンラインおよび店舗での購入など、異なるソースからの訪問がスティッチングされるために、すべてのデータソースから利用可能であることが重要です。

良いユーザー識別子の例

以下は良いユーザー識別子です：

• Hashed email address
• Hashed phone number
• The Trade Desk Unified ID
• Customer ID
• Patient ID
• Member ID
• Account ID
• Student ID

ユーザー識別子のハッシュ化についての詳細は、PIIを含む値のハッシュ化を参照してください。

不適切なユーザー識別子の例

以下のIDは適切なユーザー識別子ではありません：

• マーケティング活動ID - ユーザーではなく、マーケティングアクションやキャンペーン用のIDです。たとえば、Adobe Marketing Cloud IDやGoogle Client IDなどです。
• ベンダーID - ソフトウェアやサービスベンダーのIDです。
• デバイスID - 複数のユーザーによって使用される可能性があります。
• 匿名ID - ユーザーが異なるデバイスやブラウザーからログインすると変更されます。

マーケティング活動IDやベンダーIDは良いユーザー識別子にはなりませんが、コネクタアクションで使用する訪問属性として保存する場合には役立つことがあります。

ユーザー識別子の最大数

ベストプラクティスとしては、訪問ID属性を最大2つまで構成することが推奨されます。

2つ以上の訪問IDを使用する場合、特定のスティッチングシナリオでは、それらを組み合わせるのではなく、2つの別々のプロファイルを作成する可能性があります。

また、イベントで1つのユーザー識別子のみを構成することが重要です。単一のイベントで複数のユーザー識別子を構成すると、予期しないスティッチング結果につながることもあります。

訪問スティッチングを有効にした後、追加の訪問ID属性を追加する前に、Tealium担当者に相談することをお勧めします。

ユーザー識別子の準備

訪問ID属性に割り当てる前にユーザー識別子を検証および正規化するためのベストプラクティスを以下に示します。これらの前処理技術は、独自のコードまたは拡張機能およびエンリッチメントを使用して実装できます。

メールアドレスの検証

メールアドレスをユーザー識別子として使用する場合、@記号が含まれているか、正規表現を使用して値が有効なメールアドレスであることを確認することがベストプラクティスです。ユーザー識別子の値が未定義である場合や他の無効な値である場合、それを使用して訪問ID属性を構成することは望ましくありません。これにより、関連性のないプロファイルがスティッチングされる原因となります。

次の図は、メールアドレスを検証するために正規表現を使用するSet Data Values拡張機能の構成の例を示しています：

この例では、次の正規表現を使用してメールアドレスを検証し、値を構成しています：

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

メールアドレスの正規化

異なるデータソースからの文字列属性（例：メールアドレス）は、異なる大文字小文字の規則を使用する場合があります。たとえば、一部は値に大文字を使用し、他はすべて小文字を使用する場合があります。これらの値を正規化する（すべて小文字に変更する）ことがベストプラクティスです。たとえば、次のメールアドレスは、小文字に正規化されない限り、同じものとは見なされません：

• abby.adams@acme.com
• Abby.Adams@acme.com
• ABBY.ADAMS@ACME.com

ユーザー識別子の値を構成し、値を正規化する方法については、ユーザー識別子の値を構成するを参照してください。

電話番号の正規化

電話番号をユーザー識別子として使用する場合、値を数字のみを含むように正規化することがベストプラクティスです。電話番号に含まれる文字は国によって異なり、以下のようになります：

• 数字のグループはスペース、ダッシュ、ピリオド、またはこれらの文字の組み合わせで区切られる場合があります。
• エリアコードまたは市外局番は括弧で囲まれることがあり、数字の数は異なる場合があります。
• 電話番号の数字の数も異なる場合があり、固定電話と携帯電話では異なる場合があります。
• 国コードは通常、+に続いて1〜4桁の数字で始まります。最初と2番目の数字の間にダッシュがある場合があります。一部の国では国コードを括弧で囲むことがあります。

次の表は、電話番号のさまざまな形式がどのように正規化されるべきかの例を示しています：

PIIを含む値のハッシュ化

個人を特定できる情報（PII）を含むユーザー識別子（例：メールアドレスや電話番号）は、ユーザーのプライバシーを保護するためにハッシュ化する必要があります。ハッシュ関数（例：SHA256）は、機密情報を含むテキスト値を匿名で一意の固定長の文字列に変換し、その一意性を保持します。

ユーザー識別子はハッシュ化する前に正規化する必要があります。

Crypto拡張機能の使用についての情報は、ユーザー識別子の値を構成するおよびCrypto拡張機能を参照してください。

暗号拡張の例

次の例では、customer_email というデータレイヤー変数をハッシュ化しています：

> utag_data.customer_email
< "test@tealium.com"

暗号拡張を構成して customer_email をSHA-1暗号ハッシュ関数を使用して変換すると、新しい値は次のようになります：

> utag_data.customer_email
< "05fcf31275aa13408ace62e84dac60ae4b805a65"

customer_email を保持し、ハッシュ値を作成するには、customer_email_hash という名前の第二の変数を使用します。まず、Set Data Values extensionを使用して、customer_email の値に customer_email_hash ハッシュ変数を初期化し、その後、暗号拡張でハッシュ化します。これにより、新しいハッシュ値を作成した後に元の値を保持できます：

> utag_data.customer_email
< "test@tealium.com"
> utag_data.customer_email_hash
< "05fcf31275aa13408ace62e84dac60ae4b805a65"

ユーザー識別子の値を構成する

次の図は、ユーザー識別子として使用されるデータレイヤー変数の値を構成する例を示しています。この例では、値を構成し、値を小文字にし、値をハッシュ化するために三つの拡張を使用しています。

詳細については、Set Data Values extension および Crypto extension を参照してください。

資格イベントで訪問IDを構成する

訪問IDは、資格イベント中にのみ構成されるべきです。資格イベントは、アカウントの作成や購入の完了など、信頼できる識別手段を顧客が提供するときに発生します。

例えば、購入時にユーザーがメールアドレスを提供する場合、そのメールアドレスは小文字にされ、ハッシュ化されます。これは、Verify and normalize email addresses および Hash user identifiers that contain PII で説明されています。購入イベントが発生したときにユーザー識別子の値に訪問ID属性を構成するためにエンリッチメントを使用します。

次の図は、購入イベントが発生したときに値を構成するエンリッチメントを持つ訪問ID属性の例を示しています：

追加のリソース

• About visitor stitching
• Visitor stitching guidelines
• Visitor ID attribute