Prodantix

Prodantix ist für Menschen gemacht, die Software bauen. Jedes Produktteam stellt dieselben drei Fragen: Was tun die Leute in unserer App wirklich, wer sollte welchen Teil davon sehen dürfen, und wann ist der richtige Moment, ihnen etwas zu sagen.

Die meisten Unternehmen kaufen für jede dieser Aufgaben ein anderes Werkzeug, und genau da fangen die Probleme an. Jedes Werkzeug führt seine eigene getrennte Aufzeichnung darüber, wer Ihre Nutzer sind, und diese Aufzeichnungen driften langsam auseinander. Das eine glaubt, eine Kundin habe die Einrichtung ihres Kontos abgeschlossen. Das andere hinkt hinterher und schickt ihr eine Anleitung für einen Schritt, den sie vergangene Woche erledigt hat. Niemand bemerkt es, bis sie sich beschwert oder zwei Dashboards unterschiedliche Zahlen zeigen.

Wie die Engine aufgebaut ist

Vier Grundbausteine bilden die Engine, alles Weitere setzt darauf auf. Es lohnt sich, sie der Reihe nach zu betrachten, denn jeder speist den nächsten. Die Konzeptreferenz behandelt sie vollständig.

Ereignis

Eine einzelne Handlung eines Nutzers, erfasst in dem Moment, in dem sie geschieht: eine abgeschlossene Anmeldung, eine geöffnete Seite, ein auf halbem Weg abgebrochenes Formular. Ereignisse sind das Rohsignal und das Einzige, was von außen ins System gelangt. Alles Weitere wird daraus abgeleitet.

Nutzerzustand

Eine lebende, abfragbare Projektion von allem, was über einen Nutzer bekannt ist, abgeleitet aus seinen Ereignissen und aktualisiert in dem Moment, in dem ein neues eintrifft. Das ist die Quelle der Wahrheit, aus der Analyse, Feature-Flags und Messaging lesen. Sie ist keine nächtliche Aggregation und keine Kopie, die irgendein Job im Gleichlauf hält. Es gibt genau eine.

Entscheidung

Eine Regel, die gegen den Nutzerzustand ausgewertet wird: wer zu einer Kohorte gehört, wer ein Flag bekommt, wer für eine Nachricht infrage kommt. Da eine Entscheidung den Live-Zustand in dem Moment liest, in dem sie gestellt wird, kann sie nicht aus einem veralteten Bild antworten.

Aktion

Was die Engine tut, wenn eine Entscheidung greift: eine Funktion freischalten, eine Nachricht senden, einen Workflow starten. Eine Aktion wird selbst als Ereignis erfasst, und genau das schließt den Kreis: Was die Engine getan hat, wird Teil dessen, was sie weiß.

Analyse heißt, den Zustand lesen

Analyse ist in Prodantix kein separater Speicher mit einer eigenen Kopie Ihrer Nutzer. Sie ist das direkte Lesen des Nutzerzustands. Funnel, Retention und Kohorten sind Abfragen auf derselben lebenden Projektion, auf der auch der Rest der Engine arbeitet. Es gibt also keinen SQL-Umweg über ein Warehouse und kein Warten auf eine nächtliche Aggregation: Der Zustand hat bereits die Form der Frage. Kohorten sind hier eigenständige Objekte: benannt, über Klauseln definiert, mit einer Mitgliedschaft, die aktuell bleibt, während Leute die Bedingung erfüllen oder nicht mehr erfüllen.

Eine Frage aufheben, die Sie erneut stellen werden

Ein Dashboard ist eine benannte Menge von Kacheln, und eine Kachel ist eine Abfrage, die Sie bereits ausgeführt haben, samt der Art, wie sie gezeichnet werden soll. Die Abfrage wird genau so gespeichert, wie der Explorer sie abgeschickt hat, eine Kachel hält also die Frage und kein Bild ihrer Antwort: Öffnen Sie eine, läuft die Abfrage erneut und setzt Sie im Explorer wieder auf genau diese Abfrage, frei darin, das Zeitfenster zu verschieben oder die Aufschlüsselung zu ändern. Ein Dashboard ist damit nie ein veralteter Export. Es ist eine Menge von Fragen, die die Engine bei jedem Hinsehen aus dem lebenden Zustand beantwortet.

Wenn eine Zahl sich von selbst bewegt

