よく検索されるキーワード

Marketing Cloud Engagement ポケットガイド - セットアップ編

公開日: 2025.06.30

Share:

●   ●   ●

目次

当ガイドで得られること (What’s in it for me? (WIIFM)):

  • Marketing Cloud Engagement (MCE) 導入途中での "迷子" や戦略なき "迷走" により貴重な時間を失うリスクを回避
  • 事前準備から初期実装までの "荷造り" を効率的にチェック
  • 早期に価値 (導入効果) を得るための最初の一歩が踏み出せる

⛰ STEP 1 : 事前に決めておくこと

現状を把握し、目的とゴールを決定する

  • 現状を把握する (ワークショップなどの実施)
    • 自分たちの組織の成熟度を把握する

📌メンバー内で自分たちの状況をマッピングし、現時点の成熟度を可視化した例 (人によって認識は異なる)

  • エンドカスタマーとのインタラクションを整理する

📌 B2C Customer Lifecycle Management

📌B2C アクティビティ例             📌B2B アクティビティ例  (🔗 What is customer lifecycle marketing?)

📌B2C カスタマージャーニーマップ例

  • 現在のツール、どんなレコードがあるのかを把握する
    • 利用中の既存サービスの棚卸し (例: メールの場合 : 利用中の ESP (Email Service Provider) からの切り替えか or 棲み分けか)
    • 施策を実行する上でのデータの準備 (例: メッセージ配信可否 (Opt-In/Out) のメニューは用意できるか (特に日本では SMS への配慮が薄い))
      • 🌵Note: 昔から更新されないままのメールアドレス群や、購読管理 (Opt-in/out) が一切できていない、といった基本的な顧客管理がない状況では、新しいツールを導入する以前の当たり前のことが疎かになっている状態と言える。「青い鳥」を追い求める前に「現状把握」が必要。

導入する目的とゴールを明確にする

  • ゴール: 最終的に達成したい内容
  • 目標: 今年度達成したい結果
  • 戦略: 3〜６ヶ月で取り組む内容
  • 施策: 具体的なシナリオ (初期フェーズではどこに焦点をあてるか)

📌ビジネスバリューと実装難易度からの優先するシナリオを決定 (難易度はお客様毎に大きく異なる)

  • 連動する KPI を決定

📌サクセスマップでの KPI 設定例

  • 優先施策の決定

施策を見直す

  • その施策は売上 (解約阻止、もしくは社内コストの削減) に大きく貢献するか
  • 今一度エンドカスタマーの視点に立ち返る (施策はエンドカスタマーにとっても有益かどうか)
    • 受け取った内容がエンドカスタマーにとって価値あるものであれば、行動変容へつながる

  • 最適な相手に、最適なタイミングで、最適な内容を、最適なチャネル/場所で

  • 受信する側 / 配信する側それぞれのニーズのバランスはとれているか (配信過多ではないか)

  • その他の確認ポイント
    • エンドカスタマーが受信するメッセージ件数は結果的に増えないか (件数の増加は購読取り消しへ)
      • 現行のメールマガジンはやめることはできるか、など
    • 必ずしもクロスチャネルにする必要はない
      • チャネル毎に特性が異なるため (例: SMS は即時性を重視)、実際にはクロスチャネルを１つの施策に落とすのは困難な場合がある。マルチチャネル対応はターゲットやタイミングを限定した上での一部分的な利用が現実的。
    • すべてのエンドカスタマーをカバーしようとする “完璧主義” な施策にする必要はなし (例: 必ずしも全員にクーポン配布は必要なし)。費用対効果を追求するためにパレートの法則 (80:20) を意識

●   ●   ●

🧭Tips: 成功の秘訣は “Think Big, Start Small, Scale Fast”

数年先の大きなビジョンを定めつつ、小さな課題解決からスタートし、それを拡張しつつ、早期に価値 (導入効果) を得る。

⛰ STEP 2 : ゴール/目標/戦略に応じたリソースを集める

⛰ STEP 3 : エディションとビジネスユニットの構成を決める

アカウント内でのビジネスユニット (BU) の構成を決める

📌ユーザー / アカウント / ビジネスユニットの構成例 (Enterprise ID (EID) / Member ID (MID))

  • テスト / リリース環境をどこまで用意するか？ 
    • 例: 親 BU / Production BU / Staging BU / Development BU / Sandbox BU / Training BU など
      • 🌵Note: 構成によって必須となる SKU も大きく変化する。当然ながら、本番 BU へ展開するまで別 BU での検証を重ねる分だけオペレーションが煩雑になる。(オペレーション優先で、同一 BU 上で本番とテストを同時に行うケースもある)

📌本番/テスト構成 - オプション 1〜 4

  • 🌵Note: プッシュ通知などの用途でモバイルアプリに MobilePush SDK を実装した場合、SDK コンフィグレーションを通じて特定の MID と紐づく連携となる。よって、プッシュ関連コンタクトのレコードを BU 間での右から左に移行させることは不可となる。
    • コンフィグレーションによって特定 MID へ戻されるレコード:
      • エンドカスタマー側のアプリ操作による MC へのデータの引き渡し(例: sfmc_setContactKey)、プッシュ配信に必要となるデバイストークン、開封結果などなど

