ユーザー識別子の選択におけるベストプラクティス
このガイドでは、訪問のID属性に最適なユーザー識別子を選択するためのベストプラクティスを提供します。
ユーザー識別子について
ユーザー識別子は、Tealiumのインストールにおけるデータレイヤー変数で、デバイス、プラットフォーム、ブラウザー間でユーザーを一意に識別します。
ユーザー識別子は、訪問プロファイルの訪問ID属性を構成するために使用されます。訪問のスティッチングは、訪問ID属性を使用して、訪問ID値が一致する複数のデバイスとブラウザーからの訪問プロファイルを結合します。
次の図は、ユーザー識別子 hashed_email_address（イベント属性）によって訪問ID属性 Hashed email address が構成される例を示しています：
ユーザー識別子はTealiumによって自動的に作成または構成されません。これらの属性は、あなたのユースケースに基づいて構成する必要があります。
要件
ユーザー識別子は以下の要件を満たす必要があります：
- 訪問ごとに一意であること。
- 長さが最低6文字で、少なくとも3つの一意の文字を含むこと。
- プラットフォーム、デバイス、ブラウザー間で一貫した大文字小文字を持つこと。
- すべてのデータソース間で持続すること。
ユーザー識別子が一意でない場合、訪問のスティッチングプロセスが誤って2つの関連性のないプロファイルを結合する可能性があり、これは元に戻すことができません。
詳細については、訪問のスティッチングについてと訪問ID属性を参照してください。
ユーザー識別子の選択方法
ユーザー識別子を選択するために、あなたのウェブサイト、アプリ、またはストアの訪問に対して現在収集している識別子をリストアップします。次に、各識別子について以下を決定します：
- 値は訪問ごとに一意ですか？
- それはすべてのデータソースから利用可能ですか？
あなたのビジネスのすべてのエリアに共通で、各訪問に一意の値を持つ識別子を選択します。例えば、メールアドレスや電話番号はあなたのウェブサイト、モバイルアプリ、またはあなたのビジネスでの対面のやり取りから来ることがあります。
識別子はまた、オンラインと店舗での購入など、異なるソースからの訪問がスティッチングされるように、すべてのデータソースから利用可能であるべきです。
良いユーザー識別子の例
以下は良いユーザー識別子の例です：
- ハッシュ化されたメールアドレス
- ハッシュ化された電話番号
- The Trade Desk Unified ID
- 顧客ID
- 患者ID
- メンバーID
- アカウントID
- 学生ID
ユーザー識別子のハッシュ化についての詳細は、PIIを含む値のハッシュ化を参照してください。
良くないユーザー識別子の例
以下のIDは適切なユーザー識別子ではありません：
- マーケティング活性化ID - ユーザーではなく、マーケティングアクションやキャンペーンのID。例えば、Adobe Marketing Cloud IDやGoogle Client ID。
- ベンダーID - ソフトウェアやサービスベンダーのID。
- デバイスID - 複数のユーザーによって使用される可能性があります。
- 匿名ID - ユーザーが別のデバイスやブラウザからログインすると変わります。
マーケティング活性化IDとベンダーIDは良いユーザー識別子にはなりませんが、コネクタアクションで使用するために訪問属性として保存するときには役立ちます。
ユーザー識別子の最大数
ベストプラクティスは、訪問ID属性を最大2つ構成することです。
2つ以上の訪問IDが使用されると、特定のスティッチングシナリオでは、プロファイルを結合する代わりに2つの別々のプロファイルが作成される可能性があります。
また、イベントで1つのユーザー識別子のみを構成することも重要です。1つのイベントで複数のユーザー識別子を構成すると、予期しないスティッチング結果につながる可能性があります。
訪問のスティッチングを有効にした後、追加の訪問ID属性を追加する前に、Tealiumのカスタマーサクセスチームに相談することをお勧めします。
ユーザー識別子の準備
以下のベストプラクティスを使用して、ユーザー識別子を検証し、正規化し、訪問ID属性に割り当てる前に準備します。これらの前処理技術は、あなた自身のコードや拡張機能、エンリッチメントを使用して実装することができます。
メールアドレスの検証
メールアドレスをユーザー識別子として使用する場合、値が有効なメールアドレスであることを確認することがベストプラクティスです。例えば、@記号のチェックや正規表現の使用などです。ユーザー識別子の値が未定義、または他の無効な値である場合、それを訪問ID属性に構成することは避けてください。そうすると、関連性のないプロファイルがスティッチングされる原因となります。
次の図は、正規表現を使用してメールアドレスを検証するSet Data Values拡張機能の構成の例を示しています：
この例では、次の正規表現を使用してメールアドレスを検証し、値を構成します：
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
メールアドレスの正規化
異なるデータソースからの文字列属性（例えばメールアドレス）は、異なる大文字小文字の規則を使用することがあります。例えば、一部は値に大文字を使用し、他の一部はすべて小文字を使用するかもしれません。これらの値を正規化する（すべて小文字に変更する）ことがベストプラクティスです。これはLower-Casing extensionを使用して行います。
例えば、次のメールアドレスは、小文字に正規化されるまで同一とは見なされません：
abby.adams@acme.comAbby.Adams@acme.comABBY.ADAMS@ACME.com
ユーザー識別子の値を構成し、値を正規化する方法については、ユーザー識別子の値の構成を参照してください。
電話番号の正規化
電話番号をユーザー識別子として使用する場合、値を数字のみに正規化することがベストプラクティスです。電話番号に含まれる文字は、国によって異なります：
- 数字のグループは、スペース、ダッシュ、ピリオド、またはこれらの文字の組み合わせで区切られることがあります。
- エリアコードや市外局番は括弧で囲まれ、数字の数は異なることがあります。
- 電話番号の数字の数も異なることがあり、固定電話と携帯電話では異なることもあります。
- 国コードは通常、
+に続く1から4桁の数字で始まります。最初と2番目の数字の間にダッシュがあることがあります。一部の国では、国コードを括弧で囲むことがあります。
次の表は、電話番号のさまざまな形式がどのように正規化されるべきかを示す例を示しています：
| 国 | 番号 | 正規化後 |
|---|---|---|
| ブラジル | +55 (11) 91234-5678 | 5511912345678 |
| フランス | +33 6 12.34.56.78 | 33612345678 |
| 日本 | +81 90-1234-5678 | 819012345678 |
| ウクライナ | +380 (50) 987-65-43 | 380509876543 |
| イギリス（固定電話） | +44 20 1234 5678 | 442012345678 |
| イギリス（携帯電話） | +44 7723 45678 | 44772345678 |
| アメリカ | +1 (123) 456-7890 | 11234567890 |
PIIを含む値のハッシュ化
メールアドレスや電話番号など、個人を特定可能な情報（PII）を含むユーザー識別子は、ユーザーのプライバシーを保護するためにハッシュ化するべきです。ハッシュ関数（例えばSHA256）は、敏感な情報を含むテキスト値を匿名で一意の固定長の文字列に変換し、その一意性を保持します。
ユーザー識別子は、ハッシュ化する前に正規化されるべきです。
Crypto拡張機能の使用については、ユーザー識別子の値の構成とCrypto拡張機能を参照してください。
Crypto拡張機能の例
次の例では、customer_emailという名前のデータレイヤー変数をハッシュ化します：
> utag_data.customer_email
< "test@tealium.com"
Crypto拡張機能を構成してcustomer_emailをSHA-1暗号化ハッシュ関数で変換すると、新しい値は次のようになります：
> utag_data.customer_email
< "05fcf31275aa13408ace62e84dac60ae4b805a65"
customer_emailを保持し、ハッシュ値を作成するには、customer_email_hashという名前の2つ目の変数を使用します。まず、Set Data Values extensionを使用してハッシュ変数customer_email_hashをcustomer_emailの値に初期化し、次にCrypto拡張機能でそれをハッシュ化します。これにより、新しいハッシュ値を作成した後も元の値が保持されます：
> utag_data.customer_email
< "test@tealium.com"
> utag_data.customer_email_hash
< "05fcf31275aa13408ace62e84dac60ae4b805a65"
ユーザー識別子の値を構成する
以下の図は、データレイヤー変数を構成し、それをユーザー識別子として使用する例を示しています。値を構成し、値を小文字にし、値をハッシュ化するために3つの拡張機能を使用します。
詳細については、Set Data Values extensionとCrypto extensionを参照してください。
資格イベントで訪問IDを構成する
訪問IDは、資格イベント中にのみ構成する必要があります。資格イベントは、アカウントを作成したり、購入を完了したりするなど、顧客が信頼性のある識別手段を提供するときに発生します。
例えば、ユーザーが購入時にメールアドレスを提供した場合、そのメールアドレスは、Verify and normalize email addressesとHash user identifiers that contain PIIで説明されているように、小文字に変換され、ハッシュ化されます。購入イベントが発生したときに、ユーザー識別子の値を訪問ID属性に構成するためにエンリッチメントを使用します。
以下の図は、購入イベントが発生したときに値を構成するエンリッチメントを持つ訪問ID属性の例を示しています：
追加のリソース
最終更新日 :: 2025年January月31日