Troubleshooting

Search or Site traffic is empty

If Traffic → Search or Traffic → Site traffic shows no data, the usual cause is not a broken integration. It is a data window that does not reach back far enough to include your most recent import.

Both screens default to a 28 day window. The date range filter at the top of the page offers 7, 28 or 90 days and carries the choice in the URL as ?days=; any other value reads as 28, so 90 days is the widest window these screens show (readDays in platform/frontend/src/lib/filters.js). If your most recent import lands outside the default 28 days but inside 90, choosing Last 90 days is the actual fix.

In steady state, imports run on a schedule rather than the moment you load the page: Search data refreshes daily at 05:00 UTC through discoveredby-cli@enqueue-gsc-import.timer, and Site traffic data (Google Analytics) refreshes daily at 06:00 UTC through a separate discoveredby-cli@enqueue-ga4-import.timer.

Mapping a property to a project is the exception to that schedule. Mapping queues that project's first import there and then rather than deferring it to the next scheduled run (_enqueue_initial_import in platform/backend/api/routers/integrations.py), so a freshly mapped property does not sit waiting on the timer for its first pull. If that immediate enqueue is lost, the next scheduled run picks the property up anyway: the daily fan-outs reach a project through its mapped properties, and the import widens to a 180 day backfill for any property whose history has never been pulled (_enqueue_ga4_for_eligible_projects and _enqueue_gsc_for_eligible_projects in platform/backend/api/tasks.py). For a mapped property, then, a missed enqueue costs a delay of a day, not a lost import.

Connecting is not the same as mapping, and that difference is the other common cause of an empty Search or Site traffic screen. Connecting queues a discovery pass that maps a property to a project only where the property's own hostname exactly equals one of your project domains and only where that match is unambiguous (sync_and_automap in platform/backend/api/services/integrations/google/ga4_automap.py, sync_and_automap_gsc in the sibling gsc_automap.py, both matching through match_property_to_project in automap_common.py). A subdomain-only match such as a shop.example.com stream against an example.com project, no match at all, or an ambiguous one, leaves the property unmapped on purpose rather than guessing. An unmapped property is in no fan-out's scope, so nothing imports for it and no later run heals it: if those screens have been empty since the day you connected, open the integrations settings and map the property to the project by hand. That mapping is what starts the first import.

Widening the window is still the fix when the most recent successful import, whichever kind, lands outside the default 28 days but inside 90. An import older than 90 days cannot be brought into view from these screens; the next successful import is what fills them again.

No citations yet

Being named in AI answers without yet being cited as a source is a normal, common starting state, not a sign anything is broken.

A mention and a citation are different things: a mention is your brand named in an answer, a citation is your domain linked as a source for that answer, and you can be mentioned without being cited (see Key terms). An engine can describe your brand from what it already knows without pulling one of your pages into the answer at all, so winning a mention is often the earlier, easier outcome, and a citation can take longer to follow.

If citation rate reads zero while your collected answer count is not zero, that is a real zero, not a broken measurement: see Metrics defined for how a genuine zero differs from no data. Domain coverage, a separate number on that same page, catches the weaker signal of an engine reading one of your pages without linking to it. Zero citations alongside domain coverage above zero means retrieval without citation, not a bug.

A run failed

Where to look: each prompt's run history lists the executions in the filter bar's window that match its engine, country, persona and language chips, failed ones included, with their status, up to the 50 most recent. While fewer than 50 are listed, widening the date range or clearing a chip shows more; once 50 are listed it cannot, since the list already holds the newest 50 and clearing a chip only swaps in newer runs of other engines or targets. 90 days is the widest window, so an older run is not listed there. A failed execution shows a plain-language reason drawn from a closed, safe set (timeout, rate limited, provider error, or internal error) rather than a raw error string.

A failed run is retried automatically later the same day, at 03:00, 05:00, 09:00 and 17:00 UTC, so a short engine outage rarely costs you the day. A retry that succeeds replaces the failed run with the answer. Until then, and if the 17:00 retry also fails, the run stays failed for that day. A retry only happens while the prompt, the engine and your plan would still run it.

A Google AI Overviews or Google AI Mode run that reads No AI Overview shown or No AI Mode answer did not fail: the request succeeded and Google showed no AI answer for that search. It counts toward the shown rate instead of any answer metric (see When Google shows no AI answer).

What a failed run does to your numbers: nothing, quietly. Every answer metric on Metrics defined is built from executions whose status is completed, whether it counts those executions directly or counts the mentions attached to them; the three run metrics there also count runs with no AI answer, never failed ones. A failed execution is never completed, so it never contributes an answer, a citation, a retrieval, or a mention to any of those counts. A run that failed to get an answer at all does not drag your visibility, citation rate, share of voice, or any other metric down: it is absent from the count, not counted as a miss.

My numbers moved but nothing changed on my site

Two things that have nothing to do with your website can move your numbers, and both are expected.

Adding a tracked competitor changes share of voice, even though nothing in the answers themselves changed: the denominator is a sum, added up across every active tracked brand family, of how many answers named each one, so widening your competitor roster adds that competitor's own count to the sum (see Metrics defined). The competitor's mentions were already happening; your project just started counting them.

The other cause is the engines themselves. Each tracked prompt runs again on its own schedule, and an engine's answer to the same question can differ from one run to the next even when nothing about your site, your competitors, or the prompt has changed. Engines do not answer the same way every time, so a daily figure moves on its own from one day to the next. A single day's swing is not, by itself, evidence that anything is different on your site; read the trend over the whole window instead of one day.

Competitor shares do not add up to 100 percent

On the Competitors screen, the hero figure and the bar chart, domain-citation share of voice, sum back to 100 percent on the very next load after you pause or remove a competitor. That figure is filtered to active competitor rows fresh on every load, on both sides of the division, so there is no separate step and no lag (see Domain-citation share of voice for the mechanism). Each share is rounded to one decimal place, so the total can still land a few tenths above or below 100 percent even when nothing is wrong; if it is short by more than a rounding difference, or the gap does not close on the next load, that is worth a closer look.

"By brand mentioned", the other share-of-voice figure on the same screen, can lag one load behind instead, and that is expected, not a bug. It reads a flag mirrored onto your brand-entity roster from each competitor's own active flag, refreshed by a sync that some screens run when they load, such as Settings → Brands, and Competitors itself, but only after its own "By brand mentioned" request for that same load. So the very next load right after pausing can still show the old figure, because that load's own sync runs after, not before, the figure it would fix. Reload once more, or open Settings → Brands first, and it will be correct (see Share of voice for the mechanism). The mention rows already recorded are always kept either way, just not counted while the mirror is stale.

A number says no data instead of zero

A metric reading no data is not the same as a metric reading zero, and the product never blurs the two. See How to read any number here on Metrics defined for what no data means and why, and that page's own per-metric sections for which population each number divides by. An empty population is what produces no data; a measured population that happens to contain none of what you are looking for is what produces a real zero.

Related

• Metrics defined: every number's exact formula, denominator, and the no data versus zero rule
• Key terms: what a mention, a citation, and retrieval each mean
• Engines and measurement: which engines run, and how an answer is labelled