ドメイン戦略を決める (要件によっては追加 SKU が必要)

  • どの BU に対し、どの Sender Authentication Package (SAP) ドメインを割り当てるか

📌 ドメイン区分の整理  (例: URL 視点で見ると SAP ドメインは「mail.salesforce.com」となる)

📌 ドメイン関連 SKU ではどこまでをカバーするのか

📌 ドメイン戦略と IP アドレス / プライベートドメイン / SSLの追加適用例

  • ドメインに紐づく SAP や SSL において、設定完了後に既存のドメインを別のものに “移行” することは不可。すでに SKU を通じて処理済みであれば、別ドメイン用としての新規 SKU が必要。 
  • モバイル キャリア ドメイン (例: “@docomo.ne.jp”) を大量に持つ場合メール送信専用 IP アドレスの追加を検討 (後述)

●   ●   ●

🌵Note: “社内の部門別/チーム別” での BU 分割は... 将来問題が起きるかも？

メール、SMS、モバイルアプリ、ウェブ (LP) という具合に、それぞれの担当が個別に BU を持った場合、連絡先キーが一致しないことよるコンタクト数の超過、Journey でのマルチチャンネル配信不可、エンドカスタマーは別々のチャネルから近似のメッセージを受け取る (コミュニケーションの分断)、といった弊害が予想される。

BU 分けするとしても、ブランド別 / 国別が望ましい。

⛰ STEP 4 : アカウントの設定をする

●   ●   ●

🌵Note: 設定した内容はドキュメントに残しておく

  • 設定変更は副作用を伴うこともあるため (例: SFTP への IP ホワイトリストを設定することでアクセス不可に)、早めにチーム間で通知を。
    • 例: アカウント構成 / セキュリティ設定 / IP 一覧 etc
  • デフォルトからの設定変更箇所 (例: Content Builder の自動保存の無効化) を記録しておくだけでも、MC を将来利用する予定のメンバーとの共通認識にできる。
  • クラウドサービスは設定周りが簡単にいじれる分、実装当時の設定の確認を怠っていると、数年後に大きな問題に...ということにも。

⛰ STEP 5 : “Email Deliverability (メール デリバラビリティ)” の下準備

ドメイン戦略に基づき設定を進める

   📌SAP 申請の案内メールのサンプル              📌SAP 申請フォームのサンプル

  • SAP ドメインで最も利用されているのは「サブドメイン委任」
    • 🧭Tips: サブドメイン委任での SAP ドメイン (例: <SUB>.root-domain.com) を決定する場合、<SUB> に "ma", "mc", "smc" といった配信側の視点で命名するよりも、"message", "contact", "info", "mail" といったエンドカスタマー視点での命名が望ましい。
  • SAP 申請フォーム上での留意点
    • 🧭Tips: 将来、複数 BU を作成する予定がある場合は、SAP 申請フォーム上で "送信者認証を適用するアカウント" では「送信者認証を本アカウントとサブアカウントに適用」(Assign Sender Authentication to this Account and Sub-Accounts)にしておくことを推奨。これにより、子 BU を新規作成した際には既存の SAP ドメインが自動的に引き継がれる。(サポートケースを通じて、子 BU へ SAP 適用を個別にリクエストすることも可能)
    • 🌵Note: SAP 申請の案内メールを受信していない場合、サポートケース経由で再送 (+ 宛先の変更) が可能。
    • 🌵Note: フォームに申請後、その内容をもとに US に所在する “Deliverability Administrator“ 担当者が処理を進めていきます。そのため、プロセスを進める過程では英語でのメールのやりとりが必要。
    • 🌵Note: SAP 申請フォームの内容は、上記の通り US に所在する担当者によって処理を進められるため、日本語の内容が把握できません (特に “補足事項(Additional Comments)“)。フォーム上での記載はすべて英語での記入を。
    • 🌵Note: 専用 IP / 共有 IP どちらがいいか → [Litmus] Dedicated vs. Shared IP
  • Option: “メール送信専用プライベート ドメイン” を追加で利用するかどうか (DNS 周りの知識が必須)
    • 🧭Tips: SAP ドメインでの送信者アドレス (From Address) ではなく、既存で利用中の送信者アドレス、もしくはルート ドメイン (noreply@root-domain.com) と同じ送信者アドレスにしたい
      • 解決方法
        • メール送信専用用プライベート ドメイン(PD) SKU を更に追加する
        • 以下いずれの送信者アドレスであっても送信で利用可能となる
      • 構成例
        • SAP ドメイン > 送信者アドレス: noreply@message.root-domain.com 
        • メール送信専用プライベート ドメイン > 送信者アドレス: noreply@root-domain.com 
          • 🌵Note: DNS 変更を伴うため対象ドメインを管理する側へ変更が可能か事前に確認しておく必要がある。送信専用プライベート ドメイン用途であれば MX は不使用。MX は SAP ドメイン側が担当する。
  • Option: メール送信専用 IP アドレスは追加でさらに必要かどうか
    • 完全に配信完了となるまでに時間的制約の有無 / 大量のモバイル キャリア (例: “@docomo.ne.jp“ ) の有無
    • メール配信量が25万通/月を超えない場合、MC の共有送信 IP アドレスを利用する方が望ましい (ただし共有 IP アドレスを選択した場合は、リトライ時間の変更などは不可となるなど一部制限がかかる)
      • 🌵Note: SAP ドメイン時と同様に追加 IP アドレスの処理も US に所在する “Deliverability Administrator“ 担当者が処理を進めていきます。そのため、プロセスを進める過程では英語でのメールのやりとりが必要となります。
  • SAP ドメインが正しくラッピングされているか外部ツールから確認する

