How to Measure SaaS Pricing Schema, AI Citations and Price Accuracy

Pricing-schema measurement tends to fail before any data is collected, because the question was never narrowed. "Did the schema work?" has no answer. "Did impressions for these twelve pricing URLs in this country change between these dates, and can anything else explain it?" has an answer, and usually the answer is "yes, several things." This page sets out what each data source actually exposes, what a comparison across it can support, and the point at which a visibility number stops being a business outcome. The recurring theme: the constraint that matters is the denominator, not the tooling.

Two labels mark evidence boundaries on this page. Documented means the guidance that follows is directly supported by published Google or vendor documentation, quoted. Recommendation means a metric threshold, protocol or reporting rule that CoreAEX prescribes and the documentation does not. This page is dense in thresholds, so an untagged rule below is ours. Untagged text is ordinary explanation or a conclusion following from something already labelled.

Choose the outcome first

Seven distinct outcomes get collapsed into "AI visibility," and they need different data, different denominators and different claims. Pick one before choosing a tool.

Price accuracy is the row no platform supplies. No monitoring product reports whether the number a system stated about your pricing is right, because that requires comparing an answer to your commercial truth - which only you hold. It is the outcome this cluster cares about most and the one you have to build.

That is not the same as saying it cannot be automated. Where your pricing model is structured, you can automate answer capture, price extraction and comparison against a versioned expected truth. What automation does not remove is the judgement: complex units, minimums, commitments and hedged prose need explicit coding rules and human review of ambiguous cases. Retain the raw answer, version the expected truth, publish the coding rules, and review by hand what the rules cannot settle. Recommendation

Measurement dictionary

These definitions are used throughout this cluster and are fixed here. Two adjacent terms with different denominators are a reliable way for a measurement claim to become indefensible.

The mention/citation boundary is not a stylistic preference, and vendors encode it in their data models. In Ahrefs' Brand Radar API, the mentions endpoint's field description reads Estimated mentions from responses mentioning only your brand - brand names - while the citations endpoint's reads Estimated citations from responses mentioning only your brand URLs. Names versus URLs. Reporting a mentions figure as citations changes what is being counted, not just what it is called. Documented

That makes citation a displayed-interface outcome. It does not establish that the system retrieved the page during that run, used a particular passage from it, or relied on it for the claim beside the attribution.

Data-source map

Every source below answers a narrower question than its name suggests. The "cannot tell you" column is the one to read.

The table above covers Google's Search Console specifically. For how Bing Webmaster Tools' AI reporting compares - and what neither platform's numbers can prove about AI visibility on their own - see comparing Search Console and Bing Webmaster Tools reporting.

Three Search Console limits will bite a pricing measurement specifically. Documented

Filtering changes the denominator. Google states that some queries are omitted to protect privacy, that They're included in chart totals, unless a query filter is applied, and that Filtering your data by query or URL can affect the report totals due to data truncation and the omission of anonymized queries. A filtered total and an unfiltered total are different populations. Comparing them is a denominator error, not a finding.

The table is not the whole picture. Due to internal limitations, Search Console stores and shows only the most important data rows. The API is blunter: The API is bounded by internal limitations of Search Console and does not guarantee to return all data rows but rather top ones. Absence from the table is not absence from Search.

The generative-AI figure is aggregated by property unless you filter. This one matters on a page about denominators and is easy to miss: Data on the chart is aggregated by property. For example, if two results from the same site appeared in a generative AI search results feature, they count as a single impression in the chart total. If you add a URL filter, the chart data is aggregated by URL. In the table, Data grouped by country, device, or date is aggregated by property. Data grouped by page is aggregated by page. So a cohort of pricing URLs read off the unfiltered chart is being counted at property level, and the same cohort grouped by page is not the same number. The report also inherits the Performance report's 1,000 row limitation, so state your table's coverage whenever a cohort or dimension could exceed it.

Recent data moves, and sometimes it is simply wrong. Newest data can be preliminary, meaning it's still being collected and might change in the next few hours. Google also publishes a data-anomalies page, and at the time of writing it records: A logging error caused a decrease in impressions on the Generative AI performance report in Search for data from August 13 - August 17, 2026. Anyone measuring an August 2026 change against that report is reading five days of corrupted data. Check the anomalies page before interpreting any period, not after.

Baseline design

A baseline is a set of decisions you write down before collecting anything, so that the comparison later is between like and like. Six things have to be fixed, and each of them silently changes results if it drifts. Recommendation

