Loading
システム管理者に対するフィッシング耐性MFA・全従業員ユーザーMFAの適用のお知らせ 続きを読む
Salesforce Data 360 について
オムニチャネルに関する考慮事項とベストプラクティス

オムニチャネルに関する考慮事項とベストプラクティス

このソリューションを実装する前に考慮すべき重要な側面とトレードオフがあります。このガイドは、顧客向けのオムニチャネル環境を有効にする方法の一例にすぎません。たとえば、独立したシングルチャネルジャーニーの代わりに、ユーザーは Data Cloud を使用して、1 つのジャーニーをメール、SMS、MobilePush のすべての活動と一緒にオーケストレーションすることで、シームレスなカスタマーエクスペリエンスを作成できます。

このソリューションで統合個人を使用する場合の潜在的なリスク

このソリューションでは、メール、SMS、MobilePush のすべてのチャネルで使用するオムニチャネル連絡先を Engagement に作成するために Marketing Cloud Engagement を実装していないことを前提としています。このガイドでは、Data Cloud で ID 解決ルールを作成して、別々の個人 (メール、SMS、MobilePush の各 SubscriberKey) を統合個人 (人を示す単一の表現) に関連付ける方法について説明します。

通常は、個人プロファイルをできるだけ使用することをお勧めします。キャンペーンでの統合個人の使用は、トランザクションまたはイベントトリガーの使用事例ではなく、プロモーションの使用事例に限定することをお勧めします。

誤った人へのメッセージ送信

統合個人は動的として検討し、変更される可能性があるため慎重に扱ってください。統合個人は、ID 解決内で設定したルールと、Data Cloud インスタンス内に保存されているデータに基づいています。ID 解決プロセスでは、外部データソースから新しくインポートされたデータまたは ID 解決ルールセットで行った変更に基づいて、個人プロファイルとそれに関連付けられた連絡先住所を特定の統合個人に追加したり、特定の統合個人から削除したりすることができます。そのため、誤った人にメッセージを送信する可能性があります。

例: Data Cloud には、John Smith という人物の統合個人を含めることができます。ID 解決ルールに基づいて、John Smith の統合プロファイルは最初に John.Smith.Email、John.Smith.SMS、John.Smith.MobilePush の 3 つの異なる個人 (Marketing Cloud Engagement の SubscriberKey) で構成されます。Cumulus は、John Smith の統合個人を有効化して Journey Builder で使用します。

John Smith の統合個人プロファイルから取得  
個人 ID EmailAddress FullName PhoneNumber Country MobilePushSubscriberKey
John.Smith.Email john.smith@example.com John Smith 555-123-1234 アメリカ John.Smith.MobilePush
John.Smith.Email の個人プロファイルから選択 John.Smith.SMS の個人プロファイルから選択 John.Smith.MobilePush の個人プロファイルから選択
           

ジャーニーの途中で、個人の John.Smith.MobilePush が John Smith の統合個人に属していないという判断結果を示す新しい情報が ID 解決に送信されます。実際、この個人プロファイルは、同じ名前の別の人物である統合個人 John Smith, Sr. に属しています。そのため、ジャーニーでは、メールと SMS メッセージが John Smith に送信され、機密情報が含まれる可能性があるプッシュ通知が John Smith, Sr. に送信される可能性があります。

オプトアウトした個人または連絡先の選択

Data Cloud では、統合個人でセグメント化する場合、条件を満たす個人が少なくとも 1 つ設定されている統合個人が対象になります。

統合個人で有効化する場合、Data Cloud でソース注文の優先度とエンゲージメント履歴を使用して、同意または設定種別に関係なく、有効化する連絡先を選択します。連絡先の有効化およびすべての連絡先にメッセージを送信することに対する同意の取得についての責任は、お客様が単独で負うものとします。

