Skip to main content
Every measurement system has edges. This page is the honest account of ours: how detection actually works, where noise lives, and what we cannot tell you. Read it before you make a decision on an Attensira number, and read it again before you present one to someone else.

How a mention is actually detected

A mention is a case-insensitive substring match of your brand name or your domain against the text of a model’s answer. That is the whole method. There is no entity resolution, no disambiguation against a knowledge graph, and no word-boundary check. The consequence is concrete. A brand called Notion matches the word “notional”. A brand called Arc matches “architecture”, “march”, and “search”. A brand whose name is a common noun will show a mention rate that is partly noise, and no amount of averaging removes it, because the error is systematic rather than random. Everything built on mentions inherits this. Your mention rate inherits it. Every competitor rate you compare against inherits it. If a competitor’s name is a common word and yours is not, the comparison is unfair in their favour, and vice versa. We store the verbatim answer text for every successful run precisely because of this. The stored answer is the evidence: you can read what the model actually said, and detection can be re-run over the same history when the method improves, without losing the past.
If your brand name is a common English word, check a handful of stored answers before trusting your rate. Two minutes of reading tells you whether your number is measuring your brand or the dictionary.

Models are not deterministic

Ask the same model the same prompt twice and you can get two different answers. Ask it an hour later and you can get a third. This is a property of the models, not a fault in our collection. Sampling is the response. We put a prompt to a model more than once per reading where your plan allows it — n=1 on Starter, n=3 on Growth and Business — so that a rate is computed from several draws rather than one. Gating deltas is the second response: a change has to clear a statistical bar before we will call it a change at all.

Why a small sample shows “no proven change”

Every delta is tested with a two-proportion z-test at 95% significance. If the movement does not clear that bar, you get {real: false, value: null} — which means we cannot prove a change, and never means the change was zero. At n=1, this will be the common outcome. One draw per prompt per model per day is a thin sample, so most week-to-week wobble sits under the noise floor and is reported as no proven change. That is the system working: it is refusing to sell you a story that the data does not support. If you need movements confirmed faster, sampling depth is the lever — n=3 gives three draws per reading. See Plans.

null is not zero, and small n is not a rate

Two shapes carry the numbers. A rate is {value, n}. A delta is {value, real}.
  • value: null means not measured. Nothing was observed, so nothing can be reported.
  • value: 0 with n > 0 means measured zero. Runs happened; none named you.
These are different facts and they must not be collapsed into one chart line. A dashboard that draws null as zero is telling you a model rejected you when in truth it was never asked. Small n deserves the same care. A rate of 33% at n=3 is one hit out of three draws; a single different answer moves it to 0% or 67%. Look at n before you quote the percentage, and prefer wider windows over single days.

Models with no reader are unmeasured, not zero

Per-model metrics carry tracked and readable.
  • tracked: false — this model is not configured for your workspace, so it was never queried. Rendering that as 0% invents a failure that did not happen.
  • readable: false — no reader exists for that surface, so we cannot collect it at all.
Not every model surface has an API reader. google_ai, in particular, has no API reader. A new workspace starts with two model surfaces tracked by default, not five — so if you see three models with nothing in them, the likely explanation is that they were never turned on. See Models.

Competitor rates do not sum to 100%

Competitor rates use the same denominator as yours: successful runs where that competitor was named, over all successful runs in the window. They are independent rates, not slices of a pie. One answer can name you and three competitors, so four rates each rise from the same run. Adding them up produces a number that can exceed 100% and means nothing. There is no share-of-voice metric in Attensira that divides a fixed total between brands.
A field named ShareOfVoice appears in some responses. It is the brand’s own mention rate — the same number, under an older name. It is not a share of anything.

Citation position is not a rank of your brand

AvgPosition is the mean index of a URL within the model’s own citation list, computed per source domain. It answers “when this domain is cited, how far down the list does it sit”. It is not a leaderboard position, not a ranking of your brand against competitors, and not comparable to a search engine result position. There is also no visibility score and no sentiment metric in Attensira. “Visibility” appears as a label on a section of the product and as a value in the get_analytics area enum; it is not a computed metric, and nothing in the system scores whether an answer spoke about you kindly.

What we cannot attribute

We measure two things: what models answer, and which pages AI crawlers fetch. We do not measure what happened next. Attensira cannot tell you that a mention produced a visit, that a citation produced a signup, or that any of it produced revenue. There is no identity join between an answer a model gave someone and a person who later arrived at your site. Anyone claiming that link for this class of product is inferring it, not observing it. Treat these numbers as a measure of presence in AI answers. Connect them to commercial outcomes with your own analytics and your own judgement, and say out loud that you are doing so.

Freshness: today is always partial

Work is enqueued on an hourly ticker, but each prompt × model × country combination runs at most once per workspace-local calendar day. Today’s numbers are therefore incomplete until the day closes, and the shape of that incompleteness is not uniform — some prompts will have run, others not. Failed runs are stored but excluded from n, so a day with collection problems produces a smaller sample rather than a distorted rate. Compare whole days against whole days. A “drop” measured at eleven in the morning is usually just the morning. For how to read a number once you have it, see Reading the numbers. For specific symptoms, see Troubleshooting.