• The cohort. Which exact URLs. Fix the list; do not let pages join or leave it between periods. If a page must be replaced, that is a methodology change and gets recorded as one.
• The prompt set. Written out in full, versioned, and unchanged between runs. Adding a prompt because it produces a better answer is how a measurement becomes a demonstration.
• The engines and models. Named, with model labels captured at run time where the interface shows them. "ChatGPT" is not an engine specification; the model behind it changes.
• Geography and account state. Country, and whether the session is logged in, has memory or personalisation enabled, and whether web search was on.
• The time window and repetition count. How many runs per prompt, on how many days. A single run per prompt is an anecdote.
• The page characteristics you are tracking. Schema present or absent, type used, whether pricing is server-rendered, whether the plan is self-serve. These are the covariates you will need later, and they are much harder to reconstruct retrospectively.

Archive the raw outputs. Full response text, every linked source, timestamps, model labels. Generated answers are not reproducible, so an unarchived observation cannot be re-examined and effectively did not happen. This is the single cheapest thing on the page and the one most often skipped.

Record your tooling's own version. Vendor metric definitions change, sometimes on a published date. Ahrefs' Brand Radar is changing its volume basis: its methodology documentation states that Ahrefs temporarily added an option in Brand Radar to switch back to plain Google search volume for comparison, and that that option will be available until August 31, 2026, after which reports will use AI adjusted volume only. The AI-adjusted figure is built by taking a prompt's parent keyword's Google search volume and applying a platform-specific ratio to produce an estimate for each AI platform, derived from Ahrefs' own aggregated traffic data across AI platforms relative to Google. Impressions and share of voice both rest on that basis. A figure computed before that date and one computed after are not the same measurement, and nothing in a dashboard will tell you. Documented

That example is two days old at the time of writing and will be historical by the time you read it. The durable point is the practice: record which version of a metric definition produced each number, and re-check the definition before comparing across periods. Recommendation

What a before-and-after comparison can support

Before-and-after is the design almost everyone uses, and it is operationally useful. It is also the design least able to isolate a cause, and it is worth being clear about why before reporting one.

Google recommends the comparison and cautions about it in the same breath. Its structured-data guidance says The best way to do that is to run a before and after test on a few pages on your site, immediately followed by This can be a little tricky, since page views can vary for a single page for various reasons, and a prescription for controlling that by page selection: choose pages that won't be affected by the time of year or timeliness of the page content; use pages that won't change much, but are still popular enough to be read often enough to generate meaningful data. Documented

Read that as what it is: a caution about the validity of the comparison, and advice on reducing confounders by choosing stable pages. It is not an endorsement that a difference you observe was caused by the markup.

Google is repeatedly explicit that site changes carry no guaranteed effect and that positions move for reasons unrelated to you. From its guidance on debugging traffic drops: Keep in mind that there's no guarantee that changes you make to your website will result in noticeable impact in search results; positions aren't static or fixed in place; Small fluctuations in position can happen at any time (including moving back up in position, without you needing to do anything); and on seasonality, Sometimes changes in user behavior will change the demand for certain queries, either due to a new trend, or seasonality throughout the year. Documented

So the honest list of things that can move your numbers between two periods, none of which you did:

• A Google ranking update, or ordinary position drift
• Seasonality and demand shifts in your category
• Competitor content or pricing changes
• Engine or model changes at any AI provider, usually unannounced
• Recrawl lag - your change may not have been seen in the "after" window
• Other edits to the same pages in the same period
• Reporting defects, like the August 2026 generative-AI logging error above
• A vendor metric-definition change, like the volume-basis switch above

What a before-and-after comparison does support is an operational statement: the numbers changed, in this direction, over this window, and here is what else was happening. That is genuinely useful for deciding whether to keep going. It is not a causal finding, and the write-up should use "coincided with" rather than "drove." Recommendation

Stronger designs, honestly costed

Three designs get you closer to isolating an effect. Each costs something real, and it is worth naming what, because a design nobody can actually run is not a recommendation.

Matched pages. Split comparable pricing or product pages into treated and untreated groups, matched on pre-period performance, and compare the change between groups rather than within one. This can reduce confounding from shocks that hit both groups - seasonality, a ranking update, category demand - but only under assumptions you have to state and check: that the two groups would otherwise have followed comparable trends, that the shock affects them comparably, and that no other change was applied to one group and not the other. Matching on pre-period performance does not establish any of those. Show the pre-period trends, freeze other edits to both groups for the duration, record recrawl timing, and report the result as conditional on those assumptions holding. Cost: you need enough comparable pages, which most SaaS sites do not have for pricing specifically. A site with one pricing page cannot run this. It becomes feasible where you have many plan, feature or comparison pages sharing a template.

Staggered rollout. Apply the change to one group, then a second group weeks later, and see whether each group's change coincides with its own treatment date rather than a common date. Cost: time, plus the discipline not to ship the change everywhere when the first group looks good. Its advantage is that a shared external cause would move both groups at the same moment, which this design can see.

