バッチ宛先マッピング参照

この記事では、バッチプロファイルの書き出し先🔗に対してオーディエンスを アクティブ化する際の​ マッピング ​手順の必須の属性、重複排除キー、計算フィールド、および既知の制限について説明します。

必須の属性 mandatory-attributes

必須属性は、選択した属性がすべてのプロファイルレコードに含まれるようにする、ユーザーが有効にしたチェックボックスです。 例：書き出されたすべてのプロファイルに電子メールアドレスが含まれています。

Experience Platform が特定の属性を含むプロファイルのみを書き出すよう、属性を必須としてマークすることができます。 その結果、追加のフィルタリング形式として使用できます。 属性を必須としてマークする必要は​ありません。

必須属性を選択しない場合、属性に関係なく、すべての対象プロファイルを書き出します。

属性の 1 つをスキーマの一意の ID にすることをお勧めします。 必須属性について詳しくは、メールマーケティングの宛先ドキュメントの ID の節を参照してください。

重複排除キー deduplication-keys

重複排除キーは、プロファイルの重複排除の方法を決定するユーザー定義のプライマリキーです。 同じ個人に複数のレコードが存在する場合、重複排除によって最新のレコードのみが書き出されます。

重複排除キーを使用すると、同一プロファイルの複数のレコードが 1 つの書き出しファイルに含まれる可能性がなくなります。

Experience Platform で重複排除キーを使用する方法は 3 つあります。

重複排除の例 deduplication-example

次の例は、選択した重複排除キーに応じた重複排除の仕組みを示しています。

次の 2 つのプロファイルについて考えてみましょう。

プロファイル A

{
  "identityMap": {
    "Email": [
      {
        "id": "johndoe@example.com"
      },
      {
        "id": "doejohn_1@example.com"
      }
    ]
  },
  "segmentMembership": {
    "ups": {
      "fa5c4622-6847-4199-8dd4-8b7c7c7ed1d6": {
        "status": "realized",
        "lastQualificationTime": "2021-03-10 10:03:08"
      }
    }
  },
  "person": {
    "name": {
      "lastName": "Doe",
      "firstName": "John"
    }
  },
  "personalEmail": {
    "address": "johndoe@example.com"
  }
}

プロファイル B

{
  "identityMap": {
    "Email": [
      {
        "id": "johndoe@example.com"
      },
      {
        "id": "doejohn_2@example.com"
      }
    ]
  },
  "segmentMembership": {
    "ups": {
      "fa5c4622-6847-4199-8dd4-8b7c7c7ed1d6": {
        "status": "realized",
        "lastQualificationTime": "2021-04-10 11:33:28"
      }
    }
  },
  "person": {
    "name": {
      "lastName": "D",
      "firstName": "John"
    }
  },
  "personalEmail": {
    "address": "johndoe@example.com"
  }
}

重複排除の使用例 1：重複排除なし deduplication-use-case-1

重複排除を使用しない場合、書き出しファイルには次のエントリが含まれます。

重複排除の使用例 2：ID 名前空間に基づく重複排除 deduplication-use-case-2

Email 名前空間の重複排除を指定した場合、書き出しファイルには次のエントリが含まれます。 プロファイル Bは、オーディエンスに適格な最新のプロファイルなので、書き出されるのはプロファイル Bのみです。

重複排除のユースケース 3：単一のプロファイル属性に基づく重複排除 deduplication-use-case-3

personal Email 属性による重複排除を仮定した場合、エクスポートファイルには次のエントリが含まれます。 プロファイル Bは、オーディエンスに適格な最新のプロファイルなので、書き出されるのはプロファイル Bのみです。

重複排除のユースケース 4：2 つのプロファイル属性に基づく重複排除 deduplication-use-case-4

複合キー personalEmail + lastName による重複排除を仮定した場合、エクスポートファイルには次のエントリが含まれます。

CRM ID やメールアドレスなどの ID 名前空間を重複排除キーとして選択して、すべてのプロファイルレコードが必ず一意に識別されるようにすることをお勧めします。

同じタイムスタンプを持つプロファイルの重複排除の動作 deduplication-same-timestamp

プロファイルをファイルベースの宛先に書き出す場合、重複排除によって、複数のプロファイルが同じ重複排除キーと同じ参照タイムスタンプを共有する場合に、1つのプロファイルのみが書き出されます。 このタイムスタンプは、プロファイルのオーディエンスメンバーシップまたはID グラフが最後に更新された時点を表します。 プロファイルの更新およびエクスポート方法について詳しくは、​ プロファイルのエクスポート動作 ドキュメントを参照してください。

重要な考慮事項 key-considerations

重複排除キーがEmail列である次のデータを考えてみましょう。

重複排除の後、エクスポートファイルには次のものが含まれます。

説明: test1@test.comでは、両方のプロファイルが同じ重複排除キーとタイムスタンプを共有しています。 アルゴリズムは、first_nameとlast_name列の値を辞書的に並べ替えます。 名前は同じなので、タイはlast_name列を使用して解決されます。この列の前には「Doe」が表示されます。

信頼性の向上：この更新された重複排除プロセスにより、同じ座標を持つ連続した実行が常に同じ結果を生成し、一貫性が向上します。

計算フィールドを使用してデータ変換を実行する calculated-fields

計算フィールド ​ コントロールを使用して、ファイルベースの宛先に書き出されたデータに対して様々なデータ変換を実行できます。

既知の制限事項 known-limitations

新しい​マッピング ページには、次の既知の制限があります。

マッピングワークフローでオーディエンスメンバーシップ属性を選択できません audience-membership-attribute-mapping

既知の制限により、現在、フィールドを選択 ウィンドウを使用してsegmentMembership.seg_namespace.seg_id.statusをファイル書き出しに追加することはできません。 代わりに、手動で値 xdm: segmentMembership.seg_namespace.seg_id.status をスキーマフィールドに貼り付ける必要があります（下図を参照）。

{modal="regular"}

ファイルのエクスポートは、segmentMembership.seg_namespace.seg_id.status が選択されているかどうかによって、次のように異なります。

ファイルベースの宛先に対する​ プロファイル書き出し動作の詳細をご確認ください。

ID 名前空間は現在、書き出し用に選択できません identity-namespaces-export-limitation

以下の画像に示すように、ID 名前空間を書き出し用に選択する機能は、現在サポートされていません。 書き出し用にID名前空間を選択すると、レビュー​手順でエラーが発生します。

{modal="regular"}

ベータ版の間に書き出したファイルに ID 名前空間を追加する必要がある場合の一時的な回避策として、次のいずれかを実行できます。