たとえば、John Smith の統合個人に 2 つの個人 (システム A の John.Smith.1 とシステム B の John.Smith.2) を関連付けることができ、それぞれが別々のデータソースからインポートされ、それぞれに独自の関連付けられた SMS 電話番号が設定されているとします。Cumulus が、SMS メッセージを統合個人がオプトインしたかどうかという条件で統合個人をセグメント化した場合、John.Smith.A が SMS メッセージにオプトインし、John.Smith.B がオプトアウトしたとしても、John Smith の統合個人は利用者の対象となります。有効化の一環として、Cumulus がソースシステムであるシステム B から取得された SMS 連絡先を優先するように選択している場合、Data Cloud でオプトアウト済みの電話番号を John.Smith.B から選択できます。

人に関する誤ったコンテキストの使用

Data Cloud では、統合個人でセグメント化する場合、条件を満たす個人が少なくとも 1 つ設定されている統合個人が対象になります。

統合個人で有効化すると、Data Cloud により、統合個人のプロファイル内のいずれかの個人からチャネルの連絡先が選択されます。この連絡先は、会社のさまざまなシステム、ブランド、部署、または関連子会社から取得される可能性があります。そのため、Data Cloud で、会社に設定された調整ルールによって決定されたソースシステムに基づいて、属性値が選択されます。

このアクションは、誤った顧客コンテキストが使用されて、カスタマーエクスペリエンスがパーソナライズされる原因になる可能性があります。顧客が望まない連絡先で対象を絞ったコンテンツやプロモーションを受信することになるかもしれないためです。

例
Cumulus は、各ブランドの連絡先を 1 つの一元化されたソースシステム内に保存しています。John Smith という人物が、john.smith@example1.com を使用して会社のブランド A (保険ブランド) で Cumulus のメールニュースレターにサインアップしました。これとは別に、その後 John Smith は john.smith@example2.com を使用してブランド B (クレジットカードブランド) にサインアップしました。最終的に、John Smith は john.smith@example3.com を使用して、モバイルアプリケーションでブランド C (株取引ブランド) にもサインアップしました。

ブランド A を担当するマーケティングチームは、住宅保険をアップグレードする可能性のある統合個人を検索するセグメントを作成します。有効化の一環として、Data Cloud により、最もエンゲージメントの高いメールアドレスである john.smith@example3.com が選択されます。

ただし、このようなブランドと住所にはコンテキスト上の関連性はありません。Cumulus が既存の住宅ローンを顧客がアップグレードするためのプロモーションを送信すると、顧客の保険に関連付けられているメールアドレスではなく、株取引アプリケーションで使用されるメールアドレスに送信されます。

例

Cumulus 内の各ブランドには異なるソースデータシステムがあり、それぞれがデータを Data Cloud にインポートしています。John Smith という人物が、会社のブランド A (保険ブランド) で Cumulus のメールニュースレターにサインアップしました。これとは別に、その後 John Smith はブランド B (クレジットカードブランド) にサインアップしました。最終的に、John Smith はモバイルアプリケーションでブランド C (株取引ブランド) にもサインアップしました。

ブランド A を担当するマーケティングチームは、住宅保険をアップグレードする可能性のある統合個人を検索するセグメントを作成します。この有効化の一環として、チームはメール、SMS、MobilePush の各連絡先を優先順位の取得元として選択し、最初にシステム A、次にシステム B、最後にシステム C から取得するようにします。

結果データエクステンションには、John のシステム A (保険ブランド) からのメール、システム B (クレジットカードブランド) からの電話番号、システム C (株取引アプリケーション) からの MobilePush キーが含まれます。

ただし、このようなブランドと住所にはコンテキスト上の関連性はありません。Cumulus が既存の住宅ローンを顧客がアップグレードするためのプロモーションを送信する場合に、保険ブランドで使用されるメールアドレスを使用することは理にかなっています。ただし、クレジットカードブランドに関連付けられている電話番号や、株取引ブランドに関連付けられているアプリケーションを使用することは適切ではありません。

チャネルごとの同意動作

Marketing Cloud Engagement には、顧客の同意と設定の管理に使用できるさまざまな機能があります。

このソリューションでは、SubscriberKey として MobilePush キーを使用してジャーニーが編成されているため、メールアドレス john.smith@example.com の同意状況が John.Smith.MobilePush のレコードに対して確認されます。