Repeated measures on a fixed prompt panel. Run the same prompts, same engines, same geography, many times before and after. This addresses the noisiest problem in AI measurement, which is that a single answer varies run to run. Cost: mostly units and time, and it is the most feasible of the three for a small site.

What you can claim depends on how treatment was assigned, not on which of those three shapes you picked. Any of them can fall into one of four assignment cases, and the case is what governs the language:

• Random assignment of comparable units, with other changes frozen - a controlled field experiment, and generally the strongest basis here for estimating a causal effect, subject to implementation, interference and measurement assumptions.
• Deliberate, non-random assignment - you chose which pages got the change. This is quasi-experimental only when paired with a defined identification strategy and a credible counterfactual, such as difference-in-differences with defensible parallel-trends assumptions. Non-random assignment on its own does not make a study quasi-experimental. Without that strategy, treat it as observational.
• Treatment following existing differences - you marked up the pages that happened to need it. Observational, and the differences that made you choose those pages are candidate explanations for the result.
• Repeated measures with no concurrent control - an interrupted time series. It shows a change at a point in time; it does not separate your change from anything else that happened then.

One caveat survives every version, including the randomised one: none of these designs controls the answer engines, which change without notice and are not part of your experiment. So even a well-assigned test is an estimate made inside a moving system, and the write-up should say so. Where assignment was not random - which it usually is not - "associated with" is the right verb. Recommendation

On running tests at all, Google's guidance covers safety and not inference. Its website-testing documentation is about not being penalised: Don't show one set of URLs to Googlebot, and a different set to humans. This is called cloaking, and is against our spam policies; use a 302 (temporary) redirect, not a 301 (permanent) redirect; and If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly. Documented

We located no Google guidance on what such a test establishes. The page addresses cloaking, canonicalisation and duration, and says nothing about controls, confounders or attribution. That silence is worth stating plainly, because the page is sometimes cited as though Google had blessed SEO A/B testing as an inferential method. It has not addressed the question either way.

Business outcomes, and where visibility stops being ROI

The chain from markup to money has several joints, and each one loses information. Being explicit about which joint you have measured is the difference between a defensible report and a claim that collapses under one question.

Influenced pipeline is not ROI. Influenced pipeline says a touchpoint appeared somewhere in the journey of deals worth a certain amount. It has no denominator of cost, no counterfactual, and an attribution model chosen by whoever configured the CRM. Calling it ROI requires investment on one side, return on the other, and a defensible method connecting them. If any of those three is missing, report the number under its real name. Recommendation

Two things worth measuring that are not visibility - and they are not the same kind of thing, which the rest of this page depends on.

Internal pricing parity is a controlled implementation metric. Do your visible pricing, your markup and your pricing authority agree? Pass or fail, entirely within your control, no external system involved. It is the one metric on this page you can move with certainty, and it belongs first in any report.

AI-answer price accuracy is an external observation. The proportion of observed answers stating your price correctly - against a denominator that has to specify prompts, engines, models, geographies, dates and repetitions, because the number is meaningless without them. It necessarily depends on what an engine generated under those conditions. Your work improves the inputs available to that engine; it does not control the output, and the write-up should not imply otherwise.

One caution from Google that belongs in any conversation about measurement vendors, this page's recommendations included: Be wary of third-party tools that promise ranking success or claim to use 'internal' Google metrics. No third-party tool has access to our internal ranking or AI systems. The monitoring tools described here do not claim internal access - they sample prompts and label their outputs as estimates - but the caution is the right filter to apply to any vendor whose numbers you are about to put in a board report. Documented

Quarterly update protocol

A measurement that is not repeated the same way is not a measurement. This is the minimum protocol that stays feasible under real plan limits. Recommendation

1. Re-run the fixed cohort and the fixed prompt set, unchanged. Same URLs, same prompts, same engines, same countries, same repetition count.
2. Capture page state on the same dates as the answer tests. Visible pricing, raw HTML, rendered DOM, JSON-LD, validation status. A page that changed between the two is not the page you tested.
3. Archive everything mutable - full responses, linked sources, model labels, timestamps.
4. Code price accuracy against the versioned pricing source of truth as it stood on the observation date - not today's prices - either manually or through automated extraction and comparison. Retain the raw answer and the coding rule, and send ambiguous units, commitments, qualifiers or conflicting figures to human review.
5. Pull the platform reports for the same window, and check the data-anomalies page for that window before interpreting anything.
6. Record the change log before analysing: engine or model changes, vendor metric-definition changes, cohort additions or removals with reasons, page edits, and any tooling limit hit.
7. Compute per-engine and per-question-class figures before any pooled number, and do not pool where denominators or citation mechanics differ.
8. Publish denominators beside every percentage. If the denominator cannot be stated, the percentage does not go in the report.

