2024年3月22日

テクニカルTIPS マーケティング

Treasure Data CDP＜第14弾＞ID Unification 機能ご紹介

# Treasure Data

投稿者：D&A Homma

NI+C マーケソリューションチームです：）

本Tech Blogでは、NI+Cで取り扱っているTreasure Data CDPを紹介していきます。

本日はTreasure Data CDPの「ID Unification」の機能についてご紹介いたします！

ID Unificationとは

「ID Unification」機能は、顧客データの統合を簡単に可能にする機能です。

データがさまざまなチャネルやデバイス、プラットフォームから得られる場合、同一の顧客が異なるIDで表されることがあります。例えば、ウェブでの購入とモバイルアプリでの購入が異なるIDとして記録されるなど、同一人物のデータにも関わらず、IDがバラバラになってしまっているということがあります。そのため顧客の全体像を把握するのが難しいという問題が発生します。

「ID Unification」機能は、異なるデータソースから得られる顧客データを統合します。つまり、顧客の全行動を一元化して把握できるようになり、よりパーソナライズされたマーケティング活動や顧客エクスペリエンスの提供が可能となります。

ID Unification について

Treasure Dataでは、全ユーザーが利用できる標準機能として、「ID Unification」を実行するWorkflow_(※1)を提供しています。Workflowの中で記述する必要があるものは主に以下の２ファイルです。

1.　ID Unification WF を呼び出す dig ファイル

2.　ID Unification を行うデータソースや、縫い合わせキーを定義する yml ファイル

1.　Unification WFを呼び出す dig ファイル（sample）

+call_id_unification:
  http_call>: https://api-cdp.treasuredata.com/unifications/workflow_call
  headers:
    - authorization: ${secret:td.apikey}
  method: POST
  retry: true
  content_format: json
  content:
    early_access: true
    run_canonical_ids: true
    run_enrichments: true
    run_master_tables: true

    full_refresh: true
    keep_debug_tables: true

    unification:
      !include : id_unification_ex1.yml

http_call>:

Unification WF を呼び出して実行します。
ワークフローAPIは地域によって異なるため、お使いのアカウントがどの地域なのか確認して任意の設定をします。

US region（https://api-cdp.treasuredata.com/unifications/workflow_call）
EU01 region（https://api-cdp.eu01.treasuredata.com/unifications/workflow_call）
Tokyo region（https://api-cdp.treasuredata.co.jp/unifications/workflow_call）
Korea（https://api-cdp.ap02.treasuredata.com/unifications/workflow_call）

headers:

アカウントの Master API Key をシークレットに設定しておく必要があります。
設定した API Key をここで指定しています。

content:

ID Unification WF の設定が記載されている yml ファイルを指定します。オプションが複数あるので要件に応じて設定します。下記に代表的なオプションを挙げました。

run_canonical_ids:
デフォルト：true
このオプションを false にすると、canonical_id の生成プロセスを実行しません。

run_enrichments:
デフォルト：true
このオプションを false にすると、canonical_id をソーステーブルに付与するプロセスを実行しません。

run_master_tables:
デフォルト：true
このオプションを false にすると、master_table の生成プロセスを実行しません。

_(※1)Workflow について

こちらの記事を参考にしてください↓↓

Treasure Data CDP＜第6弾＞Treasure Workflow とは（前編）
Treasure Data CDP＜第7弾＞Treasure Workflow とは（後編）

2.　ID Unification を行うデータソースや、縫い合わせキーを定義する yml ファイル（sample）

name: ex1
keys:
  - name: td_client_id
    valid_regexp: "[0-9a-fA-F]{8}-..."
    invalid_texts: ['']

  - name: td_global_id
    valid_regexp: "[0-9a-fA-F]{8}-..."
    invalid_texts: ['']

  - name: mail_address
    valid_regexp: ".*@.*"

tables:
  - database: id_unification
    table: pageviews
    key_columns:
      - {column: td_client_id, key: td_client_id}

  - database: id_unification
    table: app_pageviews
    key_columns:
      - {column: td_client_id, key: td_client_id}
      - {column: td_global_id, key: td_global_id}
      - {column: mail_address, key: mail_address}

  - database: id_unification
    table: contacts
    key_columns:
      - {column: mail_address, key: mail_address}

canonical_ids:
  - name: browser_id
    merge_by_keys: [td_client_id, td_global_id]

master_tables:
  - name: master_table_ex1
    canonical_id: browser_id

    attributes:
      - name: browser_id
        source_canonical_id: browser_id

      - name: mail_address
        source_columns:
          - {table: contacts, column: mail_address}

name:

Unificationの名前になります。この名前はID Unificationで出力されるデータベース名に含まれます。
※データベース名は cdp_unification_${name} となります。

keys:

IDを統合するために利用する識別子を「key」として全て列挙します。

tables:

IDを統合するために利用する「テーブル」を全て列挙し、テーブル間の関係を記述します。記述が必須なものを今回は列挙しています。

【必須】

database:	テーブルが含まれるデータベース
table:	テーブル
key_columns:	テーブルのカラムと統一するためのキーのマッピング
column:	テーブルのカラム名
key:	このカラムが対応するkeysセクションのキー

canonical_ids:

ID Unification を実行するための設定と、実行後、統一されたユーザーに新たに識別子を割り当てる設定を行います。

出力されるデータについて

