Prodantix

Prodantix is made for the people who build software. Every product team keeps asking the same three questions: what are people actually doing inside our app, who should be allowed to see which parts of it, and when is the right moment to say something to them.

Most companies buy a different tool for each of those jobs, and that is where the trouble starts. Each tool keeps its own separate record of who your users are, and those records slowly drift apart. One tool thinks a customer has finished setting up her account. Another has not caught up, so it emails her instructions for a step she completed last week. Nobody spots it until she complains, or until two dashboards start showing different numbers.

How the engine is put together

Four primitives make up the engine, and everything else is built on them. They are worth taking in order, because each one feeds the next. The concepts reference covers them in full.

Event

A single thing a user did, captured as it happens: a sign-up completed, a page opened, a form abandoned halfway. Events are the raw signal, and they are the only thing entered into the system from outside. Everything else is derived from them.

User state

A live, queryable projection of everything known about a user, derived from their events and updated the moment a new one arrives. This is the source of truth that analytics, feature flags and messaging all read. It is not a nightly rollup, and it is not a copy that some job keeps in step. There is one of it.

Decision

A rule evaluated against user state: who belongs to a cohort, who gets a flag, who qualifies for a message. Because a decision reads live state at the moment it is asked, it cannot be answering from a stale picture.

Action

What the engine does when a decision fires: expose a feature, send a message, start a workflow. An action is itself recorded as an event, which is what lets the loop close: what the engine did becomes part of what it knows.

Analytics is reading the state

Analytics in Prodantix is not a separate store holding its own copy of your users. It is reading user state directly. Funnels, retention and cohorts are queries over the same live projection the rest of the engine acts on, so there is no SQL round trip to a warehouse and no waiting for a nightly rollup: the state is already shaped for the question. Cohorts here are first-class objects: named, defined by clauses, with membership kept current as people qualify and stop qualifying.

Saving a question you will ask again

A dashboard is a named set of tiles, and a tile is a query you already ran plus how you want it drawn. The query is stored exactly as the explorer submitted it, so a tile holds the question and not a picture of its answer: opening one runs the query again and drops you back into the explorer at that same query, free to move the window or change the breakdown. A dashboard is therefore never a stale export. It is a set of questions the engine answers from live state each time you look.

When a number moves on its own

Nobody watches every chart. Prodantix does the watching part: it reads a series bucket by bucket, works out the baseline and the spread of that series, and flags the buckets that sit too far from it, in either direction. A drop and a spike are both reported, each with the baseline it departed from and how far out it sat, so you can tell a genuine break from ordinary noise. The sensitivity is a setting rather than a fixed rule, and the detector declines to guess: a series that is nearly flat, or too short to have a shape yet, produces nothing at all rather than a false alarm.

The people the state is about

User state is a projection, and the people directory is where you read it one person at a time. The console lists everyone the project has seen, most recently active first, with a search box and a list that keeps loading as you go. A row carries what the engine has accumulated for that person: how many events, how many distinct sessions, when they were first and last seen, what they last did, which groups they belong to, and the reserved traits (name, email, telephone, avatar) pulled out into their own columns. Opening a row shows the full property table, which holds whatever your events have put there rather than a fixed set of fields. Groups have their own tab and their own properties, because a company or a workspace is a thing in its own right and its facts belong to it rather than to each of its members.

One person, several ids

A visitor arrives before you know who they are. The SDK gives them an id, they read three pages, and only then do they sign up. Until someone tells the engine who they are the profile simply has no name on it, and the directory says so rather than guessing. When the signup does happen, the ids are linked into a chain that resolves to one canonical identity, so the anonymous trail folds into the named account instead of starting a second profile. Every row shows how many ids resolve to it and the profile lists them. Where the engine cannot tell on its own, you can join two profiles by hand: you choose which identity survives, its properties win any collision, and the counts add up. That one does not come apart again. The profile as it read before the merge is kept in the audit trail, so what it said is recoverable, but the two people are not separable once joined.

Watching one session back

Analytics tells you that eleven people abandoned the same form yesterday. It cannot tell you why. Session replay records the page itself: the browser SDK captures the document and every change to it while the person works, gathers those changes into ordered chunks and uploads them to the recorder, and the console plays the session back as it happened. Every recording is filed under the same distinct id the rest of the engine uses, so a session belongs to a person you can already look up, not to a visitor id that exists only inside a separate tool.

What a recording is allowed to keep

Masking is on before you configure anything. Every character typed into a field is replaced with an asterisk in the browser, before the chunk is uploaded, so what reaches the recorder never held the content: length and word boundaries survive, which keeps the replay looking like the page, and the words themselves are gone. Password, email and telephone fields are redacted whether masking is on or off, so turning it off cannot expose a credential field. Visible page text is kept unless you ask for that to be masked too. Every chunk records whether it was masked and the console marks the session accordingly, so you always know which of the two you are watching. The recordings sit in private storage: the console asks for a short-lived signed link one chunk at a time, and nothing is reachable without one. How long a session stays available after that is set by your plan.

