【第317回】 Marketing Cloud Next ： 同意レコードの自動作成

Marketing Cloud Next Growth & Advanced Editions では、レコードの作成・更新をきっかけに「同意（Consent）」を自動作成する場合、イベントトリガーフローの 「Prospect, Lead, Contact or Related Record Change（見込み客、リード、取引先責任者、または関連レコードの変更）」 を利用する方法が、最もシンプルで分かりやすい構成と言えるでしょう。

一方で、同じ処理は Data Cloud トリガーフロー を利用して実装することも可能です。どちらも同意レコードの自動作成・更新を実現できますが、トリガーの仕組みや利用できる機能、設計上の考慮点には違いがあります。

そこで本記事では、取引先責任者の新規作成 および メールアドレス変更 を例に、イベントトリガーフローを利用した実装方法を中心に紹介するとともに、Data Cloud トリガーフローとの違いや、それぞれの特徴について解説します。

サポートされていない同意の作成について

Salesforce では、この「同意の作成」に関して 公式ヘルプドキュメント を公開しており、サポート対象外の方法への注意喚起をしています。

現在、正式にサポートされている方法は次の 3 つです。

• ① イベントトリガーフロー

• ② Data Cloud トリガーフロー

• ③ オンデマンドフロー

一方で、以下のフローアクションを利用した同意レコードの作成はサポート対象外となっています。

• MessagingConsent.MessagingConsent

• MessagingConsentV2.MessagingConsent

これらの非公式アクションを利用した場合、一見すると同意レコードは正常に作成されているように見えても、実際の配信制御との整合性が取れなくなる可能性があります。

例えば、以下のような状態が発生する可能性があります。

• 同意レコードは オプトイン になっているにもかかわらず、実際にはメールを送信できない

• 同意レコードは オプトアウト になっているにもかかわらず、メールを送信できてしまう

このような不整合を防ぐためにも、同意レコードの作成は Salesforce が正式にサポートしている方法で実装することをおすすめします。

同意管理を無効化するという選択肢について

Marketing Cloud Next には、標準の同意管理機能自体を無効化する設定も用意されています。

もちろん、この設定を無効化し、同意レコードを一切作成しない運用も技術的には可能です。

しかし、その場合は List Unsubscribe による購読解除要求を Marketing Cloud Next が正しく処理できなくなります。つまり、受信者がメールクライアントから購読解除を行っても、その情報が同意管理へ反映されず、結果として無視される形になります。

そのため、たとえ標準の購読解除リンクやプリファレンスセンターを利用しない運用であっても、少なくとも配信対象となるメールアドレスには オプトイン状態の同意レコード を作成しておくことが望ましいと考えられます。

個人的には、プロモーションメールを配信する環境において、Marketing Cloud Next の標準同意管理機能を完全に利用しないという選択は、現時点ではあまり現実的ではないと考えています。🤔

① イベントトリガーフローの設定手順

今回ご紹介する構成は、新しいメールアドレスに対してオプトインの同意レコードを自動作成することを目的とした、シンプルな実装例です。

1. イベントトリガーフローを新規作成します。

2. イベントとして 「Prospect, Lead, Contact or Related Record Change（見込み客、リード、取引先責任者、または関連レコードの変更）」 を選択します。

3. 今回は 取引先責任者（Contact）を対象として、以下のように設定します。

• オブジェクト ： 取引先責任者（Contact）

• トリガー条件 ：「レコードが作成または更新されたとき」

• エントリー条件 ： Email（項目）・is Null（演算子）・False（値）

4. 続いて Get Records 要素を配置し、トリガーされた Contact のメールアドレスを利用して Communication Subscription Consent DMO を検索します。

• 要素名（参考）
  Get Consent Records

• データソース
  Data Cloud Object

• Data Cloud オブジェクト
  Communication Subscription Consent

• 検索条件
  Communication Subscription Consent > Contact Point Value
     Equals
  {!$Input.Email}

なお、以下の設定はデフォルト値のままで問題ありません。

• Sort Records

• How Many Records to Store

• How to Store Record Data

5. 次に Decision 要素を追加し、取得した同意レコードが存在するかどうかを判定します。

• 要素名（参考）
  Has Existing Consent Record

• 分岐パス名（参考）
  Has Existing Consent Record

• 条件
  {!Get_Consent_Records.ssot__ContactPointValueText__c}
     Equals
  {!$Input.Email}

6. Decision 要素のデフォルトパス（既存レコードなし）に、「同意を作成」要素を追加します。

7. 「同意を作成」要素の設定例は、以下のとおりです。

