How SolCrys Works

How we measure AI visibility - real-user fidelity, not API approximations

We measure AI visibility by running tracked prompts against the engines included in your plan and preserving the evidence behind each response: prompt, engine, capture method, available model or surface signal, timestamp, answer text, citations, and follow-up questions. For surfaces that require rendered or SERP capture, such as Google AI Overviews / AI Mode, we tag the capture method separately. Retail-assistant validation is scoped as an add-on when access and reliability support it. Ongoing workspaces use daily priority-prompt monitoring with rolling 7-day and 30-day aggregates, so we build sample sizes that turn noisy single-snapshot reads into trend lines you can defend internally. We publish this methodology because most platforms describe their measurement in marketing-speak - we'd rather show our work and let you challenge it.

Published 2026-05-08 · Updated 2026-05-10

Questions this guide answers

How does SolCrys capture AI visibility data?
Why should I trust SolCrys's data?
How does SolCrys measure brand mentions in ChatGPT?
Browser-channel vs API capture - how does SolCrys handle the difference?

Direct answer

We measure AI visibility by running tracked prompts against supported engines and preserving the evidence behind each response: prompt, engine, capture method, available model or surface signal, timestamp, answer text, citations, and follow-up questions. For surfaces that require rendered or SERP capture, such as Google AI Overviews / AI Mode, we tag the capture method separately. Retail-assistant validation is scoped as an add-on when access and reliability support it.

Every data point in your dashboard is traceable to a specific prompt, engine, available model or surface signal, and timestamp. Free Audits are one-time snapshots; ongoing workspaces use daily priority-prompt monitoring with rolling 7-day and 30-day aggregates so trend lines reflect repeated capture, not yesterday's coin flip.

Why we treat measurement methodology as the first trust question

AI engines are noisy. Ask the same engine the same question twice in two minutes and you can get materially different answers - this is a documented property of how the underlying language models sample tokens, not a bug. Different users on the same engine often get different responses depending on regional model routing, account history, and live-web variability. We don't think a platform that hides how it deals with this deserves your trust.

The harder question is whether the data is reproducible and tagged clearly enough to explain what was measured. Public engine documentation and third-party research consistently find that consumer chat UIs, APIs, SERP surfaces, and retail assistants can behave differently. The same prompt can return a different answer through the same brand's two doors. That gap is why we tag engine, capture method, available model or surface signal, and timestamp instead of blending surfaces silently.

Channel 1: How we capture from consumer surfaces

For supported consumer and SERP surfaces, we capture the answer evidence available for that engine: rendered answer text where applicable, citations, URLs, regional settings, and available model or surface signals. Google AI Overviews / AI Mode require SERP capture because there is no public API for those results.

The technical details vary per engine and evolve over time. We comply with each provider's terms of service and use the access methods each provider supports. Retail-assistant surfaces such as Amazon Alexa for Shopping and Walmart Sparky are treated as scoped add-ons until access, reliability, legal, and SLA gates are validated.

The full rendered response text - the answer your buyer reads.
Source citations and their URLs - what the engine pointed buyers to.
Surface-specific UI details where supported and reliable.
Suggested follow-up questions - the engine's own model of 'what users ask next.'
Engine-disclosed model signals when available.
A timestamped response record for every data point.

Why the consumer surface matters more than the API

The consumer products are not always thin wrappers over the public API. Consumer chat surfaces can route to different default models, enable different tools, or apply post-processing that the public API does not. Google AI Overviews and AI Mode have no public API at all - every Overviews tracker on the market today is doing some form of SERP capture under the hood; we document the capture path instead of treating it as interchangeable with an API call.

A platform that 'tracks ChatGPT' by hitting a generic API endpoint is measuring something - but it is not measuring what your buyers see. The two outputs can diverge enough that fixing one does not move the other.

What we capture per data point

Every captured response produces a response record with the fields below. If you ever question a specific data point, our team can trace it back to the exact prompt, engine, available model or surface signal, and time, plus the response and citations we stored.

Field	What it captures	Why it matters
prompt_text	Exact prompt submitted, character-for-character.	So you can replay it manually and verify.
engine	Which consumer surface or API endpoint.	So data is not blended across surfaces.
capture_method	API, SERP-rendered, or consumer-surface capture path.	Different methods can return different answers to the same prompt.
model_signal	What the engine disclosed about the responding model, where available.	Engines update defaults; we record what was returned.
timestamp_utc	When the capture ran.	Engines change behavior over time.
response_text	Full rendered response.	The thing your buyer reads.
citations[]	Each cited URL with title and snippet.	What the engine pointed buyers to.
follow_up_questions[]	Engine-suggested next questions.	The buyer journey continuation.

Channel 2: How we capture for agents and deep research tools

Some brand mentions and product recommendations happen inside agents, deep research tools, and enterprise AI assistants that query engines through programmatic interfaces. Where an engine has a reliable API or adapter path, we capture the configured response with standardized prompt, engine, available model or surface signal, and capture-method metadata so snapshots stay comparable.

A programmatic route can return different answers than a consumer chat or SERP surface. That is why SolCrys stores engine and capture-method metadata with the response instead of treating all answer sources as the same measurement channel.