SMS メッセージ: SMS 送信の Marketing Cloud Engagement のネイティブ同意状況は、電話番号レベル (およびキーワード) で保存され、SubscriberKey レベル (メールとは異なり) では保存されません。このソリューションでは、調整する SubscriberKey に関係なく、電話 555-123-1234 の同意状況が確認されます。注意: SMS 活動を [すべての連絡先をキーワードに登録] に設定すると、ネイティブの同意が上書きされ、連絡先がオプトインされます。

メール活動のみ

  • ジャーニーのメール活動ごとに、特定のメールアドレスに送信されないようにする連絡禁止リストを関連付けます。このオプションは、メンバーが 200,000 人未満のジャーニーまたはリストのみにお勧めします。メールを送信する前に、Journey Builder で、リストに関連付けられているメールアドレスの連絡禁止状況が確認されます。
  • ジャーニーのメール活動ごとに、パブリケーションリストを関連付けます。Journey Builder では、メールを送信する前に、連絡先に関連付けられた公開状況をチェックし、連絡先が登録されているかどうか確認します。

メール、SMS、MobilePush 活動

  • ジャーニーで終了条件を使用して、人物の同意や設定を表す、最新であることがわかっている連絡先モデルの属性を監視します。ジャーニーの期間中、この値は Journey Builder で監視されます。
  • ジャーニーエントリに有効化されたデータエクステンションを使用する前に、Automation Studio でオートメーションを実行して、別データエクステンションに対して各連絡先の同意や設定の状況を検証します。無効な連絡先は、ジャーニーにエントリされる前に削除されます。
  • ジャーニーエントリソースの一部として、連絡先をジャーニーへのエントリから除外するように検索条件を設定します。無効な連絡先は、ジャーニーにエントリされる前に削除されます。

代替のオムニチャネルオーケストレーションアプローチ

メール、SMS、MobilePush のすべての活動をまとめて一緒に使用するジャーニーの代わりに、Data Cloud を使用して、独立したシングルチャネルから成る一連のジャーニーを絞り込み、オーケストレーションすることで、同様のカスタマーエクスペリエンスを作成します。

デフォルトのアドレス動作

このソリューションキットでは、Journey Builder 設定内のデフォルト送信アドレスを更新し、MobilePush キーのデフォルトのメールアドレスと SMS アドレスを上書きして、代わりに有効化されたデータエクステンションに保存されている EmailAddres と PhoneNumber に送信することをお勧めします。この方法によって、Marketing Cloud Engagement と Data Cloud のシステムで下流の更新が行われることがあります。

MobilePush キー (MobilePush SubscriberKey) 連絡先レコードの更新

送信で使用されるメールアドレスと SMS アドレスが Engagement の MobilePush キー (MobilePush SubscriberKey) 連絡先レコードに追加されるため、SubscriberKey にメールアドレスと SMS 連絡先アドレスの両方が含まれるようになります。その後、この情報は Data Cloud に同期され、MobilePush SubscriberKey の個人レコードに反映され、メールと SMS の両方の連絡先アドレスが個人に含まれるようになります。

このアクションによって更新が競合する可能性があります。Engagement では、新しいデフォルトのメールと SMS の連絡先アドレスで連絡先レコードが更新される可能性があります。一方、Data Cloud では、同じ連絡先に対して異なるメールと SMS の連絡先アドレスを使用して新しい利用者が有効化されます。

レポートとトラブルシューティング

  • すべての送信とジャーニーのレポートは、ジャーニーに使用されている SubscriberKey に基づいています。このソリューションキットの場合、MobilePush キーの値はジャーニーの SubscriberKey として機能します。
  • レポート戦略によっては、ジャーニーの送信の基準となったメールまたは SMS の SubscriberKey、または連絡先にこの値をハーモナイズするための追加プロセスが必要になる場合があります。
  • このソリューションを使用するジャーニーでは、スケジュールに基づいて更新される有効化を使用することはできません。更新により、MobilePush キー属性を購読者キーに関連付ける必須の送信リレーション設定が上書きされます。そのため、Journey Builder では MobilePush キー (MobilePush SubscriberKey を表す) の値に基づいて、オーケストレーション、パーソナライズ、送信ルックアップがすべてデフォルトに設定されます。
 
読み込み中
Salesforce Help | Article