Budget the run against your API allowance before collecting data, not after. Ahrefs documents its consumption formula as max(base_cost, per_row_cost * num_rows) with a base cost of 50 units, where per-row cost is the sum of the costs of each unique field that appears in either the returned result, or in the where or order_by parameters - default one unit per field, but certain metrics are more expensive and may consume 5 or 10 units. The response exposes what a call actually cost through headers including x-api-rows and x-api-units-cost-total-actual. Documented

So: pilot the exact fields you intend to request, read the returned row and unit-cost headers, multiply by your cohort and repetition count, and size the design with headroom. Treat row limits and pagination as coverage controls - verify that every expected page of results was actually retrieved, because an endpoint's row limit is a real way to end up with partial coverage. Handle an exhausted allowance or a failed request according to what the API actually returns; we located no documentation of what happens when an allowance is exhausted, so do not assume either silent truncation or a clean refusal without testing it. A protocol you can finish every quarter beats a larger one you complete twice.

The cohort is fixed; the change log is what moves. When a page must leave the cohort - it was consolidated, the plan was retired - record the removal and its reason rather than quietly re-baselining. A cohort that has silently turned over is why year-on-year comparisons stop meaning anything.

Reporting template

A report that survives scrutiny has the limitation next to the number rather than in an appendix. This structure is short enough to actually be produced quarterly. Recommendation

1. What we measured. Cohort size, prompt-set version, engines, countries, date window, repetition count. One paragraph. If a reader cannot reconstruct the denominator from it, it is not finished.

2. What changed since last quarter. The change log from step 6 above - engine changes, metric-definition changes, cohort movements, page edits, tooling limits hit. This goes near the front, not the back, because it governs how everything below should be read.

3. Internal consistency. Pass/fail: does visible pricing match markup match the source of truth, across the cohort? This is the metric you fully control and it belongs first among the results.

4. Price accuracy. Numerator and denominator stated. Broken out per engine. State the coding method and the coding rules; where coding was automated, report the human-review procedure and the number of ambiguous cases reviewed.

5. Visibility. Platform impressions where available, mentions and citations from monitoring, each labelled with its source, its definition and its estimate status. Don't merge a mentions figure and a citations figure into one number.

6. Search performance. Search Console figures with the filtering caveat applied - and a note if any query filter was used, because that changed the denominator.

7. Commercial. Sessions and conversions where attributable, named as association rather than cause, with the attribution model stated.

8. What we cannot say. An explicit section. The questions this quarter's data does not answer, and why. On this topic that list is long and stating it is what makes the rest credible.

Two phrasing rules for the narrative. Use "coincided with" and "was associated with" unless a design genuinely isolated the change - and none of the designs above fully does. And don't report a percentage whose denominator is not on the same page. Recommendation

What this page doesn't settle

What the measurements actually found. This page is a method, not a result. The original CoreAEX pricing-extraction study is where observed figures will be reported, with its own sample, prompt set, engines, dates and denominators. No number on this page is a finding about the world.

How to fix what the measurement reveals. A wrong or missing price traced through the layers is the troubleshooting page's subject; preventing drift in the first place belongs to the implementation page in this cluster.

Whether schema affects AI citation. This page describes how you would measure such a thing responsibly. It does not claim the relationship exists, and the framework here is deliberately capable of returning a null result.

Sources

Sources: Google's statements that AI-feature traffic is reported within the Web search type are from AI features and your website (last updated December 10, 2025). Before-and-after guidance and its caveats are from Intro to structured data (last updated December 10, 2025). Statements on position stability, seasonality and the absence of guaranteed effect are from Debugging search traffic drops (last updated December 10, 2025). Testing safety guidance is from Website testing and Google Search (last updated December 10, 2025) - a page about cloaking and duration, which does not address what a test establishes. The third-party tools caution is from Optimizing for generative AI (last updated July 10, 2026). API row limits are from the Search Analytics API reference, which displays a last-updated date of August 11, 2026. Search Console Help pages publish no last-updated dates, so the following were reviewed on August 29, 2026 and that is the only date we can give: Generative AI performance report, Performance report overview, Dimensions and data groupings, Advanced filtering and comparison, Rich result reports and Data anomalies in Search Console - the last of which is by design a moving record and should be re-read for the specific window you are analysing. Ahrefs Brand Radar mentions and citations field definitions are from the mentions overview and citations overview endpoint references, read from the live API schema on August 29, 2026; corpus construction and modelling disclaimers are from Ahrefs' published Brand Radar methodology; the AI-adjusted volume basis change is from How Ahrefs estimates AI search demand; and the unit-consumption formula is from the API limits and consumption reference. Ahrefs is a commercial vendor and its Brand Radar figures are labelled as estimates throughout that schema.

---