Observe Data Model for the API and Exports

The API and the exports use the same model as the management console. Events from your integration are classified into flows, and each flow contains the subflows a user went through. This page describes how that model appears as tables. For the events you send, see the custom events reference.

​

1. How the model fits together

​

2. Exported tables

Table exports contain 40 tables. They fall into five groups: ob_flow already includes the client environment fields of each flow, so most journey analysis starts there and joins subflows by flow ID. ob_time_series_data holds pre-calculated KPI data. Both this table and ob_time_series_experiment_data export a rolling calendar month ending at the export cutoff, so successive snapshots overlap. For reports that match the console, use time-series exports with the same interval, dimensions and filters. Recalculate from flows and subflows for questions the series do not cover.

​

3. Types, keys and identifiers

• IDs: unsigned 64-bit integers. Preserve the full unsigned range. If your platform only supports signed 64-bit integers, use a lossless decimal or string representation and apply it consistently to join keys.
• Timestamps: UTC with microsecond precision.
• JSON columns: exported as strings. Parse them in your platform where needed.
• Nullable columns: exported as nullable fields.
• Joins: flows reference their session, subflows reference their flow and events map to flows through ob_event_flow.
• Row grain: environment enrichment can produce multiple exported rows for the same flow. Count distinct flow IDs for journey totals and reduce environment rows to the required grain before joining subflows.
• User identifiers: stored as sent by your integration. See pseudonymous identifiers.

​

4. Time columns

Each table is exported by its own time column. Subflows use their start time, flows their creation time and events their event time. A journey that starts shortly before midnight can therefore have rows in two export dates. Join across the relevant export dates rather than assuming all related rows share one date. A one-day lookback can cover a midnight boundary, but is not a completeness guarantee for late events or reclassification. Tags and user references also have their own export time columns, which can use server ingestion time.

​

5. Re-classification and snapshots

Observe classifies a session a few minutes after its last event and classifies it again when later events arrive, for example when a user returns to the same session. An exported day is a snapshot of that day at export time. Classification changes after the export are not reflected in files that were already written. Agree the historical regeneration and reload process when your warehouse must reflect these corrections; downloading an unchanged snapshot again does not refresh its contents.

​

6. Schema changes

The export schema follows the data model and grows as Observe adds fields. Configure your loader to accept new columns rather than failing on them, and write transformations that select the columns they need instead of relying on column order.