Traceability: we make every data point falsifiable

A claim like 'your brand was mentioned in 23% of category prompts last week' is meaningless unless we can answer the obvious follow-up: show you which prompts, on which engines, at which times, with what exact response. So we built drill-down so you can move from any chart or trend line back to the underlying captured response. If you suspect a result is wrong, ask us for the stored response evidence and rerun the prompt yourself in the same engine to compare substance.

We treat this kind of traceability as the difference between a dashboard you can defend internally to your CMO or board and one you cannot. We don't ship the latter.

How we handle AI engine variability

A single snapshot of an AI response is a snapshot of a noisy system. AI engines are non-deterministic by design - they sample probabilistically so the conversation feels dynamic. Engines also re-route between models, update defaults, and change citation behavior day-to-day. To produce trustworthy trend lines we need repeated capture; one shot isn't enough.

Free Audit reports include a single snapshot for a directional read on where your brand stands today. Ongoing workspaces monitor priority prompts daily and aggregate results into rolling 7-day and 30-day windows, so trend lines reflect repeated capture rather than a per-snapshot coin flip. Single-snapshot moves are labeled as snapshots, not trend changes.

We can't eliminate engine noise - that's impossible. What we can do, and what we commit to, is give you enough sample size that your trend lines reflect repeated measurement, not yesterday's coin flip. We don't currently report formal confidence intervals - sample sizes vary too much across prompt sets and engines to make that label honest. We'd rather show you the underlying responses and let you judge whether a movement is meaningful.

How we disclose available model or surface signals

A common opacity in our category is vendors saying 'we track ChatGPT' without disclosing which model or surface they queried. Our policy is to store the engine, configured adapter, timestamp, and available model signal with the response. When a provider changes behavior or a configured model, we update tracking and disclose material changes so customers can interpret discontinuities in trend lines.

We don't claim to track every variant of every engine. We track the configured surfaces included in the customer's plan and scope premium or retail assistants separately when reliability and access are validated.

What we are explicit about not promising

Trust requires that we name what we won't claim, not just what we will.

We don't promise that fixing a flagged answer gap will guarantee citation lift. Engine behavior is influenced by hundreds of inputs we can't fully see; we tell you what to fix and we re-measure after.
We don't promise identical refresh depth for every workspace. Priority prompts are designed for daily monitoring in active programs; broader coverage depends on the monitoring problem we are solving.
We don't promise complete coverage of every AI engine. New engines launch frequently; we track the engines your buyers actually use, not every novelty.
We don't promise complete rendered capture across every surface or UI element. Engines redesign their interfaces; when extraction is not reliable for a surface, we scope it separately or flag the limitation instead of silently degrading.
We don't personalize results based on a fake user identity. Sessions run with default state - no logged-in personalization, no memory, no account history - so your data is comparable across customers.
We don't blend capture methods silently. API, SERP, and scoped rendered-surface data are tagged separately where applicable.

FAQ

How is consumer-surface capture different from just calling an API?

A consumer chat or SERP surface is not always a thin shell over a public API. It may use a different default model, enable different tools, or render follow-up suggestions and other UI details the API never returns. Where rendered or SERP capture is technically reliable, we tag it separately from API-based response capture.

Why don't you just use the engine's API for everything? It is cheaper.

Cheaper to operate, but API data does not always match what consumer users see. For Google AI Overviews specifically, no public API exists. For consumer chat surfaces, the API and consumer product can return materially different answers to the same prompt. We preserve capture-method metadata so customers understand what was measured.

How do you handle the fact that AI engines give different answers each time?

By repeated capture and rolling aggregation. Daily priority-prompt refreshes feed into rolling 7-day and 30-day aggregates so trend lines reflect repeated measurement rather than per-snapshot variance. We are explicit about sample-size limits and label single snapshots as such rather than reporting them as trend movements. We don't currently report formal confidence intervals - sample sizes vary too much across prompt sets and engines to put an honest statistical label on the chart.

What happens when an engine changes its default model?

We monitor provider announcements and model deprecations on an ongoing basis, with internal alerting for default-model changes. When a configured model or surface changes materially, we update tracking as soon as the change is verified and disclose the change so customers can interpret any trend-line discontinuities.

Can I verify a specific result myself?

Yes. Every data point is traceable to the exact prompt, engine, available model or surface signal, and timestamp. Open any tracked prompt, select a snapshot, and you can see the full response we captured. To verify, copy the prompt text and submit it on the engine yourself within a short time window. The response should match in substance, allowing for the engines' known non-determinism.

Is consumer-surface capture allowed under the engines' Terms of Service?

Our capture follows access patterns each provider supports for the relevant surface and scope. We monitor provider terms and adjust our methods accordingly. For enterprise customers with strict compliance requirements, we can provide documentation of the access methods used per engine under NDA.

How is this methodology different from 'AI visibility' tools that just ping public APIs?

API-only trackers measure what a developer would get back from a generic API call. SERP, rendered-surface, and retail-assistant snapshots answer different questions where supported. SolCrys tags capture method and engine scope so customers know what each data point represents.

Related guides