• 要素名（例）
  Opt In (0eBdL000000XXXXXXX)

• 同意ステータス
  オプトイン

• 連絡先
  {!$Record.ssot__EmailAddress__c}（変更後 or 新規のメールアドレス）

• チャネル
  Email

• コミュニケーション登録
  上で選択した 18 桁の ID に一致するものを選んでください

設定が完了したらフローを保存し、アクティブ化すれば完成です。

フロー保存時に発生するエラーについて

• フロー保存時に 「必須項目に入力してください。（Complete required fields.）」 というエラーが表示されることがあります。

• 設定内容に問題がないにもかかわらず発生する場合は、「同意を作成」アクションを開き直して設定をやり直すことで解消するケースがあります。特に「コミュニケーション登録」の設定が保存時に外れてしまうことがあるため、その項目が保持されているか確認してください。

• それでも解消しない場合は、一度フローを保存して閉じ、再度開いてから設定し直すと、正常に保存できることがあります。

② Data Cloud トリガーフローの設定手順

Data Cloud トリガーフローを利用するメリットは、大きく分けて 2 つあります。

1. データソースごとにフローを作成する必要がない

イベントトリガーフローでは、Contact や Lead など、トリガー対象となるデータソースごとにフローを作成する必要があります。

一方、Data Cloud トリガーフローでは Unified Data Model を起点として処理を実行できるため、Contact、Lead、個人取引先などの違いを意識せず、1 つのフローで共通のロジックを実装できます。

そのため、複数のデータソースを扱う環境や、個人取引先（Person Account）を利用している環境では、保守性の面でも大きなメリットがあります。

2. $Record__Prior を利用できる

もう 1 つの大きなメリットは、イベントトリガーフローでは利用できない $Record__Prior（変更前のレコード）がサポートされていることです。

これは、メールアドレス変更時の同意管理において非常に重要な機能です。

例えば、変更前のメールアドレスに紐づくコミュニケーション登録が オプトアウト だった場合、新しいメールアドレスに対して自動的に オプトイン の同意レコードを作成してしまうのは適切ではありません。

$Record__Prior を利用すれば、変更前のメールアドレスや同意状態を参照しながら処理を分岐できるため、このような意図しない再オプトインを防ぐことができます。

本記事では、このメリットを活かし、変更前のメールアドレスがオプトアウトだった場合は、新しいメールアドレスにもオプトインを作成しない構成を例として解説します。

今回ご紹介する構成は、新しいメールアドレスに対して、変更前のメールアドレスがオプトアウトでない場合のみ、オプトインの同意レコードを作成することを目的とした実装例です。

もちろん、同意管理のルールは企業によって異なるため、このロジックが唯一の正解というわけではありません。実際の要件や運用ポリシーに合わせて、条件や処理内容を調整してください。

1. Data Cloud トリガーフローを新規作成します。

2. 開始要素は以下のように設定します。

• オブジェクト ： Contact Point Email

• フローをトリガーする条件 ：「レコードが作成または更新されたとき」

• エントリ条件 ： なし

3. まず、「レコードを取得」要素を配置し、変更前のメールアドレス に紐づく同意レコードを取得します。

• 要素名（例）
  Get Previous Consent Record

• データソース
  Data Cloud Object

• Data Cloud オブジェクト
  Communication Subscription Consent

• 検索条件
  ① Communication Subscription Consent > Contact Point Value
     次の文字列と一致する
  {!$Record__Prior.ssot__EmailAddress__c}（変更前のメールアドレス）
  AND
  ② Communication Subscription Consent > Communication Subscription Channel Type
     次の文字列と一致する
  0eBdL000000XXXXXXX（0eBで始まる 18 桁のコミュニケーション登録 ID）

なお、以下の設定はデフォルトのままで問題ありません。

• Sort Records（レコードを並び替え）

• How Many Records to Store（保存するレコード数）

• How to Store Record Data（レコードデータの保存方法）

4. 続いて、「決定」要素を配置し、変更前のメールアドレスに紐づく同意レコードが OPT_OUT かどうかを判定します。

• 要素名（例）
  Has Previous Consent Record

• 分岐パス名（例）
  Consent Record Found（左側のパス）
  No Consent Record（右側のパス）

• 条件
  Get Previous Consent Record > Consent Status
     次の文字列と一致する
  OPT_OUT

現在のフローは以下のようになります。

5. 次に、右側の No Consent Record パスに「レコードの取得」要素を追加し、現在（変更後または新規）のメールアドレス に対する同意レコードを取得します。

• 要素名（例）
  Get Current Consent Record

