ドキュメント Campaign Campaign Standard ドキュメント

ベストプラクティスと制限事項 acs-msdyn-best-practices

Last update: Fri Jul 19 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

トピック：

作成対象：

経験者
開発者

データの管理 acs-msdyn-manage-data

連絡先とカスタムエンティティの同期の場合、この統合は Microsoft Dynamics 365 を情報源として扱います。  同期された属性に対する変更は、Adobe Campaign Standardではなく Dynamics 365 で行う必要があります）。  Campaign で変更を加えると、同期が一方向にあるので、最終的には同期中に Campaign で変更が上書きされる可能性があります。

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

プライバシー acs-msdyn-manage-privacy

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

この統合は、Microsoft Dynamics 365 とAdobe Campaign Standardの間で、エンドユーザーのデータ（エンドユーザーのデータに個人情報が含まれている場合、個人情報を含みますが、これに限定されるものではありません）を転送するように設計されています。データ管理者は、お客様の個人データの収集および使用に適用されるプライバシー法および規制を遵守する責任を負います。

この統合では、（オプトアウトを除く）データ主体のプライバシー（GDPR など）が削除されたり、その他のプライバシーリクエストを処理したりする問題は発生しません。プライバシーリクエストを処理する際は、Microsoft Dynamics 365 と Campaign （Adobe Experience Platform Privacy Service経由）の両方で、それぞれ個別に行う必要があります。

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

Adobe Experience Platform Privacy Service に対するプライバシー削除リクエストを発行しました
リクエストが正常に完了するまで監視
レコードが Campaign インスタンスにないことを確認
（間もなく） Dynamics 365 内のプライバシー削除を発行します
レコードが両方のシステムから削除されたことを確認します

IMPORTANT

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

オプトアウト opt-out

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

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

「今後の連絡の期限」プレフィックスが付いたキャンペーン属性（例：メールでの連絡の終了）、
ccpa の特定の属性

プロファイルエンティティフィールドについて詳しくはこちらを参照してください。

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

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

一方向（Microsoft Dynamics 365 から Campaign）:Dynamics 365 は、オプトアウトの情報源です。オプトアウト属性は、Dynamics 365 からCampaign Standardに一方向に同期されます
単方向（Campaign からMicrosoft Dynamics 365）：オプトアウトの情報源はCampaign Standardです。オプトアウト属性は、Campaign Standardから Dynamics 365 に一方向に同期されます
双方向:Dynamics 365 とCampaign Standardはどちらも信頼できる情報源です。オプトアウト属性は、Campaign Standardと Dynamics 365 間で双方向に同期されます

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

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

オプトイン/オプトアウトオプションを選択する方法については、この節を参照してください。

NOTE

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

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

IMPORTANT

双方向 または 一方向（Campaign からMicrosoft Dynamics 365） のオプトアウト設定が必要な場合、Campaign インスタンスにオプトアウトワークフローを設定するには、Adobeの技術担当者にリクエストを送信する必要があります

Campaign SFTP の使用状況

以下のユースケースでは、統合で Campaign SFTP ストレージを利用する必要があります。これらのユースケースに対応するのに十分なストレージ容量が SFTP アカウントにあることを確認する必要があります。ライセンス済み SFTP ストレージ容量を超えると、Campaign、統合および SFTP アカウントの機能使用が大幅に損なわれる可能性があります。

ユースケース

説明

双方向および単方向（Campaign からMicrosoft Dynamics 365）

双方向および一方向（Campaign からMicrosoft Dynamics 365）のオプトアウトデータフローでは、Campaign SFTP ストレージを使用します。 Campaign ワークフローでは、増分変更を SFTP フォルダーにエクスポートします。そこから、統合はレコードとプロセスを取得します。

オプトアウトログ

コネクタの出力ログは、統合のトラブルシューティングに役立ちます。出力ログは、オン/オフを切り替えることができます。

IMPORTANT

SFTP フォルダーにアクセスしてダウンロードする情報については、ユーザーが責任を負います。情報に個人データが含まれている場合、適用されるプライバシー法および規制を遵守する責任があります。詳細情報。

データ管理

既存の Campaign データ

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

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

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

NOTE

既存のお客様による導入は複雑なので、統合を計画および設定する際は、Adobeの技術担当者と協力することをお勧めします。

データ同期頻度

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

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

データ使用契約

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

ガードレールと制限

IMPORTANT

