Datorama(マーケティングクラウド)がダウン?マーケターが知っておくべきこと

Marketing Cloud ダッシュボードが突然読み込みを停止した場合、最も迅速な対応は、Datorama 自体がダウンしていると決めつけることではありません。Salesforce は現在、Datorama をMarketing Cloud Intelligenceと呼んでおり、同社の公式 Trust サイトでは、Salesforce 全体のインシデントとは別に製品の可用性を報告しています。2026 年 9 月 16 日現在、Salesforce Trust では Marketing > Intelligence が利用可能と表示されています。これは、Salesforce サービス全体の問題、コネクタの障害、ソース プラットフォームの停止、権限の問題、データ取り込みの遅延など、マーケティング担当者のデスクから見るとすべて似たような問題に見える可能性があるため重要です。

次の架空の例を考えてみましょう。有料メディア担当のマヤは、役員会議の45分前に朝のキャンペーン進捗状況ダッシュボードを開きます。いくつかのKPIタイルが読み込み中のままで、昨日の支出が表示されず、レポートのエクスポートも1つ失敗しています。彼女の最初の直感は「Datoramaがダウンしている」というものでした。しかし、すぐにキャンペーンを一時停止したり予算を変更したりするのではなく、彼女はこの状況を可用性の問題として捉えます。このように区別することで、レポートの問題がマーケティング上の意思決定ミスに発展するのを防ぐことができるのです。

マーケティング分析ダッシュボードが表示されたノートパソコン。ダッシュボードには、読み込み中の指標、利用できないレポートデータ、およびサービスステータスチェックリストが表示されている。
指標が停止し、ステータスチェックパネルが表示されたマーケティング分析ダッシュボードは、障害発生時にマーケターが最初に答えるべき質問を示しています。つまり、分析サービスが利用できないのか、それとも問題はデータ、アクセス、または接続されたソースに限定されているのか、ということです。

まず、今日の「Datoramaダウン」の意味を知りましょう。

Datoramaは、Salesforce Marketing Cloud Intelligenceの旧名称です。Salesforceは、この2つの名称が同じ製品を指していることを確認しています。このプラットフォームは、複数のソースからのマーケティングデータを接続、統合、分析、視覚化するように設計されています。社内で「Datorama」という名称を使用しているチームがあっても問題ありませんが、公式のステータスページやサポートページでは、現在一般的にMarketing Cloud Intelligenceという名称が使用されています。

名称や製品範囲については、Salesforceの公式マーケティング分析ページおよびMarketing Cloud Intelligenceのヘルプドキュメントで確認できます。

また、重要な製品の違いもあります。Marketing Cloud Intelligenceは、Marketing Cloud EngagementにバンドルされているIntelligence Reportsとは必ずしも同じものではありません。Salesforceでは、これらはアカウントやテナントの要件が異なる別々のレポートサービスとして文書化されています。同僚が「Marketing Cloudのレポート機能がダウンしている」と言った場合は、結論を出す前に、どちらの製品を指しているのかを確認してください。

Salesforceの公式ステータスで現在発表されている内容

最も信頼できる公開チェックポイントはSalesforce Trustです。2026年9月16日現在、Salesforce Trustの可用性ページでは、マーケティング > インテリジェンスが利用可能と表示されています。Salesforceは、顧客が現在のインシデント、メンテナンス、影響を受けるインスタンス、およびサービス履歴を確認できる専用のステータスサイトも提供しています。

これは、すべての顧客が正常な動作を経験していることを証明するものではありません。Salesforceのステータスはあくまで一つの指標であり、テナント、ワークスペース、コネクタ、および上流データソースのテストに代わるものではありません。つまり、公式のインシデント報告やテナント固有のチェックによって裏付けられない限り、「Datoramaがダウンしています」という見出しや社内メッセージを使用する際は、マーケティング担当者は注意する必要があるということです。

Salesforceのサポートガイドラインでは、Marketing Cloud Intelligenceに関するサポートケースを開設する前に、Trustサイトを確認することを推奨しています。また、技術的な問題を報告する際には、ビジネスへの影響、スクリーンショット、再現手順、想定される動作、関連するワークスペース、ウィジェット、またはピボットテーブルの識別子を含めるよう顧客に求めています。

