“通知”の検索結果
-
基本機能、概要モバイルメッセージング:MobleConnect(SMS)、MobilePush(APP)、GroupConnect (LINE)SMS、プッシュ通知、LINEグループメッセージングを使用してクロスチャネルのエンゲージメントを作成あらかじめ用意されたSMSテンプレートおよびドラッグ&ドロップツールを使用して、メッセージをカスタマイズプッシュ通知でアプリケーションの定着を促進ジオフェンシングとビーコンを使用して外出先で顧客をターゲットに設定 時間を意識したパーソナライズされたリマインダーやアラートを提供 モバイルAPIを使用してカスタムソリューションを作成および自動化利用事例送信対象を事前にセグメントし、より関連性の高い情報をMobilePushで送信例:最近動きのない顧客に向けて新商品を宣伝したいLINE活用事例カスタマーサポートあらかじめよくある質問を登録しておき自動応答にするプログレッシブプロファイリング 簡単な質問を重ね顧客情報を蓄積する誕生日など特定の日時のお知らせ購入完了後のお知らせまとめもっと使い方を知りたいかはMC Tips!や勉強会をへご参加くださいMC Tips!はこちらコミュニティのページが表示されますので”アクセス方法”のリンクを参照くださいコミュニティへ参加がまだの方は参加後に再度クリックください
-
アカウント内でのビジネスユニット (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) ドメインを割り当てるか🧭 Tips: SAP ドメインとして最も利用されているのは「サブドメイン委任」📌 ドメイン区分の整理 (例: URL 視点で見ると SAP ドメインは「mail.salesforce.com」となる)📌 ドメイン関連 SKU ではどこまでをカバーするのか📌 ドメイン戦略と IP アドレス / プライベートドメイン / SSLの追加適用例ドメインに紐づく SAP や SSL において、設定完了後に既存のドメインを別のものに “移行” することは不可。すでに SKU を通じて処理済みであれば、別ドメイン用としての新規 SKU が必要。 モバイル キャリア ドメイン (例: “@docomo.ne.jp”) を大量に持つ場合メール送信専用 IP アドレスの追加を検討 (後述)● ● ●🌵Note: “社内の部門別/チーム別” での BU 分割は... 将来問題が起きるかも?メール、SMS、モバイルアプリ、ウェブ (LP) という具合に、それぞれの担当が個別に BU を持った場合、連絡先キーが一致しないことよるコンタクト数の超過、Journey でのマルチチャンネル配信不可、エンドカスタマーは別々のチャネルから近似のメッセージを受け取る (コミュニケーションの分断)、といった弊害が予想される。BU 分けするとしても、ブランド別 / 国別が望ましい。
-
アカウントの設定ビジネスユニット環境設定 (BU 作成毎)ユーザー / ロール / 多要素認証 (MFA) もしくは SSOデータ連携前の準備MC SFTPMC SFTP ユーザーアカウント (認証: パスワード or SSH 鍵 など) 複数 SFTP ユーザーを作成する場合、利用用途の明確な切り分けを (注: アクセスできるユーザーの増加とセキュリティリスクは比例する) 🌵Note: “<tenant-specific>.ftp.marketingcloudops.com” 形式のテナント固有のエンドポイント (TSE)となっているか確認🌵Note: デフォルトだとSFTP のパスワード有効期限は 90 日間。セキュリティ設定の [パスワードの有効期限から FTP ユーザーを除外] でこの期限の無効化が可能。外部 SFTP (MC 側を SFTP クライアントとしてファイルを転送する場合)クロスクラウド連携Marketing Cloud Connect (aka MC Connect)Multi-Org 構成にするかどうか🌵Note: MC 連携用の Sales/Service Cloud 側のユーザーアカウント言語は「英語」がベターDistributed MarketingCore 側からオペレーションにより、Journey 経由でメール or SMS を配信 (要件に注意)API (必要に応じて)メール関連のコンフィグレーション日本向けメール配信で有効化が望ましい設定 (いずれもテクニカル サポート ケース経由で有効化)メール本文に対する BASE64 / Quoted-Printable 有効化 (Docomo 対策) (MID 単位) 特定ドメインに対するスロットリング (MID 単位)バウンスリトライ時時間 (IP アドレス単位)共有 IP アドレスを選択されている場合、この変更は不可Option: ウェブ解析ツール (例: Google Analytics UTMパラメータ) に合わせてパラメーターマネージャーの Web Analytics コネクタ上でトラッキングパラメーターをセット (MID 単位) * 参考: 外部記事Option: 専用 MTA プールを持つ場合は MC サービスチーム支援のもと個別の要件に応じて調整可通知管理Automation Studio のオートメーションのスキップ/エラー/完了の通知アラートマネージャー (Alert Manager) の通知製品コミュニケーションメールの受信条件は、"システム管理者" / "Marketing Cloud 管理者" のロール🌵Note: 仕様変更・メンテナンス・製品の廃止等から、お客様個別で実施が必要な作業も含めて、継続して利用する上で極めて重要な情報が Salesforce 側からメールで通知されることがある。このような重要なお知らせを受け取るべき人はこれらロールを保持しているか、今一度チェックを。Trust - Status でメジャーリリースの日程の通知 & 障害を受信 (アカウントがどの Stack かを確認する方法)● ● ●🌵Note: 設定した内容はドキュメントに残しておく設定変更は副作用を伴うこともあるため (例: SFTP への IP ホワイトリストを設定することでアクセス不可に)、早めにチーム間で通知を。例: アカウント構成 / セキュリティ設定 / IP 一覧 etcデフォルトからの設定変更箇所 (例: Content Builder の自動保存の無効化) を記録しておくだけでも、MC を将来利用する予定のメンバーとの共通認識にできる。クラウドサービスは設定周りが簡単にいじれる分、実装当時の設定の確認を怠っていると、数年後に大きな問題に...ということにも。
-
購読ステータスの管理(オプトイン/アウト)を理解するMarketing Cloudの購読取り消しのレベルは3種類存在するグローバル / プライマリ(アカウント) / リスト:参考リンクさらにプライマリ(アカウント)レベルの購読取り消しには、エンタープライズ全体での購読取り消しと、ビジネスユニットごとの購読取り消しがあるトップの親 BU (= EID) の購読取り消しは必ずエンタープライズ全体での購読取り消しとなり、ビジネスニット単位の購読取り消しはできないよって、複数ブランドを持つお客様のベストプラクティスとしては、親 BU は全体を管理するための専用の BU という運用として (親BUから本番のメール配信はしない)、子 BU では個別ブランド専用の BU としてビジネスユニットごとの購読管理にすることを推奨購読取り消しの方法メールの “購読取り消し“ には複数の方法がある配信解除用のアドレス “List-Unsubscribe” (iOS メールや Gmail 経由)ISP (Internet Service Provider) からのフィードバックループ購読取り消しリンク (ワンクリック購読取り消し)プロファイルセンターと購読センター返信メール (キーワードによる購読取り消しが有効な場合)MC UI 上からの手動でのステータス変更CloudPages での管理(作り込みが必要)購読取り消しを無視して配信し続けると ESP (Email Service Provider) は該当 IP をブロックリストに追加するので注意バウンスについて理解し設定を確認するバウンスと購読者のステータスについて Email Studio でのバウンスメール管理バウンス理由一覧:Marketing Cloud のメール送信の不達理由と説明バウンスに関して知っておきたいポイントリトライ時間の変更が済んでいるか確認する上記リンク先「Email Studio でのバウンスメール管理」に記載のとおり、ソフトバウンスはデフォルトで15分ごと72時間同じメールの再送信を行う。そのためメールの送信開始時間帯によっては、深夜時間帯に購読者がメールを受信する可能性があるそれを防ぐため、日本向けのメール配信では72時間ではなく4〜6時間への変更を推奨しているポケットガイド パッキング編でも触れているが(参照)、もし設定変更がまだの場合はリトライ時間の変更を行う:Marketing Cloud - Deliverability 推奨設定: リトライ継続時間の変更送信先ドメインが docomo でユーザが見つからない場合docomoアドレス(@docomo.ne.jp)向けメールで、明らかにメールアドレスが合っているにも関わらずUserUnknownとなった場合は「購読者(携帯を持っている方)の設定による受信拒否」に合致している可能性がある→メールアドレスが存在するのにハードバウンスとして扱われてしまう「バウンス」や「配信不能」の購読者に、むやみにメールを送り続けてはいけない存在しないメールアドレスやスパム判定されたメールを送り続けると、最終的に ISP 側から「迷惑メール配信している」と判断されてブラックリスト入りすることになってしまうそのため、購読者ステータスがバウンスや配信不能となっている人に対して、何の判断もせずにステータスをアクティブに上書きして送り続けるような事は避けるべき。結果として全てのメールの配信到達性を下げる事につながってしまう参考:運用開始後はバウンスを必ずモニタリングするバウンスを放置すると、ISPからの評価が下がり、本来届くべき人にも届きづらくなる可能性がある(⛰ STEP 4 : 大量配信の準備をする)MCのレポート機能を使い、初回配信はもちろん、定期的にバウンスの率やバウンス理由を確認することは、配信到達率を維持向上させるために重要。定期的な確認を運用として組み込む事を推奨バウンスを確認する様々な方法概況を分かりやすく把握:Intelligence Reports for Engagementドメイン別のバウンス状況などを見やすく簡単に表示できる。ただデータが反映されるまでのタイムラグが最大1日強あるため、すぐに結果を確認したいときには不向き送信ジョブ単位でバウンス状況を確認:Email Studioのマイトラッキング (リンク先の「バウンストラッキング」を参照)送信ジョブ単位でドメイン別のバウンス状況を確認:すべてのドメインのメールパフォーマンスレポート または ドメイン別メールパフォーマンスレポート発生したバウンスを一覧出力:Bounceデータビュー購読者別にバウンス状態を確認:Email Studio の すべての購読者 または ステータス別の購読者エクスポート🌵Note: チャネルのつながりを維持するためにメールがハードバウンスした場合、今後のメール通知は一切行えない事を意味する。この状況はコンタクトセンターでの電話対応や郵送といったコストを結果的に増大させるこのような将来起こりうるコストの増加を事前に予防するため、メールが不通に至った顧客に対しSMS(ショートメッセージ)やモバイルPush通知でお知らせするといった方法を取られる企業もある。この通知により顧客自身でメールアドレスを変更するように誘導し、メールチャネルが途絶えることを防いでいる。
- 1