よくある誤解#

誤解1. 電話番号や住所などの表記揺れを統一してくれると思っている#

こちらの誤解は主に日本語の値を持つデータに起因する者である。 いわゆる「名寄せ」という言葉のイメージで捉えてしまうと、識別子の中で表記の揺らぎがある電話番号や住所などを、自動的に統一して統合してくれるものと勘違いしてしまう。ID Unification の以下の点をよく理解しておくこと。

  • ID Unification ツールは、識別子の完全一致による縫い合わせを行うもので、識別子の表記揺れの補正を事前に行わない。

  • テーブル間で表記揺れのある識別子 (電話番号、住所、氏名など) を縫い合わせキーとして使いたい場合は、事前に表記揺れを別の手段で統一しておく必要がある。

誤解2. 氏名や IP アドレスを縫い合わせキーに使えると思っている#

縫い合わせ key として使用する識別子は、必ず個人に対してユニークでなければならない。

key として使用できないもの#

  • ❌ 氏名

    • 同姓同名である場合である別人が、同一人物として統合されてしまう。

  • ❌ IP アドレス

    • 値の再利用が行われるので、複数の別人が同一視されてしまう。

  • ❌ 共有メールアドレス、メーリングリスト

  • ❌ 自宅電話番号

key として使用できるもの#

  • ⭕️ td_client_id, td_global_id, td_ssc_id

  • ⭕️ member_id, customer_id

    • システム側がユニークに生成してくれる ID

  • ⭕️ email

  • ⭕️ 携帯電話番号 (個人に紐づく電話)

誤解3. key の値が似たものを「類推」して紐づけてくれる#

ID Unification では似た key の値のものを同一視してくれたり、行動パターンが同じものを類推して縫い合わせてくれる機能はないことに注意しよう。

誤解4. canonical_id は不変だと思っている#

一度割り振られた canonical_id は、以降の更新によって値が変わる可能性がある。

  • Unification WF を更新した際に、前回の最終 graph における leader の値よりも小さい値が現れれば、 leader が置き換えられることになり、canonical_id が変わることになる。

  • できるだけ canonical_id が変わらないように、個人に不変な key を merge_by_keys: の先頭に設定する。

_images/9-1-1.png

Fig. 55 canonical_id が変わってしまうケース#

User1 は前回の最終グラフの leader の値 aaa_01 より小さい値の aaa_00 の td_client_id が登場したため、アルゴリズムが決める最終 leader は前回と異なり aaa_00 になり、これに基づいて生成される canonical_id も異なることに。これはオーディエンススタジオ上で、User1の cdp_customer_id が変わってしまうことを意味する。