Skip to main content
POST
Analyze the flow impact of error flavours

Authorizations

Authorization
string
header
required

Use an Observe API key from the management console. The key selects the project and must grant the permission listed on the operation. Keep this key on your server.

Body

application/json
flavourIDs
string[]
required

Flavour IDs to analyze together (format erf-<number>), e.g. an error's member flavours.

Required array length: 1 - 1000 elements
fromDate
string
required

Range start, naive UTC datetime (inclusive).

Example:

"2026-08-01T00:00:00"

toDate
string
required

Range end, naive UTC datetime (exclusive).

Example:

"2026-08-08T00:00:00"

flowLimit
integer

Maximum number of flows to analyze PER GROUP (affected and baseline). Both groups are read as raw flow rows, so this is what bounds the analysis; a group that hits the limit is marked sampled and describes the most recent flowLimit flows of that group. Defaults to 5000. High values buy completeness (fewer sampled groups, so per-user tallies see a user's whole history in range) at the cost of a slower analysis.

Required range: 1 <= x <= 50000
Example:

5000

baselineFlowListID
string

Optional stored ID list (format idl-<number>, from POST /observe/idLists or a previous analysis) to use verbatim as the baseline group instead of building one. The listed flows are read as raw rows (capped at flowLimit, most recent first) and compared against the affected group with the usual device-mix standardization; matching is ignored when this is set.

matching
object

Baseline modeling configuration. When present, the baseline is not "all engaged flows of the affected flow types" but a stratified sample matched to the affected group on the requested dimensions — controlling for WHERE in the flow the error happened (pathPrefix) and for the population mix, so the completion comparison isolates the error instead of the route that leads to it. The response's matchingReport describes the strata, the achieved balance, and every fallback taken.

errorID
string

The curated error whose impact is being analyzed (format err-<number>). When set, the flavourIDs must be exactly the error's current member flavours, and the analysis result is stored on the error as its last-known impact (served as lastImpact in the errors list). Omit for ad-hoc flavour analyses, which are never stored.

Response

Impact analysis for the given flavours and range.

affected
object
required
occurrenceCount
integer<int64>
required

Occurrences of the given flavours on real-user flows in range.

orphanOccurrenceCount
integer<int64>
required

Occurrences in range without an attached flow (inferred / never attached); excluded from all rates.

baseline
object
completionLift
number<double>

affected.completionRate minus baseline.completionRate (percentage points as a fraction, negative = affected flows complete less). Absent when either side has no completion rate.

occurrencesPerFlowAvg
number<double>

Average occurrences per affected flow (occurrenceCount / affected.flowCount). Absent when no flows are affected.

affectedUserCount
integer<int64>

Distinct users among affected flows (flows without a user reference contribute none). Absent when no flows are affected.

repeatUserCount
integer<int64>

Distinct users who hit the analyzed flavours MORE THAN ONCE in range, i.e. at least two occurrences — whether spread over several flows or fired twice within one flow. Subset of affectedUserCount; flows without a user reference contribute none. Absent when no flows are affected. Computed over the analyzed flows, so on a sampled affected group it is a lower bound (a user's earlier flows may fall outside the sample).

repeatUserOccurrenceCount
integer<int64>

Occurrences on the repeat users' flows — how much of occurrenceCount is concentrated on users who keep hitting this.

repeatUserFlowCount
integer<int64>

Affected flows belonging to the repeat users, i.e. the size of the cohort behind repeatUserFlowListID.

repeatUserFlowListID
string

Handle of a stored ID list (format idl-<number>) holding the affected flows of the repeat users, for opening exactly those high-impact users in user search. Empty when no user hit the flavours more than once.

userExposure
object[]

The distribution behind repeatUserCount: the affected users grouped into occurrence bands (1, 2, 3-4, 5-9, 10+), ascending, empty bands omitted. Every band above the first is made of repeat users, so their user counts sum to repeatUserCount and all bands together to affectedUserCount. Same sampling caveat as repeatUserCount — on a sampled affected group users shift toward the lower bands.

unattributedFlows
object
terminalIncompleteFlowCount
integer<int64>

Incomplete affected flows whose last occurrence of the analyzed flavours fell within 10 seconds of the flow's end - the error was (close to) the last thing that happened. Absent when no flows are affected.

analyzedFlowLimit
integer<int64>

The per-group flow cap the analysis ran with (the request's flowLimit, or the default). Together with each group's sampled flag it tells a caller whether raising the limit would change the numbers.

matchingReport
object

How the baseline group was modeled and how well it mirrors the affected group. Present when the request asked for matching or supplied baselineFlowListID; absent on a plain (unmatched) analysis.

perFlowType
object[]

The completion comparison split per flow type of the affected group, biggest affected slice first. The group-level completionLift is a weighted mean over these; when the per-type lifts diverge (different sign, or a large spread), the blended number hides differently-hurt flow types and a caller should present this cut instead. Empty when no flows are affected.

Maximum array length: 1000
subflowCompletion
object

How the ERRORING SUBFLOW itself ended on both sides — did this step succeed, as opposed to completionLift's did the whole flow succeed (possibly via a fallback). The affected side measures the segment the analyzed flavours fired on (falling back to the flow's first segment of the subflow's code when embedding does not locate it); the baseline side the first segment of the same code, so flows that never attempted the subflow are excluded. Flow-type-agnostic by construction: a passkey-login attempt is the same unit in a login and in a signup flow, so this comparison stays clean when the affected group mixes flow types. Absent when the analyzed flavours span several subflow types or none resolves to a known code.