Showing different things to different people

Teams often want to release something new to a handful of users first and see how it goes before everyone gets it. Prodantix decides who sees what by evaluating conditions against user state: an attribute, an operator and a value, checked at the moment the flag is asked rather than looked up in a stored list. You can give a new feature to two percent of customers, watch how they use it, then widen it or withdraw it without waiting for another release.

Messages that arrive while they still help

A message is only worth sending while it still helps. Prodantix can send one the moment a person does something, or fails to. If a customer reaches the limit of their plan, they hear about it there and then, rather than the next morning after they have already given up and gone elsewhere.

When they write back

Messaging goes one way until somebody replies, and then it is a support thread. Prodantix carries those too, and the AI inside them drafts rather than sends. The model is given the thread and that person’s own state, nothing else: not another customer’s conversation, not the rest of your project. It writes a suggested reply, and the reply becomes a turn in the thread only when your agent presses send, so “suggest, not send” is how the code is built rather than a rule somebody has to remember. The thread carries its own credential as well. A project key identifies a project and travels inside every page that installs the SDK, so it cannot stand for a person; each conversation gets its own token, scoped to that one thread, and the id in a request body never decides who you are talking to. Opening a conversation is the single route that needs nothing but the public key, so it is rate limited per project and per caller.

Wiring a sequence yourself

Some responses are more than one step, and you want to lay them out yourself. A workflow is a small graph: it starts manually, or when somebody enters or leaves a cohort, and from there it moves through nodes. An action node does something (write a log line, call a webhook of yours). A delay node waits, up to thirty days. A wait node holds until a named signal arrives, with its own exit if the signal never comes. A branch node tests conditions against user state and takes the matching path, or the fallback. Runs advance one node at a time, and each step is committed before the next is claimed, so a restart resumes where the run had actually reached rather than replaying it from the top. Webhooks are checked before they are called: the target has to be a public https address, the addresses the check approved are the ones the request goes to, redirects are not followed, and a call that hangs is cut off.

AI orchestration, and how the loop closes

The surfaces above still leave you wiring the steps: notice something, work out who it applies to, decide what to do about it. Prodantix can run that loop itself. The engine detects the meaningful moment in live state, selects the cohort it applies to, and chooses the action. What makes this more than ordinary automation is the last part: the action is recorded as an event, so it folds back into the same user state the next decision reads. The system’s own behaviour becomes part of what it knows about that person, rather than something that happened to them off to one side.

A proposal waits for a person

The engine does not act on its own conclusion. What it produces is a proposal, and a proposal is a written plan: these flags, these cohorts, this message. Before it can be approved, every flag, cohort and conversation it names is resolved against your own tenant, and a reference that does not resolve fails the whole proposal rather than being quietly dropped, which is what keeps a model that has read something hostile from reaching past your project. Approval is a human action, and it is the point at which anything happens: execution runs through the same flag and messaging paths you use by hand, so the permissions, the audit trail and the limits on your plan all still apply. Approving twice does nothing the second time.

Getting events in

Everything starts with an event sent to the ingest endpoint, which the engine folds into user state immediately. SDKs cover web, mobile and server. React is the one exception: its lifecycle needs a dedicated adapter, a provider and hook that install the client once and are StrictMode-safe. The quickstart wires it up in a few lines.

Keys and environments

Every SDK call carries a project key, which comes from the console. Creating a project produces two environments, live and test, each with its own key: build against test, ship with live. Both keys are shown exactly once, right after creation, because the server stores only a hash and no screen can reproduce them later. Rotation mints a replacement for the environment you pick, and you choose whether the old key stops working immediately or after a grace period.

Four ways to talk to it

REST spans three hosts, one for flags and messaging, one for event ingestion and one for session replay, each serving its own OpenAPI document at /openapi.json. Ingestion answers 202, which means the event was accepted for processing rather than stored: a malformed event can still be dropped further down the pipeline. GraphQL covers the full application model, including projects, flags, workflows, analytics, messaging, cohorts and billing. The realtime surface broadcasts flag changes, messages and workflow runs, and drops unauthenticated connections immediately. The MCP surface lets AI agents read and write through tool calls; it is machine to machine and refuses browser requests.

The data stays yours

You can run Prodantix on our servers or on your own, and it works the same either way. Everything you put into it, you can take out again in full, whenever you want. We do not sell your data and we do not use it to train AI models. By design Prodantix ends up holding the most complete record of your customers that you have anywhere, so that promise carries more weight here than it would elsewhere.

Who it is for

Prodantix suits teams who are running two or three separate tools for this and are tired of them disagreeing. It is most useful once you have enough customers that you can no longer keep track of what they are doing by asking around.

Visit Prodantix: prodantix.com