Niemand behält jedes Diagramm im Blick. Das Beobachten übernimmt Prodantix: Es liest eine Reihe Abschnitt für Abschnitt, ermittelt die Grundlinie und die Streuung dieser Reihe und markiert die Abschnitte, die zu weit davon entfernt liegen, in beide Richtungen. Ein Einbruch und ein Ausschlag werden beide gemeldet, jeweils mit der Grundlinie, von der sie abwichen, und dem Abstand, den sie hatten, sodass Sie einen echten Bruch von gewöhnlichem Rauschen unterscheiden. Die Empfindlichkeit ist eine Einstellung und keine feste Regel, und der Detektor rät nicht: Eine nahezu flache Reihe oder eine, die noch zu kurz ist, um überhaupt eine Form zu haben, liefert lieber gar nichts als einen Fehlalarm.

Die Menschen, von denen der Zustand handelt

Der Nutzerzustand ist eine Projektion, und das Personenverzeichnis ist der Ort, an dem Sie ihn Person für Person lesen. Die Konsole listet alle auf, die das Projekt gesehen hat, die zuletzt Aktiven zuerst, mit einem Suchfeld und einer Liste, die beim Weiterblättern nachlädt. Jede Zeile trägt, was die Engine über diese Person angesammelt hat: wie viele Ereignisse, wie viele verschiedene Sitzungen, wann sie zuerst und zuletzt gesehen wurde, was sie zuletzt getan hat, zu welchen Gruppen sie gehört, dazu die reservierten Merkmale (Name, E-Mail, Telefon, Avatar) in eigenen Spalten. Das Öffnen einer Zeile zeigt die vollständige Eigenschaftstabelle, in der steht, was Ihre Ereignisse dort abgelegt haben, und nicht ein fester Satz von Feldern. Gruppen haben einen eigenen Reiter und eigene Eigenschaften, denn ein Unternehmen oder ein Arbeitsbereich ist eine Sache für sich, und seine Fakten gehören ihm und nicht jedem einzelnen Mitglied.

Eine Person, mehrere Kennungen

Eine Besucherin kommt an, bevor Sie wissen, wer sie ist. Das SDK gibt ihr eine Kennung, sie liest drei Seiten, und erst danach meldet sie sich an. Solange niemand der Engine sagt, wer sie ist, trägt das Profil schlicht keinen Namen, und das Verzeichnis sagt das, statt zu raten. Wenn die Anmeldung dann geschieht, werden die Kennungen zu einer Kette verbunden, die auf eine einzige kanonische Identität hinausläuft, sodass die anonyme Spur in das benannte Konto einklappt, statt ein zweites Profil zu eröffnen. Jede Zeile zeigt, wie viele Kennungen auf sie hinauslaufen, und das Profil zählt sie auf. Wo die Engine es allein nicht entscheiden kann, können Sie zwei Profile von Hand zusammenführen: Sie wählen, welche Identität bestehen bleibt, ihre Eigenschaften gewinnen jeden Konflikt, und die Zähler addieren sich. Das geht nicht wieder auseinander. Das Profil so, wie es vor der Zusammenführung lautete, bleibt in der Prüfspur, sein Inhalt ist also wiederherstellbar, die beiden Personen sind nach dem Zusammenführen aber nicht mehr trennbar.

Eine Sitzung noch einmal ansehen

Die Analytik sagt Ihnen, dass gestern elf Personen dasselbe Formular abgebrochen haben. Warum, sagt sie nicht. Die Sitzungsaufzeichnung nimmt die Seite selbst auf: Das Browser-SDK erfasst das Dokument und jede Änderung daran, während die Person arbeitet, bündelt diese Änderungen zu geordneten Teilstücken und lädt sie zum Rekorder hoch, und die Konsole spielt die Sitzung so ab, wie sie stattgefunden hat. Jede Aufzeichnung liegt unter derselben Kennung, die auch der Rest der Engine verwendet. Eine Sitzung gehört damit zu einer Person, die Sie ohnehin nachschlagen können, und nicht zu einer Besucher-ID, die es nur in einem separaten Werkzeug gibt.

Was eine Aufzeichnung behalten darf

Die Maskierung ist aktiv, bevor Sie irgendetwas einstellen. Jedes in ein Feld getippte Zeichen wird noch im Browser durch ein Sternchen ersetzt, bevor das Teilstück hochgeladen wird. Was beim Rekorder ankommt, hat den Inhalt also nie enthalten: Länge und Wortgrenzen bleiben erhalten, wodurch die Wiedergabe weiterhin wie die Seite aussieht, und die Wörter selbst sind fort. Passwort-, E-Mail- und Telefonfelder werden geschwärzt, ob die Maskierung an oder aus ist. Sie abzuschalten kann ein Anmeldefeld also nicht offenlegen. Sichtbarer Seitentext bleibt erhalten, sofern Sie nicht auch dafür Maskierung verlangen. Jedes Teilstück hält fest, ob es maskiert war, und die Konsole kennzeichnet die Sitzung entsprechend, sodass Sie stets wissen, welche der beiden Sie ansehen. Die Aufzeichnungen liegen in privatem Speicher: Die Konsole fordert einen kurzlebigen signierten Link für jeweils ein Teilstück an, und ohne ihn ist nichts erreichbar. Wie lange eine Sitzung danach verfügbar bleibt, bestimmt Ihr Tarif.