ユーザー側の特定のアクション（レコードの初期取り込み、レコードデータの再生など）その結果、大量のレコードがMicrosoft Dynamics 365 からAdobe Campaign インスタンスに取り込まれる可能性があります。パフォーマンス上の問題が発生するリスクを軽減するために、すべての Campaign プロセスを停止することをお勧めします（マーケティングアクティビティやワークフローの実行など）。大量のレコードが Campaign に取り込まれるまで。

カスタムエンティティ

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

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

カスタムエンティティデータフローを設定する場合は、次の点に注意することが重要です。

Campaign のカスタムリソースの作成と変更は慎重に行うべき操作で、エキスパートユーザーのみが実行する必要があります。
カスタムエンティティのデータフローでは、同期されたカスタムエンティティの Dynamics 365 内で変更追跡を有効にする必要があります。
統合の並列処理が原因で、親およびリンクされた子レコードが Dynamics 365 でほぼ同時に作成された場合、その親レコードよりも前に新しい子レコードを Campaign に書き込める可能性がわずかながらあります。
1 カーディナリティシンプルリンク オプションを使用して親と子が Campaign 側でリンクされている場合、親レコードが Campaign に到達するまで、子レコードは（UI または API 経由で）非表示になりアクセスできなくなります。
（Campaign での 1 基数のシンプルリンク の場合）子レコードが Dynamics 365 で更新または削除され、Campaign に親レコードが表示される前にその変更が Campaign に書き込まれる場合（可能性は低いですが、リモートで表示される可能性があります）、その更新または削除は Campaign で処理されず、エラーが発生します。更新の場合、更新されたレコードを同期するには、該当するレコードを Dynamics 365 で再度更新する必要があります。削除の場合、Dynamics 365 には削除または更新するレコードがないので、問題のレコードはキャンペーン側で個別に処理する必要があります。
非表示の子レコードがあり、それにアクセスする方法がないと思われる状況になった場合は、カーディナリティリンクタイプを一時的に 0 または 1 のカーディナリティシンプルリンク に変更して、それらのレコードにアクセスできます。

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

統合ガードレール

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

統合で生成されるエンジンコール量をサポートするには、適切な Campaign パッケージのライセンスを取得する必要があります。ライセンス済みエンジン呼び出しボリュームを超えると、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）
統合では、1 つのカスタムリソースにつき最大 5 つのリンク列をサポートします。カスタムリソース間で複数の列をリンクすると、パフォーマンスに大きな影響を与える可能性があります。 1 基数シンプルリンク よりも 0 または 1 基数シンプルリンク をお勧めします。
この統合は、プリミティブ Microsoft Dynamics 365 データタイプ（ブール、整数、小数、倍精度浮動小数点数、文字列、日時、日付）とAdobe Campaign Standard データタイプ（整数、ブール、浮動小数、倍精度浮動小数点数、日付、日時、文字列）間の変換をサポートします。より高度なデータタイプは文字列として解釈され、そのまま同期されます。
Adobeとお客様の間で、オンボーディングのメンテナンスウィンドウを確立する必要が生じる場合があります。
統合の使用状況の大幅な増加または「スパイク」は、新しいレコードや更新されたレコードの急激な増加など、データ同期の速度低下を引き起こす可能性があることに注意してください。
統合の一環として、Microsoft Azure と Dynamics 365 の統合前の設定手順を完了する必要があります。設定手順このページを参照してください
Dynamics 365 と Campaign のデータモデルが統合され、維持されることになっています。

統合の境界

この統合は、Microsoft Dynamics 365 と Campaign の間で一般的なデータ移動の一般的なユースケースを解決するように設計されましたが、お客様ごとに固有のすべてのユースケースに対応するものではありません。

この統合では、プライバシー（GDPR など）の削除は発行されません。エンドユーザーのプライバシーリクエストを処理する責任はお客様にあります。このようなリクエストは、Campaign （Adobe Experience Platform Privacy Service経由）と Dynamics 365 の両方で個別に行う必要があります。必要に応じて、統合はデータ同期に役立つ定期的な削除を発行できます。詳しくはプライバシーの節を参照してください。
オプトアウト情報（顧客が設定した場合）を除き、プロファイルまたはカスタムエンティティデータは Campaign から Dynamics 365 に同期されません。
キャンペーンの購読管理（購読/購読解除など）は、ネイティブではサポートされていません。
Dynamics 365 内からの Campaign メールキャンペーンの作成とトリガーはサポートされていません。
この統合では、Dynamics 365 とCampaign Standardデータモデル間のデータのリモデリングはサポートされていまん。この統合では、1 つの Dynamics 365 テーブルを 1 つの Campaign テーブルに同期する必要があります。

recommendation-more-help

3ef63344-7f3d-48f9-85ed-02bf569c4fff