Skip to main content
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.

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

Why does a change say “real”?

A change is {value, real}.
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.
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.

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.

Reading these over MCP

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