キャンペーンとMicrosoft Dynamics 365間のデータの管理

一方向の同期の真の原因

連絡先エンティティとカスタムエンティティの同期の場合、この統合はDynamics 365を真の原因として扱います。  同期された属性に対する変更は、キャンペーンではなくDynamics 365で行う必要があります。  キャンペーンで変更が行われると、同期中にキャンペーン上で上書きされる可能性があります。これは、同期が一方向に行われるためです。

連絡先の削除

必要に応じて、Dynamics 365で連絡先が削除された場合に、プロファイルの削除呼び出しをキャンペーンに発行するように統合を設定できます。これにより、データの整合性を維持できます。

ただし、プロファイルの削除は、プライバシーの削除とは異なります。 キャンペーン内のプライバシー削除により、キャンペーンプロファイルレコードと関連するログエントリが削除されます。一方、正規プロファイルの削除では、ACSプロファイルレコードのみが削除され、残りはキャンペーンログに残ります。

統合でプロファイルの削除機能が有効になっている場合は、データの件名のプライバシー要求を適切に処理するために、追加の手順を実行する必要があります。 ](#manage-privacy-requests)の下の[セクションの手順を参照してください。

プライバシー

プライバシー要求の管理

この統合は、エンドユーザーデータ(エンドユーザーデータに個人情報が含まれる場合は、その個人情報を含む)をMicrosoft Dynamics 365とAdobe Campaign Standard間で転送するように設計されています。 お客様の会社は、データ管理者として、個人データの収集と使用に適用されるプライバシーに関する法令に準拠する責任を負います。

統合では、データ・サブジェクト・プライバシー(GDPRなど)の削除や他のプライバシー要求(オプトアウトを除く)の処理は一切行われません。 プライバシー要求を処理する場合は、Dynamics 365とキャンペーン(Adobe Experience Platform Privacy Service経由)の両方で、個別に処理する必要があります。

Dynamics 365で連絡先が削除された場合に、キャンペーンに対して定期的なプロファイル削除呼び出しを発行するように統合を設定した場合は、次の手順に従う必要があります。 この処理中に、対象のレコードに対して更新が行われていないことを確認します。

  1. Adobe Experience Platform Privacy Serviceにプライバシー削除要求を発行

  2. 要求が正常に完了するまで監視する

  3. レコードがキャンペーンインスタンスに存在しないことを確認します

  4. (その後すぐ)Dynamics 365内でプライバシーの削除を発行します

  5. レコードが両方のシステムから削除されたことを確認します

次のリンクは、各システムにアクセス権を実装したり、プライバシー関連のリクエストを削除したりする際の参考になります。

プライバシーとリンクされたリソース

キャンペーンのカスタムリソースレコードに、キャンペーンの使用に応じた個人情報が含まれる場合は、そのレコードを対応するキャンペーンプロファイルレコード(直接または他のカスタムリソースを介して)にリンクし、プロファイルレコードのプライバシー関連の削除で個人情報を含むリンクカスタムリソースレコードも削除できます。エンティティ間のリンクおよび削除のオプションは、リンクされたレコードをカスケード形式で削除できるように設定する必要があります。 個人情報は、プロファイルにリンクされていないカスタムリソースに入力しないでください。

この節](…/…/integrating/using/map-campaign-custom-resources-and-dynamics-365-custom-entities.md)では、キャンペーンリソースとDynamics 365エンティティ[をマッピングする方法を説明します。

オプトアウト

Dynamics 365とキャンペーンのオプトアウト属性の違いと、各顧客のビジネス要件の違いにより、オプトアウトマッピングは、顧客が完了するための演習として残されています。  エンドユーザーのオプトアウト設定が維持され、オプトアウトしたチャネルを介した通信を受け取らないように、オプトアウトがシステム間で適切にマッピングされるようにすることが重要です。

オプトアウトマッピングでは、プレフィックスが「連絡を取らない」のキャンペーン属性(電子メールによる連絡を取らないなど)またはCCPAオプトアウトの特定の属性のみが使用できることに注意してください。 詳細情報。Dynamics 365では、ほとんどのオプトアウトフィールドには「ドノット」プレフィックスが付きます。ただし、データタイプに互換性がある場合は、他の属性をオプトアウト目的に使用することもできます。

統合をプロビジョニングする際、ビジネスに必要なオプトアウト設定を指定できます。

  • Dynamics 365はオプトアウトの真実の原因です:オプトアウト属性は、Dynamics 365からキャンペーンに1方向で同期されます
  • キャンペーンはオプトアウトの真の原因です。オプトアウト属性は、キャンペーンからDynamics 365への一方向で同期されます
  • Dynamics 365 ANDキャンペーンはどちらも真実の源です。オプトアウト属性は、キャンペーンとDynamics 365の間で双方向に同期されます。

また、システム間のオプトアウト同期を別のプロセスで管理する場合は、統合のオプトアウトデータフローを無効にできます。

双方向オプトアウト設定では、ロジックを使用して、両方のシステムに書き込む値が決定されます。 このロジックは、2つのシステム間のタイムスタンプ(Dynamics 365でのレコードレベルの変更、キャンペーンの属性レベルの変更)を比較して、どのシステムが使用されるかを判断します。 キャンペーンに、より新しいタイムスタンプが含まれている場合は、キャンペーン値が使用されます。 Dynamics 365により新しいタイムスタンプが含まれている場合、または同じ場合は、opt-out=TRUEが勝ちます(値の1つがTRUEの場合)。

メモ

必要に応じて、Adobe Campaignのデフォルトおよび特定のタイポロジルールを確認し、変更を行う前に、デフォルトおよび特定の通信を更新して、すべての送信通信にその変更が正しく適用されることを確認してください。 例えば、オプトアウトの環境設定へのマッピングには、受信者の意図/コミュニケーションの選択が正確に反映され、顧客注文の確認など、関係の配信やトランザクションメッセージのが意図せずやめないようにしてください。

双方向またはDynamics 365オプトアウト構成へのキャンペーンを選択した場合、キャンペーンオプトアウトデータは、ワークフローを介してキャンペーンのSFTPストレージ領域に定期的にエクスポートされます(後述の「キャンペーンのSFTPの使用」を参照)。 キャンペーンのオプトアウトワークフローの実行が停止するイベントでは、オプトアウトの同期が失敗する可能性を減らすために、できる限り早く手動で再起動する必要があります。

キャンペーンSFTPの使用

キャンペーンのSFTPストレージは、次の使用例で統合が利用する必要があります。 これらの使用例に対応するために、SFTPアカウントに十分なストレージ容量があることを確認する必要があります。 SFTPのストレージ容量がライセンスを超えると、キャンペーン、統合、および/またはSFTPアカウントの機能的使用が著しく損なわれる場合があります。

使用例 説明
初期データ読み込み 500kレコードを超えるDynamics 365テーブルは、ワークフローを介してインポートするには、キャンペーンSFTPストレージにエクスポートする必要があります。 それ以降、統合は増分更新にAPIを使用します。
Dynamics 365の単方向オプトアウトに対する双方向のオプトアウトとキャンペーン 双方向のオプトアウトおよびDynamics 365の単方向のオプトアウトデータフローへのキャンペーンでは、キャンペーンのSFTPストレージを利用します。 ACSワークフローは、増分変更をSFTPフォルダにエクスポートします。 このページから、統合がレコードとプロセスを取得します。
災害復旧 システム障害が発生したイベントが万一発生した場合は、「初回データ読み込み」の使用例に従って、失敗したキャンペーンに増分更新を送ります。

既存のキャンペーンデータ

この統合は、Dynamics 365の連絡先とカスタムエンティティをキャンペーンに同期します。 統合の外部で作成されたキャンペーンレコード(同期ジョブで作成されたものではない)は、統合によって変更されません。統合設定時に存在するキャンペーンレコードも含まれます。

この統合では、キャンペーンの​externalId​フィールドを使用してキャンペーンプロファイルレコードをDynamics 365の連絡先レコードと同期するので、Dynamics 365から同期するレコードには、このキャンペーンフィールド(externalId)にDynamics 365 contactId​を入力する必要があります。 また、カスタムエンティティもDynamics 365の一意のIDを使用して同期されます。 キャンペーンのカスタムエンティティでは、このID属性をテーブル列として含める必要があります。 externalId列は、この属性値の格納に使用できますが、キャンペーンのカスタムエンティティには必要ありません。

ただし、Dynamics 365は真実の原因であり、Dynamics 365側の更新をキャンペーンが検出した場合は、統合プロファイルデータを上書きできます。 既存のデプロイメントに応じて、統合を有効にするために必要なその他の手順もあります。したがって、Adobeのテクニカルコンタクトと緊密に連絡を取ることをお勧めします。

メモ

既存のお客様のデプロイメントは複雑なので、統合の計画と設定を行う際は、Adobeのテクニカルコンタクトにご相談することをお勧めします。

データ同期の頻度

統合は、Dynamics 365で更新が発生した直後に、更新を検出し、処理「キュー」に追加できるアーキテクチャを利用します(バッチ処理ではなくストリーミング)。 このため、データ・フローの実行頻度またはスケジュールを指定する必要はありません。

ただし、Dynamics 365オプトアウトデータフローに対する双方向およびキャンペーンは例外です。 これらのオプトアウト設定では、更新されたACSレコードはACSワークフローを介して1日に1回SFTPにエクスポートされ、その後、統合ツールがファイルを読み取り、レコードを処理します。

データ使用規約

EMEAまたはAPAC地域にお住まいの場合、一部のデータは、この統合の一環として米国で処理されます。 詳しくは、この節を参照してください。

このページ