Contested, Settling, or Decaying? Turn AI-Citation Variance Into a Spend Decision

Questions this guide answers

• How do I decide which AI queries to spend on?
• How do I tell a query I'm losing from a query nobody asks anymore?
• Should I use one significance threshold for all my AI-visibility queries?
• What does it mean when an AI query's variance suddenly drops?
• How do I turn AI-citation volatility into a prioritization decision?

Direct answer

The contested-vs-settled distinction tells you which AI queries are winnable: a high-variance, high-value query is a contested open slot, still up for grabs. This page is the next step, how to turn that signal into a spend decision.

Four moves. Measure the noise floor per query, not with one global threshold. Classify each query into a phase from its variance and share trend. Route each phase to a different move. And before you spend to defend a query whose share is falling, check demand, because a query you're losing to a competitor and a query nobody asks anymore look identical on a citation-share chart and call for opposite moves. The query that's quietly being absorbed, answered so completely by the AI that fewer people ask it, is the one teams keep paying to defend when the right move is to walk away.

First, the noise floor is per-query, not global

Before you can act on a query's movement you have to know what 'movement' even means for that query, and it is not the same number across your set, because the two regimes the contested-vs-settled split describes carry very different floors. A settled query, one clear answer everyone's converged on, barely moves run to run: low floor. A contested query, several plausible answers and thin consensus, reshuffles a lot with nothing changing: high floor.

So a single global significance threshold lies to you in both directions. Set it where contested queries live and you'll miss real movement on the settled ones; set it where settled queries live and you'll flag pure noise on the contested ones as if it were a win. The fix is to measure the floor per query, or per cluster of similar queries, the way you'd establish a baseline before reading any instrument. The mechanics of how many runs that takes are in how many runs until your number is trustworthy; the point here is that the floor is a property of each query, not of your dashboard.

The per-query floor is a map of which battles are winnable

Once you have the floor per query, the same data that filters noise also prioritizes your work. Sort your queries by two axes: how contested they are, and whether you're already winning them.

A contested query you're not yet in is an open slot with the door still open, that's your attack surface, and it's where spending actually moves the needle. A query that's settled against you is a hard, slow fight you win only with a structural change, a new corroborating source, a genuinely better-cited asset, not another content refresh, because a content refresh rarely shifts a query that's already converged on someone else. So you deprioritize those, or escalate them deliberately rather than drip effort into them. The per-query floor stops being a noise filter and becomes a roadmap: it tells you which battles are open, which are won, and which aren't worth fighting with the tools you have.

Three phases, three different moves

Every tracked query is in one of three phases, readable from two trends: how its run-to-run variance is moving, and which way its share is going. Each phase calls for a different move, and treating them the same is how budget gets wasted.

One useful property makes this actionable early: variance tends to collapse before share fully settles, so a query whose run-to-run swing is shrinking is an early signal, often a couple of weeks ahead, that the slot is closing. That's your window to act while you still can.

The trap: a query you're losing and a query that's dying look identical

The third phase is where teams burn money, because two completely different situations produce the same chart. Your citation share is falling and the variance is collapsing. That can mean a competitor has won the slot, a contest you lost. Or it can mean the query itself is dying: the AI now answers it so completely, or buyer behavior has moved on, that fewer people ask it at all. The pie is shrinking, and your falling share is just the query disappearing under you.

Same downward line, opposite correct move. If you're losing a live contest, the slot still exists and is worth a structural fight if the query matters. If the query is being absorbed, there is nothing left to win, and every dollar spent defending it is wasted. So before you treat a falling query as a loss to recover, check whether the query is still being asked. The disambiguating signal is demand, not share.

An honest caveat on the demand signal

The demand check is the load-bearing piece, so be honest about its limits. AI-query volume isn't directly observable the way search volume is; you're inferring it from proxies, search-volume tools, your own prompt tracker, assistant-side trends, so treat the demand trend as directional, not precise. A large, sustained move is real; a small wobble might be noise in the proxy itself. The goal isn't a perfect demand number, it's enough signal to tell 'people still ask this' from 'this query is fading,' which is all the decision needs.

Putting it together: the allocation loop

The whole thing is one pass, run on a cadence rather than reacted to per run. Freeze your buyer prompt set and measure each query as a rate over weeks. Establish the noise floor per query. Classify each query's phase from its variance and share trends. On the falling ones, check demand before deciding anything. Then route: double down on the live-contested slots you can still take, defend the ones settling your way, structurally fight or abandon the ones settling away depending on whether demand is still there.

This is the Measure, Diagnose, Execute, Verify loop with variance as the diagnosis. The variance you were tempted to smooth away is the input that tells you where to spend, and the demand check is what keeps you from spending on a query that no longer exists.

A worked example

Take a representative case, an analytics vendor we'll call Northwind Data (not a real company). Two of its tracked queries were both falling and both going quiet, variance collapsing on each, and the instinct was to pour content into defending both.

The demand check split them. On the first query, buyers were still asking it constantly; the falling share was a competitor winning the slot, a real contest, so Northwind escalated it deliberately, earning a couple of strong third-party sources rather than refreshing its own page. On the second, demand had quietly dried up: the engines now answered that question completely inside the response, and the absolute number of times it came up had been sliding for weeks. There was no slot left to win. Northwind stopped spending on it and moved the budget to a live-contested query it could actually take. One falling chart, two opposite decisions, and the demand signal was the only thing that told them apart.

What we don't claim

Phases aren't always clean; some queries sit ambiguously between contested and settling, and you read the trend, not a single run. You can't force a contested query to settle in your favor, you can only make the accurate, well-corroborated version the easiest one for the engines to converge on (see AI cites consensus, not authority). And the demand signal is a proxy, not a meter. The claim here is narrower and more useful than a forecast: read as trends rather than points, variance and demand together tell you which queries to spend on and which to leave, which is exactly the decision a single visibility number can't inform.

See it on your own queries

Start with the raw material: your buyer queries measured as a rate across engines, with the cited sources behind each. Start Free (free, no credit card) and SolCrys shows you where you stand and which sources are shaping each answer. The per-query floor, the phase classification, and the demand check are the diagnosis that turns that measurement into a spend decision.

Talk to us if you want it run continuously, so the phases update on a cadence and the falling queries get the demand check before anyone spends to defend them.

The variance was never the problem to smooth away. It's the part of the signal that tells you where the next dollar should go.

FAQ

Related guides