Verschiedenen Leuten Verschiedenes zeigen

Teams wollen Neues oft zuerst einer Handvoll Nutzer geben und sehen, wie es läuft, bevor es alle bekommen. Prodantix entscheidet, wer was sieht, indem es Bedingungen gegen den Nutzerzustand auswertet: ein Attribut, ein Operator und ein Wert, geprüft in dem Moment, in dem das Flag abgefragt wird, statt in einer gespeicherten Liste nachgeschlagen. Sie können eine neue Funktion zwei Prozent der Kundschaft geben, beobachten, wie sie damit umgeht, und sie dann ausweiten oder zurückziehen, ohne auf ein weiteres Release zu warten.

Nachrichten, die ankommen, solange sie noch helfen

Eine Nachricht lohnt sich nur, solange sie noch hilft. Prodantix kann sie in dem Moment senden, in dem jemand etwas tut oder eben nicht tut. Erreicht eine Kundin die Grenze ihres Tarifs, erfährt sie es sofort und nicht am nächsten Morgen, wenn sie längst aufgegeben hat und woanders ist.

Wenn sie zurückschreiben

Nachrichten laufen in eine Richtung, bis jemand antwortet, und dann ist es ein Support-Verlauf. Prodantix trägt auch diese, und die KI darin entwirft, statt zu senden. Dem Modell werden nur der Verlauf und der eigene Zustand dieser Person gegeben, sonst nichts: nicht die Unterhaltung einer anderen Kundin, nicht der Rest Ihres Projekts. Es schreibt eine vorgeschlagene Antwort, und die Antwort wird erst dann ein Beitrag im Verlauf, wenn Ihre Mitarbeiterin auf Senden drückt. „Vorschlagen, nicht senden“ ist damit die Bauweise des Codes und keine Regel, an die sich jemand erinnern müsste. Der Verlauf trägt außerdem seine eigenen Zugangsdaten. Ein Projektschlüssel weist ein Projekt aus und reist in jeder Seite mit, die das SDK einbindet, er kann also nicht für eine Person stehen. Jede Unterhaltung bekommt ihr eigenes Token, das nur für diesen einen Verlauf gilt, und die Kennung in einem Anfragekörper entscheidet nie, mit wem Sie sprechen. Eine Unterhaltung zu eröffnen ist der einzige Weg, der nichts außer dem öffentlichen Schlüssel braucht, und ist deshalb pro Projekt und pro Aufrufer begrenzt.

Eine Abfolge selbst verdrahten

Manche Reaktionen bestehen aus mehr als einem Schritt, und Sie wollen sie selbst auslegen. Ein Workflow ist ein kleiner Graph: Er startet von Hand oder wenn jemand eine Kohorte betritt oder verlässt, und läuft von dort durch Knoten. Ein Aktionsknoten tut etwas (eine Logzeile schreiben, einen Ihrer Webhooks aufrufen). Ein Verzögerungsknoten wartet, bis zu dreißig Tage. Ein Warteknoten hält an, bis ein benanntes Signal eintrifft, mit einem eigenen Ausgang, falls das Signal ausbleibt. Ein Verzweigungsknoten prüft Bedingungen gegen den Nutzerzustand und nimmt den passenden Pfad oder den Ausweichpfad. Läufe rücken einen Knoten nach dem anderen vor, und jeder Schritt wird festgeschrieben, bevor der nächste beansprucht wird, sodass ein Neustart dort weitermacht, wo der Lauf tatsächlich angekommen war, statt ihn von vorn abzuspielen. Webhooks werden vor dem Aufruf geprüft: Das Ziel muss eine öffentliche https-Adresse sein, die Anfrage geht an genau die Adressen, die die Prüfung freigegeben hat, Weiterleitungen werden nicht verfolgt, und ein hängender Aufruf wird abgebrochen.

KI-Orchestrierung, und wie sich der Kreis schließt