ID Unification を実行すると、 cdp_unification_${name} という名前でデータベースが作成されます。例えば、先ほどの yml では、 name: ex1 と指定したので、 cdp_unification_ex1 という名前でデーターベースが作成され、その中に ID Unificationが行われたデータが出力され、テーブルへ格納されます。

Output テーブル一覧

enriched_${source_table Name}

${source_table Name}：tables: の table: で指定したテーブル名が入る

上書き

yml の tables: で列挙したテーブルに canonical_id を付与したテーブル。このテーブルは attribute_table / behavior_table として、同時に出力される master_table と canonical_id で結合できるようになる。

master_table

master_tables: の name: で指定したマスターテーブル名が入る

上書き

一意に識別できる canonical_id をレコードにもつ master_table。加えて attributes: に指定したカラムが付与されている。

そのほかにも、分析で利用可能なテーブルがオプションに沿って出力されます。

詳細はTreasura Data社が公開している公式ドキュメントも合わせてご確認ください。

サンプルデータで実際の動きを確認してみましょう！

データセット

複数サイトのログです。各サイトのログは、各テーブルに格納されています。

このデータは、複数ユーザーが存在しているように見えますが、サイトを横断してtd_client_id、td_global_idでつなぎ合わせると1人に特定できます。

こちらのデータをサンプルとして、WFを実行し、動きを確認してみます。

結果

処理の結果は、作成されたデータベースのテーブルを確認します。

ymlファイルの中で、master_tables: の name: にて指定した名前でテーブルが作成されています。

レコードは、canonical_id ごとに生成されます。今回のサンプルデータでは、1人に特定されるため結果は1レコードとなりました。

注意すべきポイント

電話番号や住所などの表記揺れの統一機能はありません

電話番号や住所などの識別子の表記揺れを、自動で整合し統合するといった機能はありません。以下がポイントになります。

- ID Unification のWF処理は、識別子の完全一致で縫い合わせを行います。
- 電話番号、住所、氏名などの表記揺れがある識別子を縫い合わせキーとして使いたい場合は、あらかじめデータの表記を統一する必要があります。（ただしユニークとなっていること）

氏名や IP アドレスを縫い合わせを行うキーに使用することはできません

縫い合わせキーとして使用する識別子は、必ず個人に対してユニークである必要があります。例えば、同姓同名の人がいた場合、「氏名」は個人に対してユニークな値とならないため使用できません。その他にもキーに使用することができない項目は以下のようなものがあります。

- 氏名
- 共有メールアドレス、メーリングリスト
- IPアドレス
- 自宅の電話など多数が使う電話番号

キーの値が似たものを「類推」することはできません

ID Unification のWF処理ではデータが似ているキーの値を同じものの見なしたり、行動パターンが同じものを「推測」して縫い合わせを行うといった機能はありません。表記揺れの場合と同様に、データをそろえる必要があります。

canonical_id は処理後変わることはない

一度、ID Unification のWF処理によって決まった canonical_id は次回更新以降、値が変わる可能性があります。

- ID Unification のWF処理を更新した際に、前回処理で決まった値よりも小さい値が現れれば、値が置き換えられることになり、canonical_id も変わることになります。
- できるだけ canonical_id が変わらないように、個人に対して不変となるキーを merge_by_keys: の一番最初に設定します。

【例1】

このユーザーは、前回処理で決まった値 xxx_01 より小さい値の xxx_00 の td_client_id がデータに入ってきたため、処理によって決められる最小値は前回と異なり xxx_00 になり、これによって生成される canonical_id も異なってしまいます。

前回と今回の処理の後では、ユーザーが同一にも関わらず、別の人という認識とされてしまいます。この事象を回避するためには、可能な限り個人に対して不変となる key を設定する必要があります。

以上がID Unification機能のご紹介でした。

Treasure Data CDPの「ID Unification」機能は、顧客データを深く理解し、それに基づいた効率的なマーケティングを行うための強力なツールです。この機能を適切に活用することで、企業は統一された顧客ビューを作成し、よりパーソナライズされたエクスペリエンスを提供することが可能となります。

ご興味を持たれた方は「こちら」からお問い合わせください。

Treasure Data CDP についてのそのほかの記事はこちら▼

セグメント作成について
Treasure Data CDP ＜第1弾＞Audience Studio の機能でセグメント作成してみた！！

Activationについて
Treasure Data CDP ＜第2弾＞Audience Studio の機能 Activation を使ってみた！

Predictive Scoring について
Treasure Data CDP ＜第3弾＞Predictive Scoring のご紹介

データのインポートについて
Treasure Data CDP ＜第4弾＞Treasure Data にデータをインポートしてみた

SQLを使ったデータの抽出方法について
Treasure Data CDP＜第5弾＞SQL を使ってデータ抽出してみた！

Treasure Workflowについて（前編）
Treasure Data CDP＜第6弾＞Treasure Workflow とは（前編）

Treasure Workflowについて（後編）
Treasure Data CDP＜第7弾＞Treasure Workflow とは（後編）

オーディエンススタジオジャーニーオーケストレーションについて
Treasure Data CDP＜第8弾＞新機能ジャーニーオーケストレーションご紹介

Server Side 1st Party Cookieについて
Treasure Data CDP＜第9弾＞Server Side 1st Party Cookieのご紹介

ジャーニーオーケストレーションの機能を使ったジャーニーの作成方法について
Treasure Data CDP＜第10弾＞【Journey Ohchestration】ジャーニーを作成してみよう！