🎥 ウェビナー全体はこちらでご覧ください: ユーザーが実際に使用する組み込み分析の設計
主な学び
- 組み込み分析の導入は、ユーザーが静的なダッシュボードを確認するためにワークフローを離れることを強いられる場合に失敗します。
- ダッシュボード疲れは、より良い分析体験を提供する代わりに、新しいビジネスの質問ごとに別のダッシュボードが作成される場合に発生します。
- 製品チームは、特にAIが分析ワークフローの一部になるにつれて、ガバナンスされたデータと柔軟な探索のバランスを取る必要があります。
- コンテキストレイヤーは、自然言語の回答を一貫したビジネス定義で提供するため、AI分析に不可欠です。
- 組み込み分析SDKは、カスタムUX、単一の可視化、ダッシュボードのリンク、テーマ設定、会話型分析など、iframeよりもSaaSチームにより多くの制御機能を提供します。
- 組み込み分析の未来は意思決定インテリジェンスです。それは、ユーザーがすでに作業している場所で提供される、プロアクティブで説明可能なインサイトです。
誰も認めたがらない問題:あなたのダッシュボードは使われていない
BIツールを購入し、展開し、チームがダッシュボードを構築し、ローンチメールが送信されました。そして…沈黙。
もしそれが身に覚えがあるなら、あなただけではありません。最近の業界カンファレンスで、あるセッションが私たちに心に残る一文で始まりました: 誰もダッシュボードをもっと求めてはいません. しかし、新しいビジネスの質問に対するデフォルトの対応は、別のものを構築することです。
これが ダッシュボード疲れ, そしてそれは予測可能な悪循環に従います:
- 質問が発生する
- ダッシュボードが構築される
- フォローアップの質問が生じる
- 無限に繰り返す
データチームが月曜日に出荷したダッシュボードは、金曜日には古くなっている。それを構築した人物は、すべてのフィールドの意味を理解しているが、あなたのビジネスステークホルダーは理解していない。そしてSaaSの文脈では、コストはさらに高い。ユーザーが作業中のワークフローを離れて、どこか別の場所で「ダッシュボードをチェックする」必要があるたびに、彼らはコンテキストを失い、勢いを失い、最終的には完全に面倒になる。
その結果は?ほとんど何も伝えない、高価なBI投資。
パワー対コントロール:プロダクトチームのジレンマ
組み込み分析を構築するすべてのプロダクトチームは、2つの失敗モードの間で挟まれる:
| 自由度が高すぎる | コントロールが強すぎる |
|---|---|
| オープンなセルフサービスはカオスを生む。6つの部門、6つの「収益」の定義。データへの信頼は急速に失われる。 | ロックダウンされたダッシュボードは、自分自身のフォローアップの質問に答えられないユーザーを不満にさせる。彼らはExcelでシャドウ分析を構築しに行く。 |
どちらの極端な方法も機能しない。2000年代初頭はガバナンスによるロックダウンをもたらした。2010年代のローコード時代はシャドウITと暴走するスプレッドシートをもたらした。今、AIが加わることで、チームは再び締め付けようとする誘惑に駆られる—そして、彼らは再びユーザーを失うだろう。
正しい移行は、より多くの自由でも、より多くのコントロールでもない。それはより良いサービスである。 ほとんどのユーザーは、実際には〜を望んでいない 構築すること 分析。彼らが望んでいるのは、すでにいるワークフローの中で、直接的でコンテキストに基づいた回答を受け取ることである。
使いやすさは、機能ではなくプロダクト戦略である
すべてを変えるリフレーミングはこれだ:2026年において、使いやすさは「あれば良いもの」ではない。それは戦略そのものだ。
スマートフォンで銀行取引をする方法を考えてみて。食べ物を注文する方法。フライトを予約する方法。コンシューマーソフトウェアの基準が、今やエンタープライズソフトウェアの基準となった。もしあなたの組み込み分析が2008年のエンタープライズソフトウェアのように感じられるなら、ユーザーはそれを迂回するだろう。
これを推進している2つのシフトがある:
1. 会話型AIが新しいデフォルトインターフェースである
自然言語は、データに質問をする期待される方法として急速に定着している。「州ごとの預金残高を教えてください。」「実際の収益は月間予算と比較してどうですか?」ユーザーは、回答を得るためにSQL、データモデリング、またはあなたのダッシュボード設定ツールを学ぶ必要はないはずだ。
2. 認識型分析は静的なレポート作成に取って代わる
次のフロンティアは、より美しいダッシュボードではありません。それは、ユーザーが尋ねることを知る前にインサイトを表面化させる分析です。 〜する前に、 ユーザーが尋ねることを知る前に。コンテキストで更新されるKPI。しきい値が超えたときに発動するアラート。意思決定が実際に起こる場所で配信される通知。
その成果は測定可能です。セルフサービスと自然言語を分析ワークフローに統合した組織は、以下を報告しています。 新しいダッシュボードのリクエストが最大50%減少する, エンジニアリングチームをより価値の高い作業に解放します。
3つのペルソナのために設計する、1つだけではない
組み込み分析における最大の誤りの一つは、「ユーザー」を単一のペルソナとして扱うことです。実際には、少なくとも3ついます。
- ビジネスステークホルダー - ガイドされた、平易な言葉での回答を求めている。ツールを学びたいわけではない。単に意思決定をする必要があるだけ。
- パワーアナリスト - マルチステップの推論、カスタムフィルター、ドリルダウン、そして自由に探索する能力を求めている。
- 開発者/ビルダー - 既存の製品表面に組み込み分析をクリーンに埋め込むための、コンポーザブルでプログラム的なアクセスを求めている。
これらの中で一つだけのために設計すると、残りの2つを失います。まさにここで、 組み込み分析SDK は、iframeベースのBI埋め込みよりも構造的な優位性を持っています。SDKは、3つのペルソナすべてを同じロックダウンされたビューアに落とし込むのではなく、同じ製品内で各ペルソナに合わせた体験を提供する開発者へのプリミティブを提供します。
組み込みAI分析にとってコンテキストが王様である理由
ほとんどの「AI BI」の物語が崩壊する場所がここにあります。
LLMに生のスキーマを向けます。ユーザーが「今四半期の売上は?」と尋ねます。LLMは快調に数字を返しますが、それは総売上ですか?純売上ですか?認識済みですか?計上済みですか?更新料を含みますか?モデルは知りません。だから推測します。そしてLLMは「生成」なので、毎回少し異なる推測が返ってきます。 生成型,
それは分析ではありません。それは、より速く、より美しい間違いです。
解決策は、 コンテキストレイヤー をデータの上に重ねることです。このレイヤーは、ビジネスの意味をデータロジックに翻訳します。Revealでは、これは簡単なJSONまたはAPIを通じて設定され、AIに以下を伝えます:
- 一貫した定義 - 「売上」は、 このフィールドにこのフィールドを足し、このフィールドを引く、といった定義です。, どのチームでも、毎回同じ定義です。
- ハルシネーション防止 - AIは管理された定義に制約され、メトリクスを捏造することができません。
- 統制された探索 - ユーザーは何でも尋ねることができますが、常に実際のビジネスロジックに基づいた回答が得られます。
これがセマンティックレイヤー(人間向けの翻訳レイヤー)とコンテキストレイヤー(AI向けの翻訳レイヤー)の違いです。私たちが今いる世界では、 コンテキストが王様です。
インサイトからアクションへ:意思決定インテリジェンス
素晴らしいダッシュボードや素晴らしいNLQがあっても、根本的な問題が残っています。分析は、尋ねられるのを待っているのです。次のフロンティアは、 意思決定インテリジェンスです - 意思決定が行われる業務ワークフローに、説明可能なインサイトを直接組み込むこと。
ここで重要な3つのパターンがあります:
- プロアクティブなリスクスコアリング - 顧客のチャーンリスクや収益の漏れなどを自動的にフラグ付けすること。 行動を起こす時間があるうちに。四半期レビューの時ではなく。
- 人間が理解できる説明 - 推奨されるアクションには、平易な言葉による根拠が伴うため、ビジネスユーザーが理解できます。 なぜ。単に 何が。.
- 成果志向のメトリクス - ダッシュボードを何回開いたかではなく、どれだけの意思決定と行動を促したかによって、分析を測定すること。
RevealはSDKであるため、単一のKPIビジュアライゼーションをワークフローの隣に配置したり、しきい値を超えたときに通知を発生させたり、ユーザーがすでに作業している場所にチャット駆動型の推奨事項を表示したりできます。別個の「分析ゾーン」をボルトオンするわけではありません。インテリジェンスを製品に組み込むのです。
ライブデモで示すのは、
この ウェビナーのウォークスルーで、これらすべてをAcme Analytics - Reveal SDKを基に構築された架空のSaaSアプリの中にまとめています。注目すべきハイライトをいくつかご紹介します: - Reveal SDKを基に構築された架空のSaaSアプリです。ジャンプする価値のあるいくつかのハイライトをご紹介します。
- 単一の可視化モード: ホームページ上のKPIタイルが、ユーザーに「ダッシュボードを開く」ことを強制することなく、プロアクティブな回答を提供する、実際には個別のダッシュボードであること。
- ダッシュボードのリンク: フィルターコンテキストを完全に保ったまま、あるダッシュボードから別のダッシュボードへ掘り下げられるため、パワーアナリストは最初からやり直す代わりに、自分の質問を追うことができる。
- 新しいダッシュボードへの3つのパス: 空から開始(完全なWYSIWYG)、テンプレートから開始、またはユーザーがドラッグ&ドロップできる事前構築されたKPIの可視化カタログから開始。
- AIダッシュボードアシスタント: 「売上パイプラインを構築」と入力するだけで、コンテキストレイヤーに基づいた完全で管理されたダッシュボードが数秒で返ってくる。
- 会話型分析: チャットで「州ごとの預金は?」と尋ね、チャートを受け取り、次に「ツリーマップに変更して」と言うと、AIが会話のコンテキストを維持し、可視化を更新する。
- 完全なテーマ設定とホワイトラベル制御: ライトモード、ダークモード、カスタムフォント、カスタムカラー。ホストアプリを制御しているため、組み込み体験は常に「 あなたの 製品」のように見える。
なぜ組み込み分析SDKがiframeを上回るのか — いつでも
組み込み分析の唯一の選択肢がiframeである場合、BIベンダーが提供することを決定した体験に縛られます。異なるペルソナに合わせてUXを調整することはできません。単一のKPIをワークフローに組み込むことはできません。カスタムのツールチップアクション、カスタムのダッシュボードリンク、または製品内にネイティブに存在するチャット体験を追加することはできません。
RevealのようなSDKは、その状況を覆します。クライアント側でJavaScript APIを、サーバー側で.NET、Java、またはNodeバックエンドを提供するため、次のことが可能になります:
- ユーザーが見る体験を開発者が制御できる
- ダッシュボード、単一の可視化、NLQチャット、テンプレートを、製品が必要とする方法で組み合わせることができる
- すべてのインタラクション(ツールチップ、メニュー、ドリルダウン)が拡張可能である
- 組み込み分析は、単に付け足したタブではなく、あなたのSaaSアプリに組み込まれているように感じられるべきです。 組み込みの それは、ユーザーがあなたの分析を採用するか、無視するかという違いです。
最終的に重要なのは、
使いやすさという機能ではありません。それは、組み込み分析への投資が回収されるか、「もっとダッシュボードを」というバックログの中で静かに死んでいくかを決定する戦略です。
ユーザーに実際に
使ってほしいなら、 あなたの分析を: AIコンテキストレイヤーを確立し、
- すべての回答が一貫性があり、統制され、信頼できるものになるようにします。 自然言語をデフォルトのインターフェースにします。
- ユーザーがSQLではなく、平易な英語で質問できるようにします。 レポート作成から意思決定インテリジェンスへと移行します。
- — 作業が行われる場所でインサイトを組み込みます。 iframeではなく、SDKを選択します。
- , そうすれば各ペルソナが実際に必要とする体験を提供できます。ウェビナー全体を見る
完全な内訳については、ライブの
Reveal BI Reveal BI AIダッシュボード支援、NLQチャット、ダッシュボードリンク、単一ビジュアライゼーションモード、およびテーマ設定を示す製品デモ — 完全なセッションはYouTubeでご覧いただけます:
製品にRevealを組み込む準備はできていますか?
- 🌐 デモをリクエストする: revealbi.io
- 📧 営業にメールする: sales@revealbi.io
- 📧 直接連絡する: jasonb@infragistics.com
著者について: Jason Beresは、Reveal組み込み分析とIgnite UIの作成元であるInfragisticsで、製品およびコンテンツ戦略を主導しています。彼は、ユーザーが実際に採用する分析体験を設計するために、SaaSおよびISVチームと協力しています。
FAQ: ユーザーが実際に使用する組み込み分析の設計方法
組み込み分析プロジェクトが失敗する主な理由は?
組み込み分析プロジェクトのほとんどが失敗するのは、ユーザーがそれらを採用しないためです。問題は通常、ダッシュボードが不適切に構築されていることではなく、ユーザーのワークフローから切り離されているか、行動に移すのが難しいか、またはフォローアップの質問に迅速に答えられないことです。
ダッシュボード疲れとは何ですか?
ダッシュボード疲れは、新しいビジネスの質問をするたびに別のダッシュボードが必要になる場合に発生します。時間の経過とともに、ユーザーはあまりにも多くのレポート、一貫性のない定義、古いデータ、そして必要な答えを見つけるための労力に直面します。
組み込み分析SDKはiframeよりも優れているのはなぜですか?
組み込み分析SDKは、製品チームにユーザーエクスペリエンスをコントロールする力をもたらします。単に別のBIインターフェースをiframe内に配置するのではなく、SDKを使用すると、開発者はダッシュボード、単一ビジュアライゼーション、自然言語チャット、カスタムアクション、テーマ設定、および分析ワークフローをホストアプリケーションに直接組み込むことができます。
AI分析におけるコンテキストレイヤーとは何ですか?
コンテキストレイヤーは、AIが質問に一貫して回答できるように、データ背後のビジネス上の意味を定義します。例えば、「収益」が何を意味するのか、どのフィールドを使用すべきか、どのガバナンスされた定義が適用されるのかをAIに正確に伝えます。
自然言語分析は採用率をどのように向上させますか?
自然言語分析により、ユーザーはSQLやダッシュボードツール、データモデルを学習する代わりに、平易な英語で質問をすることができます。これにより、ビジネスステークホルダーにとって分析がよりアクセスしやすくなる一方で、パワーユーザーに対してはより深い探索をサポートし続けることができます。
組み込み分析における意思決定インテリジェンスとは何ですか?
意思決定インテリジェンスは、分析を静的なレポート作成から進化させます。ユーザーが意思決定を行うワークフロー内に、プロアクティブなインサイト、リスクスコア、推奨事項、アラート、および平易な言葉による説明を直接提供します。
組み込み分析は誰のために設計されるべきですか?
組み込み分析は、少なくとも3つのペルソナのために設計されるべきです。それは、ガイダンスされた回答を求めるビジネスステークホルダー、より深い探索を必要とするパワーアナリスト、そして分析を製品体験に組み込むための柔軟なツールを必要とする開発者です。
