---
title: ユーザー識別子の選択に関するベストプラクティス
description: このガイドでは、訪問のID属性に最適なユーザー識別子を選択するためのベストプラクティスについて説明します。
url: https://docs.tealium.com/ja/guides/user-identifier-guide/
---
## ユーザー識別子について
ユーザー識別子は、デバイス、プラットフォーム、ブラウザー間でユーザーを一意に識別するTealiumインストールのデータレイヤー変数です。
ユーザー識別子は、訪問プロファイルの訪問ID属性を構成するために使用されます。訪問スティッチングは、訪問ID属性を使用して、一致する訪問ID値を持つ複数のデバイスおよびブラウザーからの訪問プロファイルを結合します。
次の図は、ユーザー識別子 `hashed_email_address`（イベント属性）によって構成される訪問ID属性 `Hashed email address` の例を示しています：
ユーザー識別子は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は良いユーザー識別子にはなりませんが、コネクタアクションで使用するために訪問属性として保存すると便利です。
### ユーザー識別子の最大数
ベストプラクティスとしては、最大で2つの訪問ID属性を構成することです。
2つ以上の訪問IDを使用する場合、特定のスティッチングシナリオでは、プロファイルを結合するのではなく、2つの別々のプロファイルを作成する可能性があります。
また、イベントで1つのユーザー識別子のみを構成することが重要です。単一のイベントで複数のユーザー識別子を構成すると、予期しないスティッチング結果につながることもあります。
訪問スティッチングを有効にした後、追加の訪問ID属性を追加する前に、Tealiumカスタマーサクセスチームに相談することをお勧めします。
## ユーザー識別子の準備
訪問ID属性に割り当てる前に、ユーザー識別子を検証および正規化するためのベストプラクティスを使用します。これらの前処理技術は、独自のコードまたは拡張機能およびエンリッチメントを使用して実装できます。
### メールアドレスの検証
メールアドレスをユーザー識別子として使用する場合、値が有効なメールアドレスであることを確認することがベストプラクティスです。たとえば、`@`記号が含まれているかどうかを確認するか、正規表現を使用します。ユーザー識別子の値が未定義である場合や他の無効な値である場合、それを使用して訪問ID属性を構成することは望ましくありません。そうすると、関連性のないプロファイルがスティッチングされる原因となります。
次の図は、正規表現を使用してメールアドレスを検証するSet Data Values拡張機能の構成の例を示しています：
この例では、次の正規表現を使用してメールアドレスを検証し、値を構成しています：
```none
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
```
### メールアドレスの正規化
異なるデータソースからの文字列属性（例：メールアドレス）は、異なる大文字小文字の規則を使用する場合があります。たとえば、一部は値に大文字を使用し、他はすべて小文字を使用する場合があります。これらの値を正規化する（すべて小文字に変更する）ことがベストプラクティスです。たとえば、[Lower-Casing extension]()を使用します。
たとえば、次のメールアドレスは、小文字に正規化されない限り、同じものとは見なされません：
* `abby.adams@acme.com`
* `Abby.Adams@acme.com`
* `ABBY.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 extension]()を参照してください。
#### 暗号拡張の例
次の例では、`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_hash` を `customer_email` の値に初期化し、その後で暗号拡張でハッシュ化します。これにより、新しいハッシュ値を作成した後も元の値を保持できます：
```
> 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属性の例を示しています：
## 追加のリソース
* [About visitor stitching]()
* [Visitor stitching guidelines]()
* [Visitor ID attribute]()