> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reading the numbers

> How to tell a measured zero from an unmeasured cell, why a rate carries a sample count, and when a change is real.

Every number Attensira reports carries the evidence behind it. A rate arrives with the number of observations it was built from, a change arrives with whether it cleared a significance test, and anything we never measured comes back as `null` rather than as a zero. This page explains how to read all three, in the dashboard and over [MCP](/mcp/overview).

## Why is a rate two values instead of one?

A rate is `{value, n}`. `value` is the rate itself, between 0 and 1. `n` is how many successful runs it was built from.

```json theme={null}
{ "value": 0.31, "n": 84 }
```

Read `n` first. A rate of 0.33 built from three runs and a rate of 0.33 built from three hundred are the same number describing very different amounts of evidence. The first will move dramatically on the next reading; the second will not. Small samples move in large steps, and a jump from 0 to 0.33 at `n` of 3 is one answer changing its mind, not a trend.

## What does null mean?

`null` means **not measured**. It never means zero.

| What you see               | What it means                                                 |
| -------------------------- | ------------------------------------------------------------- |
| `{"value": 0.24, "n": 96}` | Measured. You were named in 24% of runs.                      |
| `{"value": 0, "n": 96}`    | Measured. The models were asked 96 times and never named you. |
| `{"value": null, "n": 0}`  | Not measured. Nothing was read in this window.                |

The difference matters because the two failures have opposite remedies. A measured zero is a product problem — the models know your category and do not know you. An unmeasured cell is a configuration or coverage problem, and the number tells you nothing about your visibility at all.

<Warning>
  Never render an unmeasured cell as 0%. Reporting `null` as zero invents a failure that was never observed. The dashboard shows an em dash for these, and the API returns `null` so your own tooling can make the same distinction.
</Warning>

## Why does a change say "real"?

A change is `{value, real}`.

```json theme={null}
{ "value": 0.06, "real": true }
```

`value` is the movement against the immediately preceding window of equal length. `real` says whether that movement cleared a two-proportion z-test at 95% confidence.

When `real` is `false`, `value` is `null`. That is deliberate. Models are not deterministic, and a rate built from a modest sample wanders on its own without anything changing in the world. Rather than draw a line through that noise, Attensira reports no proven change.

So `{"value": null, "real": false}` means **"nothing we can prove"**, not "no movement" and not "zero". It is the honest answer to a question the sample cannot yet settle.

<Note>
  At the Starter sampling depth of one run per prompt per model per day, most movements will not clear the gate. That is the test working, not the product failing. [How we collect data](/measure/how-we-collect-data) explains sampling depth, and [Plans](/account/plans) shows which depth each plan runs at.
</Note>

## What do tracked and readable mean?

Per-model metrics carry two booleans that both look like a failure and are not.

**`tracked: false`** — this model is not configured for this workspace, so it was never asked. There is no visibility number because no question was put to it. Reporting it as 0% would invent a failure. Add the model in [Models](/tracking/models) if you want it measured.

**`readable: false`** — no reader exists for that surface, so it cannot produce a reading at all. This is a property of the model, not of your workspace or your plan, and adding the model will not change it.

Both are different again from `{"value": 0, "n": 40}`, which means the model *was* asked forty times and did not name you. Only the last of the three is a result.

## What is the unit behind every rate?

A **run**: one prompt, sent to one model, for one country, at one moment. Not a reading, not an answer, not an occurrence of your name.

Every rate on the site flattens all the runs in the window into a single pool and divides. A prompt read for thirty days at a sampling depth of three contributes ninety runs to that pool, weighted the same as any other ninety. Runs that failed are stored for debugging but excluded from `n`, so a model outage shrinks your sample rather than depressing your rate.

## Reading these over MCP

The shapes are identical through the [MCP server](/mcp/overview) — `get_analytics` returns the same `{value, n}` and `{value, real}` objects, and the same `tracked` and `readable` flags per model.

If you are building on top of the API, carry the distinction through rather than flattening it. Coercing `null` to `0` at the edge of your system is the single most common way an accurate measurement becomes a wrong report.