Prodantix
概要
- カテゴリー
- 開発者向けプラットフォーム
- ウェブサイト
- prodantix.com
- コンソール
- app.prodantix.com
- ドキュメント
- prodantix.com/en/docs/overview
- GraphQL API
- api.prodantix.com/graphql
- イベント受信
- eu.api.prodantix.com/v1/events
- リアルタイム
- eu.ws.prodantix.com
- MCP インターフェース
- eu.mcp.prodantix.com/mcp
- セッションリプレイ
- eu.replay.prodantix.com
Prodantix は、ソフトウェアをつくる人のための道具です。どの製品チームも、同じ三つの問いを繰り返しています。人は自分たちのアプリの中で実際に何をしているのか、どの部分を誰に見せるべきか、そして何かを伝えるならいつが適切なのか。
多くの会社は、この三つの仕事にそれぞれ別の道具を買います。やっかいごとはそこから始まります。道具ごとに利用者の記録を別々に持つため、その記録は少しずつずれていきます。ある道具は、この顧客はもう初期設定を終えたと考えています。別の道具は追いついておらず、先週すでに済ませた手順の案内を送ってしまう。本人から苦情が来るか、二つの画面が違う数字を示すまで、誰も気づきません。
エンジンの成り立ち
エンジンは四つの基本要素からできており、その他はすべてこの上に築かれています。順番に見ていくのが分かりやすく、それぞれが次の要素へとつながっています。コンセプトのリファレンスで詳しく解説しています。
イベント
利用者が行ったひとつのこと。起きたその瞬間に記録されます。登録の完了、ページを開いたこと、途中でやめたフォームなど。イベントは生の信号であり、外部からシステムに入ってくる唯一のものです。ほかはすべてここから導かれます。
ユーザー状態
ある利用者について分かっていることすべてを、ライブかつ問い合わせ可能な形にした射影です。その人のイベントから導かれ、新しいイベントが届いた瞬間に更新されます。分析、フィーチャーフラグ、メッセージングはいずれもこの同じ真実の源を読みます。夜間の集計でもなければ、何かのジョブが同期を保つ複製でもありません。存在するのはひとつだけです。
判定
ユーザー状態に対して評価される規則です。誰がある集団に属するか、誰にフラグを渡すか、誰がメッセージの条件を満たすか。判定は問われたその瞬間のライブな状態を読むため、古くなった像から答えることはありません。
アクション
判定が成立したときにエンジンが行うことです。機能を開く、メッセージを送る、ワークフローを開始する。アクション自体もイベントとして記録され、それがループを閉じます。エンジンが行ったことが、エンジンの知ることの一部になるのです。
分析とは状態を読むこと
Prodantix の分析は、利用者の複製を自前で抱える別の保管庫ではありません。ユーザー状態を直接読むことです。ファネル、リテンション、コホートは、エンジンの他の部分が作用するのと同じライブな射影に対する問い合わせです。ですからデータウェアハウスへの SQL の往復も、夜間集計の待ち時間もありません。状態はすでに問いの形に整っています。コホートはここでは第一級の対象です。名前を持ち、条件節で定義され、人が条件を満たしたり外れたりするのに合わせて所属が更新され続けます。
人によって見せるものを変える
チームは新しいものを、まず一部の利用者にだけ出して様子を見てから全員に広げたい、と考えることがよくあります。Prodantix は、ユーザー状態に対して条件を評価して誰に何を見せるかを決めます。属性、演算子、値の組み合わせを、保存済みの名簿を引くのではなく、フラグが問われたその瞬間に判定します。新しい機能を顧客の二パーセントにだけ渡し、使われ方を見てから、次のリリースを待たずに広げることも取り下げることもできます。
まだ役に立つうちに届くお知らせ
お知らせは、まだ役に立つあいだに届いてこそ意味があります。Prodantix は、その人が何かをした瞬間、あるいはできなかった瞬間に送ることができます。契約の上限に達した顧客は、その場で気づけます。あきらめて他所に移った翌朝ではありません。
AI オーケストレーションと、ループが閉じる仕組み
これまでの各面では、段取りをつなぐ作業は依然として利用者側に残ります。何かに気づき、それが誰に当てはまるかを見極め、どうするかを決める、という流れです。Prodantix はこのループ自体を回せます。エンジンはライブな状態から意味のある瞬間を検出し、該当するコホートを選び、アクションを決めます。ふつうの自動化と違うのは最後の部分です。アクションはイベントとして記録され、次の判定が読むのと同じユーザー状態へ折り返されます。システム自身のふるまいが、その人について知っていることの一部になるのであって、傍らで起きた出来事にとどまりません。
イベントを送り込む
すべては受信エンドポイントに送られたイベントから始まり、エンジンはそれを直ちにユーザー状態へ折り込みます。SDK はウェブ、モバイル、サーバーをカバーします。React だけは例外で、そのライフサイクルには専用アダプターが必要です。クライアントを一度だけ設置する provider と hook で、StrictMode にも耐えます。クイックスタートなら数行で接続できます。
キーと環境
SDK の呼び出しはいずれもプロジェクトキーを伴い、キーはコンソールで発行します。プロジェクトを作ると live と test の二つの環境ができ、それぞれに専用のキーが付きます。開発は test、本番は live です。どちらのキーも作成直後に一度だけ表示されます。サーバーはハッシュしか保持しないため、後からどの画面にも出せません。ローテーションでは選んだ環境の代替キーを発行し、古いキーを即座に止めるか猶予期間を置くかは利用者が決めます。
対話するための四つの経路
REST は三つのホストにまたがります。フラグとメッセージング用、イベント受信用、セッションリプレイ用で、それぞれが /openapi.json に自前の OpenAPI ドキュメントを提供します。受信は 202 を返しますが、これは処理のために受け付けたという意味であって保存された意味ではありません。不正なイベントは後段で破棄されることがあります。GraphQL はプロジェクト、フラグ、ワークフロー、分析、メッセージング、コホート、課金を含むアプリケーションモデル全体を扱います。リアルタイム面はフラグの変更、メッセージ、ワークフローの実行を配信し、認証されていない接続は即座に切断します。MCP 面はエージェントがツール呼び出しで読み書きするためのもので、機械間専用でブラウザからの要求は拒否します。
データはあなたのものであり続けます
Prodantix は当社のサーバーでも、お客さま自身のサーバーでも動かせます。どちらでも中身は同じです。預けたものは、いつでもそっくりそのまま取り出せます。データを売ることはありませんし、AIモデルの学習に使うこともありません。仕組み上、Prodantix はお客さまが持つどの記録よりも完全な顧客の記録を抱えることになります。だからこの約束は、ほかの場所より重い意味を持ちます。
対象となる方
Prodantix が向いているのは、この目的で二つ三つの道具を別々に動かしていて、それらが食い違うことにうんざりしているチームです。顧客が増えて、周りに聞いて回るだけでは何が起きているか追えなくなった頃から、いちばん効いてきます。
サイトを見る Prodantix: prodantix.com