ベストプラクティスと制限事項

データの管理

連絡先とカスタムエンティティの同期の場合、この統合は 真実の源としてのMicrosoft Dynamics 365.  同期済み属性に対する変更は、Adobe Campaign Standardではなく、Dynamics 365 でおこなう必要があります。  Campaign で変更がおこなわれると、同期が一方向におこなわれるので、同期中に Campaign で上書きされる可能性があります。

統合は、オプションで、Dynamics 365 で連絡先が削除されたときに Campaign に対してプロファイル削除呼び出しを発行するように設定し、データの整合性を維持することができます。 ただし、プロファイルの削除は、プライバシーの削除とは異なります。 Campaign でプライバシーを削除すると、Campaign プロファイルレコードと関連するログエントリが削除されます。一方、通常のプロファイル削除では、キャンペーンプロファイルレコードのみが削除され、残りはキャンペーンログに残ります。 統合でプロファイル削除機能が有効になっている場合は、データ主体のプライバシーリクエストを適切に処理するために、追加の手順を実行する必要があります。 詳しくは、 以下のプライバシー節.

プライバシー

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

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

統合により、（オプトアウトを除き）他のプライバシーリクエストを削除または処理するデータ主体のプライバシー（GDPR など）は問題となりません。 プライバシーリクエストを処理する場合、(Adobe Experience Platform Privacy Service経由で )Microsoft Dynamics 365 と Campaign の両方で、独立して処理する必要があります。

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

1. プライバシー削除リクエストの発行先： Adobe Experience Platform Privacy Service

2. リクエストが正常に完了するまで、リクエストを監視します

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

4. （間もなく）Dynamics 365 内でプライバシーの削除を発行します

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

以下は、各システムでのアクセス要求やプライバシー関連の削除要求の実装に関するガイドへのリンクです。

• Microsoft Dynamics 365

• Adobe Campaign Standard

オプトアウト

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

オプトアウトマッピングでは、次の項目のみを使用できます。

• 「今後の連絡は不要」プレフィックスの付いたキャンペーン属性（例：今後の E メールによる連絡は不要）、または

• CCPA の特定の属性

プロファイルエンティティフィールドに関する詳細は、を参照してください ここ.

Dynamics 365 では、ほとんどのオプトアウトフィールドには「donot」プレフィックスが付きますが、データタイプに互換性がある場合は、他の属性をオプトアウト用に利用することもできます。

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

• 単方向 (Microsoft Dynamics 365 ～ Campaign):Dynamics 365 は、オプトアウトの情報源です。 オプトアウト属性は、Dynamics 365 からCampaign Standardへの一方向で同期されます
• 単方向 (Campaign からMicrosoft Dynamics 365):Campaign Standardは、オプトアウトの情報源です。 オプトアウト属性は、Campaign Standardから Dynamics 365 への一方向で同期されます
• 双方向:Dynamics 365 ANDCampaign Standardはどちらも真実の源です。 オプトアウト属性は、Dynamics と Dynamics 365 の間で双方向にCampaign Standardされます

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

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

でオプトイン/オプトアウトオプションを選択する方法を説明します。 この節.

選択した 双方向 または 単方向 (Campaign からMicrosoft Dynamics 365) オプトアウトの設定時に、Campaign のオプトアウトデータは、ワークフローを通じて定期的に Campaign の SFTP ストレージ領域にエクスポートされます（以下の「Campaign の SFTP 使用状況」を参照）。 Campaign のオプトアウトワークフローの実行が停止した場合は、できるだけ早く手動で再起動し、オプトアウト同期が失われる可能性を減らす必要があります。

キャンペーン SFTP の使用

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

データ管理

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

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

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

Microsoft Dynamics 365 は依然として真実のソースであり、統合が Dynamics 365 側での更新を検出すると、Campaign プロファイルデータが上書きされる場合があることに注意してください。 また、既存のデプロイメントに応じて、統合を有効にするために他の手順が必要になる場合があります。したがって、Adobeの技術担当者と緊密に連携することをお勧めします。

データ同期頻度

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

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

データ使用契約

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

ガードレールと制限

カスタムエンティティ

この Microsoft Dynamics 365 とAdobe Campaign Standardの統合 はカスタムエンティティをサポートし、Dynamics 365 のカスタムエンティティを Campaign の対応するカスタムリソースに同期できます。

この統合では、リンクされたテーブルとリンクされていないテーブルの両方をサポートしています。

カスタムエンティティのデータフローを設定する場合は、次の点に注意する必要があります。

• Campaign のカスタムリソースの作成と変更は機密性の高い操作で、エキスパートユーザーのみが実行する必要があります。

• カスタムエンティティのデータフローの場合、同期されたカスタムエンティティに対して、Dynamics 365 内で変更追跡を有効にする必要があります。

• Dynamics 365 で、親レコードとリンクされた子レコードがほぼ同じ時間で作成された場合、統合の並列処理により、親レコードの前に新しい子レコードが Campaign に書き込まれる可能性がわずかに高くなります。

• 親と子が 基数 1 のシンプルリンク 」オプションを選択した場合、親レコードが Campaign に届くまで、子レコードは非表示のままになり、（UI または API を介して）アクセスできなくなります。

• ( 仮定 基数 1 のシンプルリンク Campaign 内 ) Dynamics 365 で子レコードが更新または削除され、その変更が Campaign に表示される前に Campaign に書き込まれた場合（可能性は低いがリモートの場合）、その更新または削除は Campaign で処理されず、エラーがスローされます。 更新の場合、更新されたレコードを同期するには、問題のレコードを Dynamics 365 で再度更新する必要があります。 削除または更新するレコードが Dynamics 365 になくなったので、削除の場合は、問題のレコードを Campaign 側で個別に処理する必要があります。

• 非表示の子レコードがあり、それらにアクセスできないと思われる状況が発生した場合は、カーディナリティリンクの種類を一時的に 基数 0 または 1 のシンプルリンク をクリックして、これらのレコードにアクセスします。

Campaign のカスタムリソースの包括的な概要については、を参照してください。 この節.

統合ガードレール

この統合の使用を計画する際は、次のガードレールを考慮する必要があります。 これらのガードレールを超えていると思われる場合は、Adobeの技術担当者にお問い合わせください。

• 統合で生成されるエンジン呼び出し量をサポートするには、適切なキャンペーンパッケージのライセンスが必要です。 ライセンスされたエンジン呼び出しの量を超えると、Campaign のパフォーマンスが低下する可能性があります。

  統合からのエンジン呼び出しの量を見積もるのに役立つように、次の情報を使用します。

  • レコードの挿入（新しいレコード）:1 件のエンジン呼び出し
  • レコードの削除：1 件のエンジン呼び出し
  • レコードの更新：2 回のエンジン呼び出し（宛先レコードがソースレコードと同一の場合、つまりキャンペーンレコードに変更がない場合は 1 回のみ）

  Campaign エンジンの呼び出し量全体を見積もる場合、ランディングページ、Web アプリ、JSSP、API、モバイルアプリの登録など、他のエンジン呼び出し元を考慮に入れることが重要です。

  Adobe Campaign Standardパッケージの情報は、こちらから表示できます。 https://helpx.adobe.com/jp/legal/product-descriptions/campaign-standard.html

• この統合では、Campaign のリソースに対する初期同期で最大 1,500 万件の合計レコードをサポートしています。 増分同期は、Adobe Campaign Standardパッケージによって制限されます。

• 標準の統合機能には、最大 20 個のカスタムエンティティ（それぞれ最大 50 列）のサポートが含まれています。

• 統合を実装する前に、カスタムリソースを作成して公開する必要があります。

• テーブルをリンクする場合の最大テーブル深度は 2 です（例：table1->table2->table3）

• この統合では、カスタムリソースあたり最大 5 つのリンクされた列をサポートします。 カスタムリソース間で複数の列をリンクすると、パフォーマンスに大きな影響を与える可能性があります。 基数 0 または 1 のシンプルリンク より優先される 基数 1 のシンプルリンク.

• この統合では、プリミティブMicrosoft Dynamics 365 データ型 (Boolean、Integer、Decimal、Double、String、DateTime、Date) とAdobe Campaign Standardデータ型 (integer、boolean、float、double、date、datetime、string) の間の変換がサポートされています。 より高度なデータ型は文字列として解釈され、そのまま同期されます。

• オンボーディングのメンテナンスウィンドウは、お客様とAdobeの間で確立する必要がある場合があります。

• 統合の使用が大幅に増加または「スパイク」する（例：新しいレコードや更新されたレコードが急激に増加する）と、データ同期の速度が低下する可能性があることに注意してください。

• 統合の一環として、Microsoft Azure と Dynamics 365 の統合前の設定手順を完了する必要があります。 設定手順を参照してください。 このページの

• Dynamics 365 および Campaign のデータモデルを統合に取り込み、維持することが期待されます。

統合の境界

この統合は、Microsoft Dynamics 365 と Campaign の間で一般的なデータ移動の使用例を解決するように設計されていますが、各顧客に固有のすべての使用例に対処するためのものではありません。

• 統合は、プライバシー（GDPR など）の削除を問題にしません。 エンドユーザーのプライバシーリクエストを実行する責任は、お客様次第です。このようなリクエストは、(Adobe Experience Platform Privacy Service経由で )Campaign と Dynamics 365 で個別におこなう必要があります。 統合では、必要に応じて、データの同期に役立つ通常の削除を発行できます。 レビュー 「プライバシー」セクション を参照してください。

• オプトアウト情報（顧客が設定した場合）を除き、Campaign から Dynamics 365 にプロファイルまたはカスタムエンティティデータは同期されません。

• キャンペーン購読管理（購読/購読解除）はネイティブではサポートされていません。

• Dynamics 365 内からのキャンペーン電子メールキャンペーンの作成とトリガーはサポートされていません。

• 統合では、 not は、Dynamics 365 とCampaign Standardデータモデルの間のデータのリモデリングをサポートしています。 統合では、1 つの Dynamics 365 テーブルを 1 つの Campaign テーブルに同期することが予想されます。

Business.Adobe.com リソース