架空のシナリオを使用して、4つの異なる故障タイプを分類します。

さて、マヤの話に戻りましょう。彼女はKPIが空白でエクスポートが失敗したことに気づきます。これらの症状は確かに存在しますが、原因を特定するものではありません。問題を分類するのに役立つ方法は、4つのレイヤーをテストすることです。

考えられる問題マーケターが見るかもしれないもの確認すべき事項
プラットフォームの可用性ログイン失敗、ダッシュボードの広範囲にわたるエラー、複数のワークスペースが利用不可Salesforceの信頼度、ステータスインシデント、影響を受けるインスタンス
データ取り込みまたはコネクタの問題ダッシュボードは読み込まれるが、最新のデータが欠落しているか、古い。データストリームの状態、ソース認証情報、アップストリームプラットフォームの可用性、更新タイミング
ワークスペースまたはアクセスに関する問題一部のユーザーや資産は障害を起こすが、他のユーザーや資産は正常に動作する。ユーザーロール、権限、ワークスペーススコープ、最近の構成変更
レポートまたは視覚化の問題特定のウィジェット、ページ、エクスポート、または計算が失敗する影響を受けるアセットID、フィルター、日付範囲、データモデルの変更、ブラウザの動作

マヤのケースでは、TrustサイトでIntelligenceが利用可能と表示され、別のチームメンバーが同じワークスペースを開くことができ、有料メディアソースのうち1つだけが昨日のデータを欠落していると仮定します。この場合、証拠は製品全体の障害ではなく、より限定的な取り込み側またはソース側の問題であることを示唆しています。そうなると、対応策は完全に変わります。

キャンペーンを変更する前にマーケターがすべきこと

分析機能の障害発生時に最も大きな運用リスクとなるのは、ダッシュボードそのものではありません。不完全または古いデータに基づいて、取り返しのつかないキャンペーン決定を下してしまうことです。レポートの内容が不確かな場合は、影響を受ける指標を未検証としてラベル付けし、欠落しているデータをパフォーマンスゼロとして扱わないようにしてください。

例えば、マヤはダッシュボードから支出やコンバージョンが消えたという理由だけで、チャネル予算を削減すべきではありません。最後に正常に動作したタイムスタンプを比較し、ネイティブ広告プラットフォームやソースシステムを確認し、不一致が1つのソースに影響しているのか、複数のソースに影響しているのかを把握する必要があります。分析レイヤーに行が欠落しているからといって、基となるキャンペーンの配信が停止したという証拠にはなりません。

実用的な意思決定ルールとして、行動を可逆的なものと不可逆的なものに分けることが挙げられます。レポートの再実行、ネイティブプラットフォームの確認、緊急性の低い最適化の延期などは可逆的な行動です。一方、高額なキャンペーンの一時停止、多額の予算の振り替え、経営陣への最終的なROIの報告などは不可逆的な行動となる可能性があります。データの整合性が不確かな場合は、影響の大きい変更を行う前に検証を優先すべきです。

問題を誇張せずに伝える方法

障害発生が疑われる場合、社内での表現は重要です。「Datoramaが世界的にダウンしています」という表現は、「Marketing Cloud Intelligenceダッシュボードが更新されません」という表現よりもはるかに説得力があります。後者の表現は、チームが実際に把握している状況を正確に表しているからです。

マヤは関係者に対し、「現在、Marketing Cloud Intelligenceビューに最新の有料メディアデータが欠落しています。Salesforce TrustではIntelligenceが利用不可とは表示されていませんが、予算決定のためにダッシュボードを使用する前に、影響を受けているコネクタとソースデータを確認しています。最後に確認されたレポートポイントは昨日の締め切り時点です。」と伝えることができます。

このメッセージは、観測された影響と未確認の原因を区別する点で有用です。また、意思決定者にとって明確な境界線を示します。つまり、どの指標が影響を受けているのか、何がまだ信頼できるのか、そしてどの行動を待つべきなのかが明確になるのです。