SSL 適用範囲の洗い出し

(1) MC 側で SSL 証明書を購入し、且つ年間の自動更新も MC 側で行う

(2) お客様側で SSL 証明書を購入し、MC にケース経由で提供し適用する (ただし image (Akamai) には適用不可)

上記から (2) を選択された場合、お客様側で毎年リニューアル予定の SSL 証明書 (certificate) を差し替えするためのサポートケースを起票し続けるオペレーションが発生する。

ただし、持ち込みの場合、そのメンテナンスはお客様側での作業になり、期日が近づいても MC 側からリマインダーされることは基本的にありません。

差し替えの依頼がない場合、セキュアを維持できなくなるため、MC 側で自動的に入れ替えを行う場合があります。

いずれにしても、お客様自身で Certificate を用意するのは、実際には社内コスト含め時間/費用いずれの面でも手間ヒマがかかる。よって、特別なセキュリティ上の理由がなければ、Certificate の購入、及び毎年の更新含めて、(1) の MC 側にすべて任せる運用が手離れがよいです。

★ アカウントブランド設定の SSL 証明書

https://help.salesforce.com/articleView?id=mc_es_ssl_certificates.htm&type=5

---

Marketing Cloud で認証機関から追加コストなしで証明書を購入することをお勧めします。

Marketing Cloud は、調達プロセスのすべての側面を処理し、必要な代替証明書を管理します。...

このオプションに関連する証明書の更新は最も単純で、ほとんどまたは全く操作を必要としません。

---

  • SSL 未適用でも影響はない？ → SSL は常に必要と考えておくべき
    • 🌵Note: Google Chrome - Blocking Mixed Content の影響
      • 実際の影響 : Chrome x Yahoo Japan Web メーラーの組み合わせではイメージ表示されない。開封トラッキングイメージが呼び出されない (→ 開封結果の取得は不可)。
  • 棚卸しした結果、追加で SAP ドメイン / IP アドレス / プライベートドメイン / SSL が必要みたい...
    • SKU が必要な場合は、弊社担当営業まで。
    • 購入したにも関わらず処理が進行していない (例: 申請周りでのメール (英語) を受け取っていない) 場合、テクニカルサポートまで。 

●   ●   ●

🌵Note: 正しく設定されているか必ず最終確認を (数年後に発覚... を避けるためにも)

⛰ STEP 6 : 使えるデータを収集し整理する

連絡先キーを決める

📌同一コンタクトとして紐付けできる “顧客ID” は存在しているか？

Data-In から Data-Out までの流れを把握

  • エンドカスタマーの属性/行動/購入を理解した上で、年齢や製品の好みなど簡易に活用できるセグメントデータを準備し、それに相対するメッセージやコンテンツをセットし、適切なタイミングで配信し、行動変容に至ったかをトラッキングで確認

📌 MC での大まかなプロセス

取り込むデータを決める (Data-In)

📌各データソースからはアクティブなレコード、且つ鮮度の高いデータのみが望ましい

  • 生の正規化データを、施策のシナリオに利用しやすい形式に整理する (非正規化データへ)。
  • 各システムからのバラバラのデータを MC にすべて取り込み連携させる場合、転送〜インポートの時間の含め、手間と時間がかかる。過去数年分の履歴データすべてが必要な訳ではなく、アクティブなレコード且つ鮮度の高いデータが望ましい。 (+ さらに３日分の差分レコードだと、ファイルの転送から MC へのインポートにおいても、処理時間が高速となり、且つ問題発生時のリカバリーしやすくなる)

MC 上で生成されるデータを把握する

  • データビューを把握し、各レコードとのリレーションからデータモデルを理解する

📌Data Views in Salesforce Marketing Cloud (by sfmarketing.cloud)

外部に渡すデータを決める (Data-Out)

⛰ 参考情報

➡️ Next : Marketing Cloud Engagement ポケットガイド (2) - 初めてのメール編 

公開日: 2025.06.30

Share:

このカテゴリの人気記事

※当サイト掲載の内容は各記事およびコンテンツの公開時点の情報です。

製品別はじめてガイド

重要なお知らせ

セールスフォースをもっと学ぶ

Salesforce活用に役立つメルマガ登録

システム管理者のみなさまにおすすめの活用ウェブセミナーや、Salesforceでビジネスを推薦いただくために有益なコンテンツをお届けします。

Salesforce ヘルプ Agentforce が幅広い質問に24/365迅速に対応します

詳しくはこちら