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.

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.

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.

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