Salesforce全体でインシデントが発生している場合

製品固有のインテリジェンスタイルが正常に見えても、Salesforce 全体のインシデントが重大な影響を及ぼす可能性があります。共有認証、コアサービス、サポートアクセス、API、または依存コンポーネントは、ユーザーが製品にアクセスしたり操作したりする方法に影響を与える可能性があります。適切な対応は、すべての Salesforce 製品が障害を起こしたと決めつけるのではなく、インシデントにリストされているサービスとインスタンスを自社のテナントと比較することです。

Salesforceは、公式のインシデントチェックガイドで、進行中のインシデントとメンテナンスを確認する方法を説明しています。また、サービスステータスガイドでは、「利用可能」、「パフォーマンス低下」、「サービス中断」、「メンテナンス」などのステータスの意味についても解説しています。

マヤにとって、これは、インシデントIDが存在する場合はそれを記録し、影響を受けたインスタンスまたはサービスをメモし、役員会議中はステータスページを開いたままにしておく必要があることを意味します。該当するインシデントがない場合は、包括的な修正をただ待つのではなく、より詳細な診断を継続する必要があります。

問題が解決するまで、報告経路を保護する。

Marketing Cloud Intelligenceは、Salesforceの外部から始まることが多いレポートチェーンの中に位置づけられています。広告プラットフォーム、Web分析、CRMシステム、コマースシステム、ファイルアップロード、API、データベースフィードなど、あらゆるものがデータ提供元となり得ます。Salesforceのドキュメントでは、Marketing Cloud Intelligenceは複数のマーケティングソースを接続し、統合するシステムであると説明されています。このアーキテクチャは強力ですが、同時に、上流で古いレポートが生成される可能性もあることを意味します。

システム障害発生時には、簡単な証拠ログを保存してください。具体的には、最初に障害が発生した時刻、最後に確認されたデータタイムスタンプ、影響を受けたワークスペースまたはレポート、影響を受けたソース、スクリーンショット、正確なエラーメッセージ、および最近の構成変更などを記録しておきましょう。サポートが必要になった場合、これらの詳細情報があれば、基本的な確認作業から始まる可能性を減らすことができます。

Salesforceの広範な問題が発生している最中にヘルプポータル自体が使いづらい場合は、証拠が失われないようにローカルで記録を続けてください。ケース作成が可能になったら、完全なタイムラインを提出してください。

ダッシュボードを再び安心して利用できるタイミングを知る方法

「ページが読み込まれる」だけでは不十分です。復旧には、可用性とデータ検証の両方が含まれるべきです。この仮想シナリオでは、Mayaは影響を受けたソースの更新が再開されるまで待機し、その後、同じ日付範囲の重要な指標の小さなセットをネイティブソースと比較します。また、最初の更新が完了したと仮定するのではなく、遅延したレコードが完全に到着したかどうかも確認します。

適切な復旧チェックには、次の3つの項目が含まれます。関連するSalesforceステータスが正常であること、影響を受けたデータストリームが想定されるタイムスタンプに追いついていること、そして複数の高価値指標が、チームが既に使用している通常の許容範囲内に収まっていること。これらのチェックのいずれかが失敗した場合は、レポートを「完全に復旧」ではなく「復旧中」としてマークしてください。

Salesforceでは、インスタンスのサービス履歴も提供されており、これにより、障害がデータやアクセスに関する問題が発生した期間と重なっていたかどうかをチームが把握するのに役立ちます。Salesforceのサービス履歴に関する手順を参照してください。

マーケターが覚えておくべきこと

「Datoramaはダウンしていますか?」という質問に対しては、根拠に基づいた回答が最善です。Datoramaは現在Marketing Cloud Intelligenceという名称になっており、障害発生を宣言する前に、Salesforce Trustの最新の公開ページを確認する必要があります。2026年9月16日現在、Salesforce TrustではIntelligenceが利用可能と表示されているため、問題が発生しているチームは、テナントアクセス、コネクタ、ソースプラットフォーム、データの鮮度、個々のレポートアセットについても調査する必要があります。