Die Oberflächen oben überlassen Ihnen weiterhin das Verdrahten der Schritte: etwas bemerken, herausfinden, für wen es gilt, entscheiden, was zu tun ist. Prodantix kann diese Schleife selbst fahren. Die Engine erkennt den entscheidenden Moment im Live-Zustand, wählt die betroffene Kohorte und bestimmt die Aktion. Mehr als gewöhnliche Automatisierung wird das durch den letzten Teil: Die Aktion wird als Ereignis erfasst und fällt damit in denselben Nutzerzustand zurück, den die nächste Entscheidung liest. Das eigene Verhalten des Systems wird Teil dessen, was es über diese Person weiß, statt etwas, das ihr nebenher zugestoßen ist.

Ein Vorschlag wartet auf einen Menschen

Die Engine handelt nicht auf eigene Faust nach ihrem Schluss. Was sie hervorbringt, ist ein Vorschlag, und ein Vorschlag ist ein aufgeschriebener Plan: diese Flags, diese Kohorten, diese Nachricht. Bevor er genehmigt werden kann, wird jedes Flag, jede Kohorte und jede Unterhaltung, die er nennt, gegen Ihren eigenen Mandanten aufgelöst, und eine Referenz, die sich nicht auflöst, lässt den ganzen Vorschlag scheitern, statt still zu verschwinden. Genau das hindert ein Modell, das etwas Feindseliges gelesen hat, daran, über Ihr Projekt hinauszugreifen. Die Genehmigung ist eine menschliche Handlung, und sie ist der Punkt, an dem überhaupt etwas geschieht: Die Ausführung läuft über dieselben Flag- und Nachrichtenwege, die Sie von Hand benutzen, sodass Berechtigungen, Prüfspur und die Grenzen Ihres Tarifs weiterhin gelten. Zweimal genehmigen bewirkt beim zweiten Mal nichts.

Ereignisse hineinbekommen

Alles beginnt mit einem Ereignis, das an den Ingest-Endpunkt geht und sofort in den Nutzerzustand eingefaltet wird. SDKs decken Web, Mobile und Server ab. React ist die eine Ausnahme: Sein Lebenszyklus braucht einen eigenen Adapter, einen Provider und Hook, die den Client einmal installieren und StrictMode-sicher sind. Der Schnellstart verdrahtet das in wenigen Zeilen.

Schlüssel und Umgebungen

Jeder SDK-Aufruf trägt einen Projektschlüssel, der aus der Konsole stammt. Ein neues Projekt erzeugt zwei Umgebungen, live und test, jede mit eigenem Schlüssel: Sie entwickeln gegen test und liefern mit live aus. Beide Schlüssel werden genau einmal gezeigt, direkt nach der Erstellung, denn der Server speichert nur einen Hash und kein Bildschirm kann sie später wiederholen. Die Rotation stellt für die gewählte Umgebung einen Ersatz aus, und Sie entscheiden, ob der alte Schlüssel sofort oder nach einer Schonfrist ungültig wird.

Vier Wege, mit ihr zu sprechen

REST erstreckt sich über drei Hosts, einen für Flags und Messaging, einen für die Ereigniserfassung und einen für Session-Replay, jeder mit eigenem OpenAPI-Dokument unter /openapi.json. Die Erfassung antwortet mit 202, was heißt, dass das Ereignis zur Verarbeitung angenommen und nicht gespeichert wurde: Ein fehlerhaftes Ereignis kann weiter hinten in der Pipeline immer noch verworfen werden. GraphQL deckt das gesamte Anwendungsmodell ab, einschließlich Projekten, Flags, Workflows, Analyse, Messaging, Kohorten und Abrechnung. Die Echtzeit-Schnittstelle überträgt Flag-Änderungen, Nachrichten und Workflow-Läufe und trennt nicht authentifizierte Verbindungen sofort. Die MCP-Schnittstelle lässt Agenten über Tool-Aufrufe lesen und schreiben; sie ist Maschine zu Maschine und weist Browser-Anfragen ab.

Die Daten bleiben Ihre

Sie können Prodantix auf unseren Servern oder auf Ihren eigenen betreiben, es funktioniert in beiden Fällen gleich. Alles, was Sie hineingeben, können Sie jederzeit vollständig wieder herausholen. Wir verkaufen Ihre Daten nicht und nutzen sie nicht, um KI-Modelle zu trainieren. Konstruktionsbedingt hält Prodantix am Ende die vollständigste Aufzeichnung über Ihre Kundschaft, die Sie irgendwo haben, deshalb wiegt dieses Versprechen hier schwerer als anderswo.

Für wen es gedacht ist

Prodantix passt zu Teams, die dafür zwei oder drei getrennte Werkzeuge betreiben und es leid sind, dass diese sich widersprechen. Am nützlichsten ist es, sobald Sie so viele Kundinnen und Kunden haben, dass Sie nicht mehr durch Herumfragen mitbekommen, was sie tun.

Besuchen Prodantix: prodantix.com