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

# Troubleshooting

> Answers to the questions people ask when an Attensira number looks wrong or missing.

Most surprising numbers in Attensira have an ordinary explanation. This page covers the five that come up most, in the order people usually hit them.

## Why is my mention rate zero?

Check first whether it is a measured zero or an unmeasured null. A measured zero has `n > 0`: runs completed and none named your brand. A null has no runs behind it and means nothing was collected. They look similar on a chart and mean opposite things.

If it is a measured zero, the models genuinely are not naming you for those prompts. That is a real finding, and usually the most useful one you will get in your first weeks. Look at which prompts produced it: broad category prompts ("best project management tool") behave very differently from prompts that already contain your name.

If it is a genuine zero but you expect otherwise, read a few stored answers. The verbatim answer text is kept for every successful run, and it will show you whether the model named competitors instead, refused the question, or answered something adjacent to what you meant to ask.

Also confirm your brand name and domain are entered as models would write them. Detection is a plain substring match, so a brand recorded with punctuation or a trailing suffix that models never use will match nothing. [Limitations](/reference/limitations) explains exactly how the match works.

## Why did my number not change?

Because the change did not clear the significance gate. Every delta runs a two-proportion z-test at 95%. If the movement sits under the noise floor, you get `{real: false, value: null}` — "no change we can prove". That is not a bug and it is not a zero; it is the system declining to report noise as signal.

This is most common at n=1, the sampling depth on Starter. One draw per prompt per model per day is a thin sample, and models are not deterministic, so ordinary run-to-run variation swamps small real movements. Widening the comparison window gives the test more runs to work with and is the cheapest fix.

If you routinely need faster confirmation of small movements, sampling depth is the lever: Growth and Business sample at n=3. See [Plans](/account/plans) for what that changes.

Also check you are not comparing a partial day against a whole one. Readings run at most once per workspace-local day, so today is incomplete until it closes. [Reading the numbers](/measure/reading-the-numbers) covers window choice.

## Why does one model show no data at all?

Almost always because it was never queried. Per-model metrics carry two flags. `tracked: false` means that model is not configured for your workspace, so no request was ever made. `readable: false` means no reader exists for that surface, so we cannot collect it regardless of your settings.

A new workspace starts with two model surfaces tracked, not all of them. If you have never opened your model settings, most of the list will be untracked by default. Turn on the surfaces you care about and data starts arriving on the next day's run.

The `readable: false` case is different and you cannot fix it from settings: `google_ai` has no API reader, for example. Neither flag means the model rejected you. Reporting an untracked model as 0% would invent a failure that never happened, so we report it as unmeasured instead. See [Limitations](/reference/limitations).

## Why don't I see data yet?

Give it a full workspace-local day. An hourly ticker enqueues work, but each prompt × model × country combination runs **at most once per calendar day** in your workspace's timezone. A workspace set up this afternoon has its first meaningful comparison tomorrow, not in an hour.

Before that first day closes, partial data is expected: some prompts will have run and others will not, so early rates are computed from whatever landed. Do not read trends into the first twenty-four hours.

Check the ordinary setup causes too. Prompts must exist and be tracked, at least one model surface must be turned on, and your brand and domain must be set — without them there is nothing to match answers against. If your credit balance is at zero, agent-driven actions such as adding prompts will have been refused rather than partially completed; see [Credits](/account/credits).

Failed runs are stored but excluded from `n`, so a collection problem shows up as a smaller sample rather than a wrong rate. A day with unexpectedly low `n` is worth a look.

## Why did a prompt stop being tracked?

The two usual causes are that someone removed it, or that your workspace is at its prompt slot limit. Slots are a fixed stock — 50 on Starter, 150 on Growth, 350 on Business — and adding a prompt when the stock is full will not succeed until a slot is freed.

Removal is immediate and stops future readings for that prompt. History already collected remains available inside your plan's retention window: 3 months on Starter, 12 on Growth, unlimited on Business. Once a prompt's data ages past that window, it is gone, and re-adding the prompt starts a fresh series rather than restoring the old one.

Prompts can also be removed over the API. `remove_prompt` is a destructive tool available to any read-and-write key, and it does not ask for confirmation. If a prompt disappeared without anyone in your team removing it in the app, audit your keys in Settings > Developer and revoke any you cannot account for. See [API keys](/account/api-keys).

Re-adding is straightforward once a slot is free, but expect a gap in the series where the prompt was untracked. That gap is unmeasured, not zero.