Clearvane Get in touch

Messaging on product data

Product events and customer messages, kept in one system.

Clearvane records what people do in your product and sends the in-app messages, chat replies and triggered flows that follow. Both are written to the same log, so a message can be traced to what happened after it.

For product and growth teams in mid-market SaaS and e-commerce

Get in touch See how it works

timeline · person u_8123live

One person, one ordered timeline of product events and messages
TimeWritten byRecord
09:12:04productexport.limit_reached
09:12:05segmententered hit_limit_twice
09:12:09clearvanemessage.sent · in‑app
09:13:41productbilling.viewed
09:15:02productplan.upgraded
09:15:02clearvaneattributed · window 24h

The two amber rows are ours. They are ordinary rows in the same table as the rest, which is the whole idea.

01 The usual setup

Four tools hold four halves of the same story.

Most teams we talk to run customer communication across three or four products. Analytics holds the events. An email tool holds the campaigns. An in-app tool holds the banners and tooltips. Support chat holds the conversations. Each one is a reasonable choice on its own.

The trouble is at the seams. The messaging tool knows a person received a message; it has no idea they opened the billing page nine minutes later. Analytics knows about the billing page and has no record of the message. Putting the two together means exporting from both, matching on an identifier that is spelled differently in each, and rebuilding by hand a timeline that both systems had and neither kept.

So the answer to did that campaign do anything arrives as a one-off reconstruction. It takes two days, someone does it once, and nobody repeats it for the next campaign. In the meantime the definitions drift: analytics computes active_14d one way, and the messaging tool, syncing overnight, computes it another. Two numbers, one meeting, no decision.

We think the join should not have to exist. Events and messages are the same kind of record, and they belong in the same place, in order.

02 Product

Four parts, and they share one store.

01

Events

Send events over HTTP, or from the SDKs, from wherever you already track them: a signup, a failed payment, a page that took nine seconds to render. Each event carries a person, a name, a timestamp and whatever properties you attach. We keep them at full fidelity — nothing is rolled up into daily counts after thirty days, because a message you send in week six needs the week-one timeline intact.

POST /v1/events
{
  "person": "u_8123",
  "name":   "export.limit_reached",
  "at":     "2026-03-11T09:12:04Z",
  "props":  { "plan": "team", "count": 2 }
}

02

Segments

A segment is a query over that log, not a list rebuilt overnight. Hit the export limit twice this week and hasn't opened billing is evaluated when it is asked for, so membership changes the moment the event lands, and a message waiting on that segment goes out without waiting for an overnight sync. Nothing drifts out of step with your analytics, because it is the same data.

03

Flows

A flow is a small graph: wait for an event, check a condition, send or hold. Every branch is written down, so there is no send order to reconstruct from a list of campaigns. Editing a live flow creates a new version and the people already inside it finish on the one they started, which means you can fix step four on a Tuesday without stranding anyone halfway.

04

Attribution

Because a sent message is an event like any other, did it do anything is an ordinary query. Pick the message, pick the outcome, pick a window. You get the people who received it and did the thing, the people who received it and did not, and — the part that usually goes missing — the holdout that never received it at all. Holdouts are on by default at 5% of the audience and reported separately, so the comparison is there before anyone asks for it.

03 Architecture

One pipeline, from event to outcome.

Events arrive over HTTP or from the SDKs and land in an append-only log partitioned by person. Segments read that log directly. Flows subscribe to segment transitions and to raw events. Delivery writes back into the same log — which is why attribution is a query and not an export.

  1. 01

    Ingest

    HTTP and SDKs. Batched or one at a time, ordered per person on arrival.

  2. 02

    Log

    Append-only, columnar, partitioned by person and by day. Full fidelity, no roll-ups.

  3. 03

    Segments

    Queries over the log, evaluated on demand. Membership changes as events land.

  4. 04

    Flows

    Versioned graphs subscribed to events and to segment transitions.

  5. 05

    Delivery

    In-app, chat and email. Every send is written back as an event.

  6. 06

    Attribution

    Message, outcome, window, holdout. A query over the same log.

Four tables, and that is the whole model

person    id · traits · first_seen · region
event     person_id · name · at · props
message   person_id · flow_id · version · channel · at
outcome   person_id · event_name · within · holdout

04 Security

Where the data sits, and who can read it.

Storage region

You choose where the log lives when the workspace is created, the United States or the European Union. It stays there. Nothing is replicated across the boundary, including backups.

In transit and at rest

TLS on every connection, including the SDKs. Volumes and backups are encrypted at rest, and the keys are rotated on a schedule rather than on an incident.

Deletion

A delete request removes the person and their events from the log itself, not only from the index. It completes within thirty days and you get a written confirmation with the count.

Who can read it

Our engineers cannot read message content by default. Access is granted for one ticket, expires on its own, and is written to an audit log you can export.

05 Who it's for

Past the spreadsheet, short of the data team.

Clearvane suits a company past the point where one person keeps all the messaging in their head, and short of the point where an in-house data team would rather build this themselves. In practice that is mid-market SaaS and e-commerce: enough people using the product that a careless send is expensive, enough surface that behavior is worth reacting to, and a growth team that wants to change the copy without opening a ticket with engineering.

Below a few thousand users, an email tool and a spreadsheet will do, and we will say so on the call. If you already run an event pipeline your analysts own, we usually work better as somewhere those events also land than as a replacement for it.

06 Company

Clearvane

A US company, about fifty people, distributed across a dozen time zones with no head office and no plans for one. Most of us worked on messaging systems or on data infrastructure before this, on both the sending and the receiving end of them.

We have customers, we have revenue, and we grow at the rate we can hire for. This year we are expanding the engineering team on the ingestion and query side.

If you want to see the product, or you have a question a page like this cannot answer, write to us. You will get a person.

adam@clearvane.pro