For the complete documentation index, see llms.txt. This page is also available as Markdown.

Data flow and trace spine

The trace spine: five streams, one trace ID, and where your data lives.

Everything the platform does travels five streams, in order, and every record on every stream carries the same trace ID. That spine is the whole trick: it is what lets a click, the decision it triggered, and the deal that closed be joined end to end.

The trace spine: events to outcomes, joined by a shared trace ID
  1. Events: raw happenings arrive, page views, form fills, CRM changes, channel activity.

  2. Identity: each event is resolved to a real person and account, retroactively when needed.

  3. Signals: resolved events become scored signals, the inputs to FIRE and to decisions.

  4. Decisions: the system chooses, and writes its reasoning before acting.

  5. Outcomes: what happened comes back and attaches to the decision that caused it.

The forward leg plans and activates; the return leg measures and attributes. Nothing on the return leg is self-reported by a channel: outcomes join on the trace ID, not on a platform's claims.

In and out

Data enters through your connected sources: the pixel, your CRM, your warehouse, enrichment. It leaves as activations into your channels and, where configured, as syncs back to your warehouse. Consent and suppression flags travel with records the whole way, so an exclusion upstream is an exclusion everywhere downstream.

Where it lives

Managed by the platform by default, with your workspace isolated end to end. Enterprise deployments run the data plane against your own warehouse (Snowflake, BigQuery, Databricks, or Redshift), so the streams live where your data already does; our team sets up the connection with you.

Last updated