自動レポート およびアラート データベースやアプリから。
自社のデータに対してクエリを作成し、そのクエリに対してルールを設定します。 報告 スケジュール通りに実行され、起動した瞬間にポータルに到達し、その後、規模が拡大するにつれて、Slack、Google Chat、Discord、Telegram、または電子メールに投稿されます。シンプルな数値として、またはNovaによる英語のナレーションとして表示されます。 アラート 同じ数値を継続的に監視し、設定した境界値を超えた場合にのみ通知します。売上、在庫レベル、価格、支払失敗など、クエリが返すものであれば、ルールで監視できます。
すべてのプランで、無料プランと個人プランは制限付き、ビジネスプランとエンタープライズプランはフル機能です。
ルールは2種類。保存されたクエリは1つ。
どちらもスケジュールに基づいてクエリを実行します。違いは結果の処理方法にあり、それは文章で読むよりも実際に見ていただく方が分かりやすいでしょう。
概略図 ― 説明図であり、スクリーンショットや測定データではありません。
アラート — 何か問題が発生した時のみ音声を発します
クエリが既に返す数値を基に、どのような状態が問題なのかを指定します。問題がない間は何も通知されません。問題が発生した瞬間に、指定した深刻度に応じたメッセージが1つ表示され、問題が解消されるまでは実行のたびに通知されることはありません。問題が解決すると、その旨を知らせるメッセージがもう1つ表示されるので、確認しなくても処理が完了したことがわかります。
- 設定したレベルより上または下
- 行数チェック ― 多すぎる、少なすぎる、まったくチェックしない
- 前回実行時との変化
- 重大度：
致命的-警告-情報
レポートは予定通りに、お客様のチャンネルに届きます。
スケジュールが実行され、クエリが実行されると、結果はすぐにポータルに表示されます。その後、規模が拡大するにつれて、チームが普段使用しているSlack、Google Chat、Discord、Telegram、メールなどのプラットフォームに投稿されます。ダウンロードするファイルも添付ファイルもありません。レポートはそのまま表示されます。 は メッセージの内容。数字そのまま送信するか、Novaに数字の意味を解説させるかを選択できます。
- 変更の有無に関わらず実行されます
- 何も言うことがないときは、ランニングを止められる
- シンプルな数字か、ノヴァのナレーション付きか、どちらでもお選びいただけます。
- すべての実行は、ポータル内でその実行へのリンクを保持します。
これらのほとんどすべてはデータベースに関するものではありません
収益、在庫水準、価格、支払額、そして何らかの上流工程で問題が発生したことを示す「静止テーブル」。データベースには、まさにその答えが隠されているのです。
クエリが返す任意の数値に対するしきい値アラート
しきい値監視は、最もシンプルで有用なルールです。クエリが既に返している数値を基準値として設定し、何が問題なのかを明確にします。基準値を超えている場合、基準値を下回っている場合、あるいは前回の実行時よりも大きく変化している場合などです。
このルールは、その数値が何を意味するのかについて何ら意見を述べません。昨日の売上、倉庫に残っている在庫数、単価、過去1時間の支払い失敗件数――これらはすべて単なる数値と範囲に過ぎません。判断を下すのはあなたであり、ルールは忍耐を提供するのです。
しきい値とペアリング 重大度 そして同じ数字でも、二つの異なる意味を持つことがある。軌道から外れた時は警告を発し、事態が深刻化した時は批判的な声を発するのだ。
――これは既に存在するクエリです。ルールはそのクエリを指し示すものであり、書き換えるものではありません。
セレクト c.name AS チャネル、
カウント(*) AS 注文、
合計(o.net_total) AS 収益
フロム 販売注文 o
ジョイン チャンネル c オン c.channel_id = o.channel_id
どこ o.order_date >= 現在の日付 - インターバル 「1日」
アンド o.status 'キャンセルされた'
GROUP BY c.name
ORDER BY 収益 DESC;例：テーブル、ビジネスロジック、保存済みクエリ。 収益 そして、それはしきい値アラートになります。週単位のスケジュールを設定すれば、Slackの月曜朝の投稿になります。どちらの場合も同じクエリです。私たちはそれをリリースしませんし、変更もしません。
自動生成された売上レポート（日次または週次）
午前7時に日次売上レポート、毎週月曜日に週次売上レポートを、チームメンバーが普段利用しているプラットフォームで配信します。保存済みのクエリ1つ、スケジュール2つ、スプレッドシートの受け渡しは不要です。
次に、同じクエリに対して逆方向のアラートを設定します。つまり、月曜日まで待つことなく、1日の収益が私が設定した数値を下回った場合に通知するようにします。
在庫不足アラート、そして全く動かない株
在庫数を発注点と比較して監視し、在庫が少なくなった時点でアラートを受け取ることで、対策を講じる時間的余裕を確保できます。アラートは、自社の倉庫テーブルから、またはAPIコネクタを介してShopifyから取得できます。
このアイデアを逆の視点から考えてみましょう。90日間売れ残っていて、ひっそりと資金を滞留させている商品ラインに対して、在庫アラートを設定するのです。
所有するデータに基づく価格監視
接続されたソース（カタログ、料金表、インポートしたサプライヤーフィードなど）に既に保持されている価格データにルールを設定し、変更があったり、設定した範囲を超えたりした場合に通知を受け取ることができます。
境界線を明確にしておきます。私たちは、お客様が接続された情報源を閲覧します。他社のウェブサイトから価格情報を収集することはありません。
選択した水準と比較した市場データ
当社のiTickコネクタは、市場データをクエリ可能な行として取り込むため、銘柄の価格は、ルールで監視できる単なる数値の一つとなります。例えば、ある水準を上回っているか、下回っているか、あるいは前回実行時以降に予想以上に変動したかなどを確認できます。
これはアラートツールであり、取引ツールではありません。通知を受け取るだけで、注文は発生しません。
支払いの失敗と注文の遅延
Stripeが過去1時間に記録した支払い失敗件数、または許容範囲を超えて未処理のままになっている注文数をカウントし、その数が許容範囲を超えた時点でトリガーを作動させます。
そして、復旧通知ではシステムが正常に戻ったことが伝えられます。これは、ほとんどのアラートシステムが省略している重要な点です。
沈黙したパイプライン
テーブルがデータを受信しなくなった場合、通常は上流で何らかの問題が発生したことを示す最初の兆候です。例えば、統合が期限切れになった、夜間ジョブが停止した、フィードの形状が変更されたのに誰も気づかなかった、といったことが考えられます。
行数カウントルールや前回実行以降の変更ルールは、スケジュールに基づいてそれを検知し、ビジネス用語で報告します。つまり、「今朝4時以降、注文は届いていません」ということです。
ダッシュボードを開かずにKPIをモニタリング
ほとんどのデータ監視ソフトウェアは、ユーザーにデータを確認するように促します。しかし、これはユーザーが関心のある数値が変動するまでは、何も要求しません。
図解：4つのKPIがそれぞれ1つずつ結び付けられている。交差しているものだけが意味を持つ。
KPIとは、クエリが返す単なる数値です。粗利益率、コンバージョン率、在庫日数、未出荷注文の最古の経過日数、今月の解約率など、SQLで表現できるものであれば、制限を設定してルールに渡すことができます。最初に定義するための別のメトリックレイヤーも、監視を開始する前に構築する必要のあるダッシュボードもありません。
境界と頻度を選択します:毎晩、毎時間、毎週、または 5分ごとに数値が規定値を超えると、設定した厳格度に応じて、選択したチャネルを通じてルールが通知します。数値が元に戻ると、復旧通知でその旨が通知されます。
これがこのツールの真髄です。これはBIツールではありませんし、既存のダッシュボードを置き換えるものでもありません。あくまでも、ダッシュボードを見るように促すレイヤーなのです。ほとんどのデータ監視ツールは、ユーザーがアクセスしなければならない場所に設置されていますが、これはユーザーが直接アクセスできるものです。
保存されたクエリが到達できる場合、ルールはそれを監視できます。
アラートやレポートは、データソースが何であるかを独自に認識しません。ルールは保存されたクエリを指し、そのクエリはプラットフォーム上の他のすべてのクエリと同じコネクタパスを通ります。そのため、ルールはソースリストの一部ではなく、ソースリスト全体を継承します。
それは 11 データベース（SQL Server、PostgreSQL、MySQL、MariaDB、Oracle、Snowflake、BigQuery、SQLite、Access、DuckDB）に加えて 8 APIコネクタ：Stripe、HubSpot、Shopify、Google Analytics 4、Google Ads、Search Console、ShipStation、iTick。 53 情報源はどれも等しく注目に値する。Stripeの決済失敗、Shopifyの在庫水準、GA4のトラフィック崩壊、iTickの銘柄価格などだ。
また、この機能はコネクタ層を再実装するのではなく、それを借用しているため、 後から追加するコネクタは出荷当日から機能します アラートの更新も、有効化も何も必要ありません。
実際的な結論。 弊社がサポート対象として用意したメニューから選択する必要は一切ありません。お客様が業務環境に合わせてクエリを作成すれば、ルールはそのクエリに従います。
自動レポート作成のための3つのステップ
新しいクエリ言語を学ぶ必要はありません。ルールは、既に信頼している保存済みのクエリ（SQL、コネクタ、フィルタ）を借用します。
保存済みのクエリを指定してください。
開く 自動化 → アラートとレポート そして、クエリビルダーライブラリからクエリを選択します。ルールはそのクエリ、コネクタ、フィルタを再利用するため、何も書き直す必要はありません。
アラートまたはレポートを選択してください
アラートは、異常状態がどのようなものかを把握する必要があります。例えば、維持すべきレベル（上回るか下回るか）、行数、前回実行時との変更点などです。一方、レポートに必要なのはスケジュールだけで、条件はオプションです。
受信方法を選択してください
どのプランでもアプリ内の通知ベルに届き、プランの規模に応じて、メール、Slack、Google Chat、Discord、Telegram、署名付きWebhookなど、7つのチャネルから任意の組み合わせで通知が配信されます。重要度を設定し、数値データのみを送信するか、Novaによるナレーションを送信するかを選択できます。
何を見ればいいか分からない？そんな時はNovaに聞いてみよう。
ほとんどの人は、どのクエリをレポート対象とするかを知る前に、レポートが必要だと認識しています。そこで、2つ目の方法があります。対象となるコネクタを選択することです。選択ツールには、どのデータベースが既にスキーマインテリジェンスに対応しているかが表示されます。あとは、Novaにルールを提案させます。
Novaはあなたの 実際のスキーマそして、重要な部分を実行します。探索的な読み取り専用クエリを実行して、データが実際に存在し、正しく入力されていることを確認します。その後、テーブル名と列名に基づいて、具体的なアラートとレポートを提案します。テーブル名から推測するのではなく、まず確認を行います。
Novaが何かを提案する前にすること
- スキーマを読み込みます。 現状のテーブル、列、型。スキーマインテリジェンスが実行された箇所については、情報が付加されています。
- 探索的クエリを実行します。 他のすべてのデータと同様に、同じバリデーターを介してライブデータに対する読み取り専用プローブを実行します。
セレクト,と,説明する. - データが正しく入力されていることを確認します。 存在するが内容が空の列は、無意味なアラートを生成します。Novaは、ユーザーよりも先にそのことを検出します。
- 規則を提案する。 テーブルに関する具体的なアラートとレポートが作成され、条件、スケジュール、重要度があらかじめ入力されています。あとは、承認するか編集するかを選択できます。
Novaはビジネスプラン以上のプランに含まれており、使用量に応じた料金体系となっています。毎月一定量のNovaクレジットが付与され、その後は従量課金となります。
データアラートが届く可能性のある7つの場所
すべてのルールはまずポータルのアプリ内ベルに表示され、規模拡大に伴い、ビジネスで既に利用しているツールへと自動的に展開されます。1つのルールを、必要な数のツールに同時に適用することも可能です。
スラック
不和
Googleチャット
電報
アプリ内通知はポータル上部のベルアイコンに表示され、レポート通知をクリックするとその実行が開きます。各実行には固有のパーマリンクが保持されるため、転送する代わりにページを同僚に渡すことができます。メールは受信者ごとに送信され、受信者ごとに追跡されるため、ルールによって実際に誰がメールを閲覧したかを確認できます。
Slackアラート、Discordアラート、Google Chat、Telegramはそれぞれ、最小公倍数的なメッセージではなく、そのプラットフォーム向けに作成されたメッセージを受け取ります。Discordの配信は実際のDiscord埋め込みであり、各ペイロードは許可されたメンションを明示的に設定するため、ルールによって誤って午前3時にサーバー全体に通知されることはありません。Google Chatは追加します 安定したスレッド処理同じルールに関する通知が繰り返し送信される場合、毎回新しいスレッドが開始されるのではなく、1つのスレッドにまとめられます。これはGoogle Chat特有の利点であり、SlackやDiscordのWebhookでは実現できません。
Webhookには署名が付いているため、受信者はそれに基づいて行動する前に、配信が本当に当社から送信されたものであることを確認できます。また、送信先は当社が呼び出す前に検証されます。
あるいは、ノヴァにレポートを書かせてもいいでしょう。
ナレーションをオンにすると、レポートは表形式からブリーフィング形式に変わります。Novaは実際の実行結果を読み取り、何が起こっているのかを英語で簡潔にまとめます。まるで記者が担当分野を取材するように、売上、在庫、あるいは指定した対象など、あらゆる情報を網羅します。
そして、クエリは境界ではなく、種となるものです。 ストーリーに必要な情報が、行データだけでは得られない場合（例えば、移動テーブルからのアイテムごとのレート、カテゴリ別の今週の比較、実際に移動したアイテムなど）、Nova がそれらの情報を探し出します。Nova はスキーマの要約を読み込み、同じ接続に対して読み取り専用のフォローアップクエリを独自に作成し、その後にサマリーを出力します。クエリの実行回数はユーザーが決定できます。簡単な確認には 1 回、詳細な分析には最大 5 回まで設定可能です。
これは、そもそもルールを構築するのを支援するNovaとは異なる役割です。Novaはルールが存在する前にルールを設計しますが、こちらはルールの実行結果を繰り返し分析し、ストーリーの必要に応じてその結果に関する調査を行います。
数字は床であり、床は決して動かない。 数値、行、系列は最初に組み立てられ、必ず送信されます。ナレーションはその上に付加されます。何らかの理由でナレーションが失敗した場合でも、数値はそのままの状態でレポートが送信されます。配信が遅延したり、停止したりすることはありません。
Novaは各実行結果を前の実行結果と比較するため、変更点は数値ではなく文章として表示されます。自分で差分を計算する必要はありません。また、表示方法はルールに基づいて設定できます。文章による説明が必要なレポートもあれば、数値だけを一目で確認したいレポートもあります。どちらも有効であり、ユーザーが選択できます。
ルールの深さを設定できます。最大5ラウンドまで設定可能で、各ラウンドで最大2つの読み取り専用クエリを実行し、ダンプではなく集計と上位N件を要求します。Novaは、スレッドがもはやその役割を果たさなくなった時点で早期に停止し、シードが既にストーリーを語っている場合は探索を完全にスキップします。ナレーションはビジネスプラン以上で利用可能で、使用量ベースです。月額Novaクレジットが含まれ、その後は従量課金となります。
データは、データが保存されている場所に留まります。
スケジュール設定の有無にかかわらず、ルールはプラットフォーム上の他のすべてのクエリと同様に実行されます。
発信専用ネットワークエージェント
エージェントは暗号化された送信接続を1つ開き、リクエストを転送します。 そして 双方向で効果を発揮します。受信ポートもVPNもファイアウォールの変更も不要で、認証情報がネットワークから外部に漏れることもありません。
読み取り専用、検証済み
他のすべてのクエリを保護するのと同じバリデーターが、これらも保護します。 セレクト, と そして 説明する 通過できません。スケジュールされたルールはデータベースに書き込むことができません。
役割による制限を設計上設けている
ルールの管理は、組織の作成者、管理者、クエリ管理者のみに限定されています。なぜなら、データをメールで送信するルールは、設定ではなく権限だからです。
代理人を通じて連絡が取れました。 SQL Server · PostgreSQL · MySQL · MariaDB · Oracle · Snowflake · BigQuery · SQLite · Access · DuckDB · Stripe · HubSpot · Shopify · Google Analytics 4 · Search Console · ShipStation · iTick
自動レポートに関するよくある質問
アラートとレポートの違いは何ですか？
アラートは、スケジュールに基づいてクエリの結果と条件を照合し、条件が満たされなくなった場合にのみ通知します。アラートにはライフサイクルがあり、トリガーされるとインシデントはオープン状態になり、クリアされると復旧通知が届きます。レポートはスケジュールに基づいて毎回実行され、結果をチャネルに投稿します。インシデントのライフサイクルはありません。レポートにも条件を関連付けることはできますが、その場合は送信フィルターとして機能します。レポートに条件が含まれている場合にのみ送信されます。
毎週月曜日の朝にSlackで売上レポートを受け取ることはできますか？
はい、それはレポートルールです。営業クエリを指定し、週単位のスケジュールを設定し、チャネルとしてSlackにチェックを入れます。複数の担当者が異なる場所でレポートを確認する場合は、メール、Discord、Google Chat、Telegramも併せて追加できます。プランに関係なく、すべてのルールはアプリ内のベルに通知され、規模を拡大するとチャットチャネルも利用できるようになります（ビジネスプランではSlack自体が利用可能になります）。月曜日まで待たずに悪い日についても知りたい場合は、同じクエリに対してしきい値を設定したアラートとして2つ目のルールを追加してください。
レポートをスケジュールするために、新しいSQL文を書く必要がありますか？
いいえ。ルールは、クエリビルダーに既に保存されているクエリを参照し、そのクエリ（SQL、コネクタ、フィルタ）を再利用します。ルール専用の言語を覚える必要はなく、ルールがクエリを書き換えることもありません。まだクエリを作成していない場合は、クエリビルダーで作成するか、Novaにスキーマを読み込ませてクエリとルールの両方を提案させてください。
定期レポートはどのようにして私のチームに届きますか？
ルールごとに最大 7 つのチャンネルを自由に組み合わせることができます。ポータルのトップバーにあるアプリ内ベルはすべてのプランに搭載されています。メール (受信者ごとに配信および追跡されるため、誰がメールを読んだかを確認できます)、チャットチャンネル (Slack、Google Chat、Discord、Telegram)、署名付きウェブフックは、プランの規模に応じて追加され、ビジネスプランではすべての機能が利用できます。PDF や添付ファイルはありません。レポートはメッセージ自体であり、チームが普段使用している場所に投稿されます。各実行では、ポータル内のその実行への永続的なリンクも保持されるため、コピーを転送する代わりにページを相手に渡すことができます。
生の数値データが得られるのですか、それとも読みやすい形式で得られるのですか？
ルールに従ってどちらでも構いません。クエリが返した行と系列である数値は常に最初に構築され、常に送信されます。さらに、Novaナレーションを有効にすると、実行結果を読み上げ、何が起こっているかを簡潔な英語の要約として作成します。以前の実行結果と比較することで、変更点が自分で差分を計算する必要のある数値ではなく、文章として表示されます。ナレーションが失敗した場合でも、レポートは数値とともに送信されます。遅延やブロックは一切発生しません。ナレーションはビジネスプラン以上で含まれており、使用量ベースです。月額Novaクレジット、その後は従量課金制となります。
しきい値アラートは実際に何をチェックできるのでしょうか？
追跡値のしきい値、行数チェック、前回実行時との変化など、すべてクエリが返す結果に対して評価されます。したがって、数値は収益、在庫レベル、価格、失敗した支払いの数、またはその他の何でも構いません。 セレクト 生成可能です。各ルールには、重大、警告、情報という重要度が設定されており、通知の表示頻度を決定します。これは、クエリ結果のビジネスデータを監視するツールであり、サーバーの健全性やインフラストラクチャを監視するツールではありません。
どの情報源が有効で、誰がルールを設定できるのか？
すべてです。ルールは保存されたクエリを監視し、保存されたクエリは、 11 データベース（SQL Server、PostgreSQL、MySQL、MariaDB、Oracle、Snowflake、BigQuery、SQLite、Access、DuckDBなど）または 8 APIコネクタ：Stripe、HubSpot、Shopify、Google Analytics 4、Google Ads、Search Console、ShipStation、iTick。アラートは独自のコネクタパスではなく共有コネクタパスを使用するため、将来の作業で追加されるコネクタはリリース当日に追加されます。ルールの管理は、組織の作成者、管理者、クエリマネージャーにロールゲートされています。 自動化 → アラートとレポート.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish