> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useboom.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Analytics and attribution
> Define what success means for an initiative, then measure against it.
Boom does not decide what a good outcome is for you. You define it, per
initiative, and everything else is measured against that definition: a rate, a
value, a funnel, and the list of individual conversations that counted.
Success metrics and the analytics views are configured and read in the Boom
app. They are not on the REST API or MCP today. The raw material behind them
is: [extracted values](/extraction), transcripts and participant records all
come back over the API, so you can compute your own numbers if you would
rather.
## Defining success
An initiative can carry more than one named success metric. Each one says what
signal counts as success, and how to aggregate it.
Three kinds of signal:
| Signal | Counts success when | Use it for |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| A **CDP event** | A named event lands for that person inside the attribution window. The value can come from a property on the event, or from an object the event points at, such as the total on the order it references. | A signup, a payment, a booking, an order. |
| A **CDP object** | An object reached from the person exists, dated inside the window by one of its own attributes rather than by when Boom saw it. | An order, a subscription, an application. |
| An **extracted variable** | The conversation produced a value for a field in your [extraction schema](/extraction). | Outcomes that only exist because someone said them, like agreeing to come back. |
Each metric aggregates as a **count**, a **sum**, an **average** or a **max**, so
"how many came back" and "how much revenue came back" are the same mechanism with
a different aggregation.
### The attribution window
A conversation's window opens when Boom sends its first outbound message and
closes 48 hours after the journey ends. That grace period is fixed and not
configurable today, so a purchase two weeks later is not attributed, by design.
A person Boom never messaged has no window at all, and is excluded from both the
numerator and the denominator rather than counted as a failure.
## What you get
**Per node**, from the messages themselves with nothing to configure: sent,
delivered, read and replied counts, how each branch split, and median wait times.
Useful for finding the step where people fall out.
**A funnel** that starts at Sent rather than at enrolled, with each stage showing
its share of the previous stage and of the first, ending in a shared succeeded
stage.
**A success rate** whose denominator is the people Boom actually messaged, not
everyone who entered. Worth knowing before comparing it to a number from another
tool, which may well count differently.
**Successes over time**, bucketed by day, switchable between count and value when
the metric aggregates a value.
**The evidence behind the number**: the individual successes that matched, each
linking to that participant and to the run that produced it. This is the part
people ask for when they do not believe the dashboard.
Metrics are recomputed on read against the current definition, and editing a
definition creates a new version rather than pinning history. So changing what
counts as success also changes what past periods show. Decide the definition
before you need to defend a number with it.
## Reading the raw data instead
Everything the dashboard builds on is available over the API and MCP, covered in
[extraction](/extraction):
* the aggregate summary for an initiative, with coverage and distributions per field
* each participant's extracted values, including the quote the value came from and a confidence
* full transcripts, in batches, so you can pull every conversation without looping one at a time
* the step by step run timeline for a participant, when you need to know what the engine did rather than what was said
CSV and XLSX exports live in the app, including one row per participant with one
column per extracted field.
## What this is not
There is no experiment primitive: no randomized allocation, no significance
testing. You can compare variants by branching a journey on an attribute and
reading each path's success metric, which answers most questions, but the split
is deterministic and the statistics are yours to do.
There are also no outbound webhooks and no warehouse sync. Reads are polling.
## Related
The typed fields a conversation yields, and the read paths behind these numbers.
The flow whose nodes these per step metrics describe.
Record the events a success metric can watch for.
The mission a success metric belongs to.