マヤの架空の朝から得られる教訓は単純だ。ダッシュボードの不具合は、プラットフォーム全体の障害の証拠ではなく、検証を促すサインとして捉えるべきだ。データが不確かな間はキャンペーンの意思決定を保護し、既知の情報のみを伝え、復旧を宣言する前に報告経路を検証する。このアプローチは、数分間推測するよりも時間はかかるが、後になって予算の誤りや不正確な経営報告を修正するよりははるかに速い。

コメントを残す

CCUSの規模拡大:二酸化炭素回収は本当に世界の排出量を逆転させることができるのか?

CCUSの規模拡大:二酸化炭素回収は本当に世界の排出量を逆転させることができるのか?

CCUS(二酸化炭素回収・利用・貯留)への投資は増加しているが、二酸化炭素回収は世界の排出量を逆転させることができるのだろうか?その有効性、規模拡大の制約要因、そして重要な証拠について見ていこう。

国境を越えたデジタルサプライチェーンマネジメントを学ぶ場所:比較すべき7つのプログラム

国境を越えたデジタルサプライチェーンマネジメントを学ぶ場所:比較すべき7つのプログラム

デジタルサプライチェーン、ロジスティクス、アナリティクス、グローバル貿易、オペレーションに関する7つのグローバルプログラムを比較し、最適なプログラムを選択するための実践的なガイダンスを提供します。

SFから現実へ:BCI技術が移動能力と発話能力を回復させる方法

SFから現実へ:BCI技術が移動能力と発話能力を回復させる方法

脳コンピューターインターフェースが神経信号をどのように解読してコミュニケーションと運動機能を回復させるのか、最近の研究で何が達成されたのか、そしてBCIの利用を依然として制限している要因は何かを学びましょう。

The Anatomy of Commercial Drones: Hardware Breakthroughs and Autonomous Flight

The Anatomy of Commercial Drones: Hardware Breakthroughs and Autonomous Flight

See how commercial drones combine sensors, edge AI, batteries, communications, and flight-control software—and where autonomy still depends on mission and regulation.

Where Should You Study Energy Storage Engineering? 7 Battery Tech Programs Compared

Where Should You Study Energy Storage Engineering? 7 Battery Tech Programs Compared

Compare seven strong battery and energy storage master's options by materials, systems, research, industry exposure, flexibility, language, and cost trade-offs.

空を操る:産業用UAVがバッテリーとペイロードの制約を克服する方法

空を操る:産業用UAVがバッテリーとペイロードの制約を克服する方法

ペイロード質量、バッテリー制限、天候、推進効率、機体構造が産業用UAVの航続時間にどのように影響するか、そしてそれを改善する方法を学びましょう。

スマート医療機器工学を学ぶ場所:トップクラスの生物医学プログラム

スマート医療機器工学を学ぶ場所:トップクラスの生物医学プログラム

スマート医療機器向けの主要な生物医学工学プログラムを比較検討しましょう。プログラムには、設計、バイオエレクトロニクス、AI、サイバーセキュリティ、臨床研修、規制などが含まれます。

Salesforceのダウンタイムに対する事業継続計画の構築方法

Salesforceのダウンタイムに対する事業継続計画の構築方法

明確な優先順位、代替ワークフロー、復旧チェック、テスト基準、および現実的な制限事項を盛り込んだ、実用的なSalesforceダウンタイム継続計画を策定してください。

StoreForceで問題が発生していますか?小売チームが従業員管理の混乱に対処する方法

StoreForceで問題が発生していますか?小売チームが従業員管理の混乱に対処する方法

StoreForceに問題が発生すると、スケジュール管理、勤怠管理、シフト変更、店舗内コミュニケーションに支障をきたす可能性があります。問題の診断方法、小売業務の円滑な運営、復旧状況の確認方法を学びましょう。

大規模なシステム障害発生時にSalesforceサポートに連絡する方法

大規模なシステム障害発生時にSalesforceサポートに連絡する方法

大規模なシステム障害発生時にSalesforceサポートに連絡する方法、適切なチャネルの選択方法、役立つケースの準備方法、重複チケットを作成せずにフォローアップする方法を学びましょう。