Data 360：ID 解決（Identity Resolution）のクレジット消費の計算ルールと最適化のベストプラクティス

• ルールセットの変更頻度を抑える: ルールセットを更新すると全件再処理が走るため、変更は計画的に最小限に留めてください。
• マッピング項目の厳選: DLOからDMOへのマッピングは、ID解決やセグメンテーションなど業務に必要な項目のみに限定してください。
• 不要な ID 解決設定の無効化: 使用していないルールセットは、速やかに無効化または削除してください。
• データソースの更新タイミングの同期: 複数のDLOから一つのDMOへマッピングしている場合、できる限り更新タイミングを揃えることで、ID解決が不必要に何度もトリガーされることを防げます。

• 原因: Individual DMO に Last Modified Date（最終更新日） をマッピングしていたこと。
   ※ Last Modified Date は更新頻度の高い項目であるため、CRM 側のほぼすべてのデータ更新が反映されます。
• 発生メカニズム:
  1. CRM 側での全件バックアップやシステムバッチにより、レコードの Last Modified Date が一斉更新される。
  2. Data 360 はマッピングされた項目の変化を検知し、「全レコードに変更あり」と判定する。
  3. ID 解決の実行時、 Last Modified Date 以外のデータ内容に変更がなくても、すべてのレコードが「再処理対象」としてカウントされ、クレジットを大量に消費する。

CRM コネクタ利用時の注意事項と対策

DLOからDMOへのデータマッピングに、更新頻度が高くなりやすいCRM側のタイムスタンプ項目などを含める際は特に注意が必要です。

• リスク: DLOからDMOへのマッピングにおいて、「SystemModStamp」を含めるとCRM側の全更新が、「Last Modified Date」を含めるとほぼすべての更新が反映されます。その結果、これらがID解決の処理対象となり、クレジット消費が増える原因となります。
• 注意事項：CRM コネクタで標準データバンドルを使用した場合、対象の DLO の Last Modified Date が ID 解決関連 DMO の Last Modified Date にデフォルトでマッピングされます。
• 対策: ID解決に不要な項目は、手動でマッピングを解除することを推奨します。