• データソース
  Data Cloud Object

• Data Cloud オブジェクト
  Communication Subscription Consent

• 検索条件
  ① Communication Subscription Consent > Contact Point Value
     次の文字列と一致する
  {!$Record.ssot__EmailAddress__c}（変更後 or 新規のメールアドレス）
  AND
  ② Communication Subscription Consent > Communication Subscription Channel Type
     次の文字列と一致する
  0eBdL000000XXXXXXX（0eBで始まる 18 桁のコミュニケーション登録 ID）

こちらも以下はデフォルト設定のままで問題ありません。

• Sort Records（レコードを並び替え）

• How Many Records to Store（保存するレコード数）

• How to Store Record Data（レコードデータの保存方法）

6. 続いて、「決定」要素を配置し、現在のメールアドレスに対する同意レコードが既に存在するかどうかを判定します。

• 要素名（例）
  Has Current Consent Record

• 分岐パス名（例）
  Consent Record Found（左側のパス）
  No Consent Record（右側のパス）

• 条件
  Get Current Consent Record > Communication Subscription Consent Id　
     空白（Is Blank）
  False

ここまで設定すると、フローは以下のようになります。

7. 右側の No Consent Record パスに、「同意を作成」アクション を追加します。

8. 「同意を作成」アクションの設定例は、以下のとおりです。

• 要素名（例）
  Opt In (0eBdL000000XXXXXXX)

• 同意ステータス
  オプトイン

• 連絡先
  {!$Record.ssot__EmailAddress__c}（変更後 or 新規のメールアドレス）

• チャネル
  Email

• コミュニケーション登録
  上で選択した 18 桁の ID に一致するものを選んでください

9. 続いて、Has Previous Consent Record の左側のパスにも「同意を作成」アクション を追加します。こちらの同意は「オプトアウト」で作成します。

• 要素名（例）
  Opt Out (0eBdL000000XXXXXXX)

• 同意ステータス
  オプトアウト

• 連絡先
  {!$Record.ssot__EmailAddress__c}（変更後 or 新規のメールアドレス）

• チャネル
  Email

• コミュニケーション登録
  上で選択した 18 桁の ID に一致するものを選んでください

10. ここまで設定したら、一度フローを保存します。
（フロー参考名：Data Cloud Consent Creation Flow）

11. この一連の設定は、1 つのコミュニケーション登録 に対するものです。

複数のコミュニケーション登録を利用している場合は、赤枠の処理をコピーし、各コミュニケーション登録ごとに設定を行ってください。

12. 例えば、3 種類のコミュニケーション登録を利用している場合は、以下のように同じ処理を直列に並べます。

これで設定は完了です。

フロー保存時に発生するエラーについて

• フロー保存時に 「必須項目に入力してください。（Complete required fields.）」 というエラーが表示されることがあります。

• 設定内容に問題がないにもかかわらず発生する場合は、「同意を作成」アクションを開き直して設定をやり直すことで解消するケースがあります。特に「コミュニケーション登録」の設定が保存時に外れてしまうことがあるため、その項目が保持されているか確認してください。

• それでも解消しない場合は、一度フローを保存して閉じ、再度開いてから設定し直すと、正常に保存できることがあります。

いかがでしたでしょうか。

「同意の作成」は、Marketing Cloud Next において非常に議論の多いテーマの一つです。実際には、すべてのケースに当てはまる正解が存在するわけではなく、各社の同意管理ポリシーやデータモデル、運用方針に応じて、最適な設計・実装を選択する必要があります。

そのため、本記事でご紹介した内容も、「唯一のベストプラクティス」ではなく、「実装パターンの一例」として参考にしていただければ幸いです。

個人的には、柔軟性を重視するのであれば Data Cloud トリガーフローを利用する方が扱いやすいと感じています。特に $Record__Prior を利用できる点は非常に大きなメリットであり、メールアドレス変更時の同意状態の引き継ぎなど、より安全な制御を実現できます。

一方で、「新規レコード作成時に同意レコードを付与したいだけ」といったシンプルな要件であれば、CRM レコードを起点としたイベントトリガーフローの方が実装しやすいケースもあります。特に CRM のフローに慣れている方であれば、こちらの方が直感的に構築できるでしょう。

つまり、どちらが優れているという話ではなく、要件や運用に応じて適切な方法を選択することが重要です。ぜひ、それぞれの特徴を理解したうえで、ご自身の環境に最適な方法を選んでみてください。

今回は以上です。

次の記事はこちら

前回の記事はこちら

私の note のトップページはこちら