Reading the numbers

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. The three rules, in the words the dashboard uses:

0 and — are different facts. A dash means not measured. A 0 means we read the answers and the count was zero.
Every rate carries its n. A percentage never appears without the number of answers behind it.
“Nothing we can prove yet” is what a change says when the sample cannot tell it apart from noise.

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.

{ "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.

Where is n in the dashboard?

Beside the rate. The analytics screens print the count with every rate they show:

Where	How the rate is written
Prompts grid, each rate cell	The percentage, with the count under it: `25%` over `1 of 4 answers`. Below 20 answers the count ends in `· thin`.
Prompts grid, share of voice	The same, counted in brand mentions rather than answers: `40%` over `2 of 5 mentions`.
Prompts grid, `n` column	The answers read for that prompt in the window.
Prompts grid, group headers	`n = 12 prompts`, then each rate as `31% of 214 answers`, or `not read` when nothing in the group was read.
Overview headline	The percentage from 20 answers up, and below 20 the count instead: `3 of 12`. Either way `n=… answers` sits beside it.

Below 20 answers a percentage claims a precision the sample does not have. “0 of 4” says everything “0%” says, and carries its own evidence, which is why the Overview switches to the count and the grid marks the count thin. The 20-answer line is a display rule, not a statistical test; the significance test for changes is described below.

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.

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.

How does the dashboard show a zero and a dash?

On every screen, an unmeasured value is an em dash (—) and a measured zero is a 0 or 0%. On the Overview, hover a dash, or the n beside the headline figure, and the dashboard says:

A dash means not measured: no answer was read for it. A 0 means we read the answers and the count was zero.

In the prompts grid a dash is never bare. Each one carries the reason it is a dash, on hover and for screen readers. The reason tells you which gap you are looking at, because the remedies differ:

Reason on the dash	What it means
not read in this window	The prompt is tracked on this model, and no reading was taken in the window you are looking at.
every read in this window failed	Readings were attempted and every one failed. The commonest failure reason follows it when there is one.
no answers came back in this window	Readings exist but carry no answers at all.
this prompt is not read on this engine	Other prompts are read on this model; this one is not.
Intent is not classified yet.	The prompt has no intent label yet. This is a missing attribute, not a measurement.

The prompts grid applies the same rule to standing: ○ Absent means we read the answers and nobody you track was named, and — Not measured means there was nothing to read. See where you stand on a prompt. The CSV exports from the prompts, pages, sources and competitors grids keep the distinction too. Each file states, in its header, that an empty value is not measured and a 0 is a measured zero. Every rate column has an _n column beside it, so you can tell which of the two an empty cell is.

Why does a change say “real”?

A change is {value, real}.

{ "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 yet”, not “no movement” and not “zero”. It is the honest answer to a question the sample cannot yet settle.

Where does “nothing we can prove yet” appear?

Wherever a change would otherwise be stated:

The Overview’s trend sentence. It always includes n, and ends either “a real change” or “nothing we can prove yet”. For example: “Named in 31% of answers, up from 26% (n=1,840), a real change.” or “Named in 31% of answers (n=214), nothing we can prove yet.” A change that clears the significance test is still “nothing we can prove yet” when fewer than 70% of the window’s days were read, and the sentence says how many were, for example “read on 4 of 28 days”. Two thin samples weeks apart are not a trend. When nothing was read at all, it says “No answers were read in this window yet (n=0), so there is nothing we can prove yet.”
The prompts grid’s Trend column. A prompt’s movement is shown in points (+6 pts) only when it cleared the test. Otherwise the cell reads not proven, and its hover says: “No change this sample can prove against the window before — nothing we can prove yet.”
Re-reads after a change ships. Where a screen sums up a change’s re-reads in one word, such as the Overview’s “What did we do, and did it work?” block, the No change and Too close to call verdicts both read “Nothing we can prove yet”: two different findings, the same honest sentence. On the Overview, a change with too few answers from before it to compare against reads the same, and so does one that moved up on some prompts and down on as many others. See Before and after for the full verdicts.

None of these say why a number moved. A real change means the number moved by more than the noise. It does not mean a particular piece of work moved it.

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 explains sampling depth, and Plans shows which depth each plan runs at.

Why was a finding held as noise?

The hourly detection pass applies the same idea to what it files in your Inbox. A rule that fires on three quiet days is not yet proof that anything changed, so before a finding is filed its last three days are compared with the seven before them, on successful reads only.

Significant at p < 0.01 on Fisher’s exact test: it is filed. That bar is stricter than the 95% test above, because a filed finding asks for your attention.
Not significant: a decision reads the same counts, day by day, and judges whether the change is real or noise. It reads numbers only.
Held as noise: the decision was confident the change is not real. The finding is not filed and starts no run, and it is checked again an hour later on fresh readings.

Each hold is recorded with its n: the successful reads, across both windows, it was judged on. As everywhere else, n is the first thing to read. A held finding at an n of 12 is a handful of answers that wandered. A dip of the same size at an n of 300 is far more likely to clear the test, and a change that clears it is filed without a question.

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 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.

A dash, a zero, and an empty list

The same rule holds for everything that is not a rate:

What you see	What it means
— (`null` on the wire)	Not measured, or not known. Nothing was read, or the reading that would answer it has not happened yet
0	Measured, and the count or rate was zero
An empty list (`[]`)	Looked, and found none

A dash never stands alone. Wherever the product shows one, it says why on hover or in place: “not read in this window”, “not scored yet”, “recorded before we kept the full brand order”. A dash without a reason asks you to guess which of several very different gaps it was. Lists follow the same split. An answer’s brand order is null until the answer has been read for it and [] once it has been read and named no brand. A link’s context is null when we never looked and "" when we looked and the answer’s text does not mention the link. A stance is unscored when nobody has read the answer for it and none when it was read and takes no position. In each pair, only the second is a reading.

Gaps

A table that is missing rows is not the same as a table whose rows are zero. So when query_evidence answers a question it cannot fully measure, it lists every hole as a gap: a key saying where the hole is, and a reason saying why.

"gaps": [
  { "key": "2026-08-01..2026-08-09", "reason": "before_first_reading" },
  { "key": "engine=gemini", "reason": "no_readings" }
]

The key is a source (search_console), a run of days (2026-08-01..2026-08-09), one day (day:2026-08-04), or one row’s key (engine=gemini). Consecutive missing days are one gap, not one per day. The reasons include days before your first tracked prompt, a source that is not connected, days not recorded yet, a value not read yet, and a day that was cut short. An empty gaps list is the claim that nothing is missing. Read the gaps before you read the rows. A 0 next to a gap is not a measurement of that gap.

Truncated days and truncated tables

Two different things can be cut short, and both are said.

A truncated day. Where a source keeps only the top rows of a day, as Search Console’s detail by search query does, that day’s numbers for a single query are a floor, not a total. The day carries a truncated_day gap. A page’s own totals are not affected: they are stored whole, not added up from the queries.
A truncated table. When an answer has more rows than its limit, truncated is true and the rows are the strongest, or the newest days or weeks when grouped by time. A count shown from a truncated read is “at least N”, never N.

Reading these over MCP

The shapes are identical through the MCP server — 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.

What do the verdicts on a shipped change mean?

The analytics overview and a prompt’s changes timeline judge each shipped change in one of four words: Moved up, Moved down, Nothing we can prove yet and Too early. None of them says the change caused the movement. The verdict words gives each one’s meaning, the text shown on hover, and how a change’s re-reads decide which word it gets.

Get started

What you track