データテーブルのレコードをユーザーに紐付ける

データテーブル上の値は、

データテーブル上の特定のメインキーをもつレコード(データテーブル上の一行) 

同一のメインキーをユーザー属性として保持しているユーザー

に紐つけることが可能です。

 

データテーブル上のレコードはユニークなメインキーを持つ必要がありますが、1つのレコードを複数のユーザーに紐つけるということも可能です。


紐付けの例

例1: ユーザー属性のメールアドレスに対して、別システム(外部CRM, 自社DB等)上のメールアドレスに紐付いた対応ステータスを紐つける

例2: ユーザー属性の企業名に対して、企業名に紐ついた企業情報を紐つける(同じ企業名を持つユーザーには、データテーブル上の同じ企業名のレコードが紐付きます)

例3: ユーザーIDに対して、リアル店舗での購買回数や購買金額を紐つける

 

 

紐付けの設定方法

データテーブルとユーザー属性を紐付ける場合、作成したデータテーブルの設定タブからユーザーとの紐付け欄からイベント名メインキー結合フィールドの設定が必要です。

__________2017-08-08_16.25.17.png

 

イベント名の設定 

紐付けられたレコードが、ユーザー属性として何というイベント名で扱われるかを設定します。

ユーザータグで送信された属性の場合はidentifyというイベント名を指定することで、他のユーザータグで送信された属性と同様に、データテーブルから紐付けられた属性を取り扱うことが可能です。

identify以外のイベント名を指定した場合、カスタムイベントで送信された属性という形式で取り扱われます。

 

 

メインキー結合フィールドの設定

データテーブル上の各行のメインキーをユーザーに紐つける際に、ユーザー属性のどの値(フィールド)と紐つけるかを決定します。

ユーザータグ(identifyイベント)で送信されたemailに紐付ける場合は identify.email 
my_eventというイベントのfield1と紐付ける場合は my_event.field1 
といった形式で、イベント名とフィールド名をドット(.)区切りで入力して下さい。

※フィールドが入れ子構造の場合は、ドット区切りで入れ子のフィールドを指定してください

 

 

紐付けの具体例

例として下記のemailをメインキーにしたデータテーブルを
my_eventで送信されたemailというパラメータに紐つけ、紐付けられた属性をfrom_collectionというイベント名で識別したい場合、

__________2017-08-08_16.36.07.png

紐付けは下記のような設定となります。

  • イベント名: from_collection
  • メインキー結合フィールド: my_event.email

__________2017-08-08_16.31.09.png

紐付けが有効であれば、セグメント設定ページ等ではイベント名で設定したfrom_collectionというイベント名でデータテーブル上のパラメータを指定できます。

__________2017-08-08_16.35.05.png

※紐付けで設定したイベント名が既存イベント名と重複している場合、email等の紐付けられたパラメータが既存の送信パラメータに追加され(画像右側の選択肢)、既存イベント名と重複していない場合は指定したイベント名自体が選択できるようになります(画像中央の選択肢)

 

紐付けを有効化した後、my_eventというイベントのemailパラメータで "taro.karte@example.com" という値が送信されているユーザーがなんらかの行動をした時点で、データテーブル上の"taro.karte@example.com"をメインキーに持つ行が該当ユーザーに紐付けられます。

 

ユーザー紐付けの挙動

通常のイベントと紐付けられた属性の違い

通常のユーザー属性はイベントの形式でユーザー属性として認識されていますが、データテーブルから紐付けられた値はイベントの形式では紐付けられません。
そのためidentifyというイベント名で属性が紐付けられた際に、identifyというイベントは発生しません。

ただし、ユーザーの属性としてはidentify下に各種属性が紐付けられている状態となります。

 

結合フィールド

セグメント設定時等では送信されたパラメータの最初の値上位30件といった値を利用可能ですが、紐付け時に利用される値は最新の値となります。

ユーザータグで送信されたメールアドレス(email)と紐付けを行った場合、ユーザーがメールアドレスを変更してユーザー属性上のメールアドレスも変更された場合は紐付けが外れる挙動となります。

 

紐付けられた属性の扱い

データテーブルから紐付けられた値は、各ユーザー属性パラメータの最新の値として認識されます。
挙動としては最新の値がデータテーブル上の値で上書きされる挙動となります。

__________2017-08-30_14.03.52.png

この挙動による注意点として、通常のタグから送信される属性と同じパラメータがデータテーブルから紐付けられた場合、タグから送信される値が更新されたとしても、ユーザー属性はデータテーブル上の値で上書きされた状態になります。
既存のタグで送信している属性と同一のパラメータをデータテーブルから紐付ける場合は十分に注意してください。

例: ユーザー属性としてポイントを送信している状態で、データテーブルからポイントの値をユーザーに紐つけた場合

ユーザータグ経由でポイントの増減が送信された場合でも、データテーブル上のポイントの値でユーザーのポイントの最新の値が更新されます。そのためタグ経由で送信されるポイントの増減は識別されなくなります。

 

紐付けの制約と履歴データの取り扱い

データテーブルのメインキーのユニーク制約と、各ユーザー属性の最新の値と各レコードが紐付けられるという仕様から、1ユーザーの同一フィールドに複数のレコードを紐つけるといった利用はできません。

例: コンバージョンタグで送信された受注IDと、データテーブル上の受注IDをメインキーとした受注マスタを紐つけた場合

⇒データテーブル上に受注IDをメインキーとして、全ての受注情報が存在していた場合でも、ユーザーに紐付けられるレコードは各ユーザーのコンバージョンタグで送信された受注IDの最新の値と紐付けられるため、このような紐付けを行った場合は1ユーザーに1受注のレコードのみ紐付けられます。