Abstract
What this document is and why it exists.
Myrah measures how generative AI assistants — ChatGPT, Claude, Gemini, and Perplexity — discuss, cite, and recommend brands in response to natural-language queries. This document specifies the methodology end-to-end: how prompt sets are constructed, how model responses are collected, how visibility is scored, and how confidence is reported.
Our goal is replicability. A reader with access to the same prompts and the same providers should be able to produce results consistent with ours, modulo the inherent variability of large language models.
Scope
What we measure and what we explicitly do not.
We measure brand presence inside generative AI responses to a defined prompt set. We do not measure traditional search rankings, traffic, conversion, paid media performance, or social mentions. We do not predict revenue lift; we measure visibility, which is a leading indicator.
Prompt construction
How we generate the prompts that actually matter.
Prompts are derived from three sources: (a) the customer's stated niche and product category, (b) competitor positioning, and (c) common buyer-intent phrasings observed in the wild. We generate candidates, deduplicate, and present them for editorial review before any audit runs.
Customers can add, remove, or rewrite any prompt. This is critical: a methodology is only as good as the questions it asks.
Provider selection
Which models we query and why.
We query four engines through their production APIs: OpenAI, Google Gemini, Anthropic Claude, and Perplexity. Each runs on a fast, general-availability tier rather than a frontier or research-preview model — the tiers that answer at the volume and latency a repeated audit requires. We publish the model in use rather than describing it, because the specific model matters to how a result should be read.
Models change as providers ship and retire them. When a model changes, the score for that engine can move without anything about your brand changing — which is why scoring is computed per engine (§06), so a provider swap moves one lane instead of the whole number.
Query execution
How we run prompts to control for known biases.
Each prompt is sent fresh to each engine, on its own, with no system prompt and no conversation history. The prompt text is the entire request. We do not append instructions, personas, or framing of any kind, because anything we added would be a variable we introduced rather than one your buyers would encounter.
We do not inject your brand name into the prompt. The brand is used only to match against the answer after it comes back. If a prompt names your brand, it is because you wrote it that way — prompts carry an explicit branded flag so branded and unbranded questions stay separable in reporting.
Every engine runs with its search tool enabled — OpenAI web search, Gemini Google Search grounding, Claude web search, and Perplexity, which is search-native. This is deliberate: it matches how these assistants answer for real users by default, and it is what produces citations at all. A training-data-only measurement would describe a product nobody uses. The consequence is that results reflect the live web at the moment of the run, which is part of what we are measuring, not noise to be removed.
Where an engine returns citations we capture them verbatim with source URLs, and where an engine exposes them, the pages it consulted but did not cite.
Response parsing
How structured signal is extracted from prose.
We extract: brand mentions (literal and aliased), ranking position when the response enumerates options, sentiment context (recommendation vs. neutral mention vs. negative), and citations. Parsing combines deterministic rules with a secondary LLM pass for ambiguous cases. The raw response is always preserved.
Scoring model
How visibility is reduced to a comparable number.
Scoring is computed per engine, then averaged. Each engine gets a raw score in [0,1] from three bounded components:
raw = 0.55 · presence + 0.30 · prominence + 0.15 · citation
Presence is how often you were mentioned, pulled toward a fixed per-engine baseline so that one answer flipping in a 25-prompt set cannot swing the number the way a raw percentage does. Prominence is mean reciprocal rank across every answer — your position among the brands the engine chose to name, scoring zero where you were absent, so the signal cannot be flattered by which competitors you happen to track. Citation is how often you were cited when citations were on the table at all, and it fades into presence as that opportunity disappears, so an engine that rarely cites does not punish you for it.
The engine scores are combined with an equal weight each — no engine counts for more than another. That is what keeps a provider changing a model from moving the headline: it moves one lane of four.
The 0–100 figure you see is the raw composite mapped through a fixed curve. The mapping is strictly monotone, so ordering, comparisons and trends are untouched; it exists only so the displayed range spreads sensibly across real results instead of bunching in the middle. Weights, baselines and the curve are constants, versioned together — currently scoring v2.0.0. They are changed deliberately and never refitted automatically, because a score that moved when other customers changed would be worthless.
Competitor analysis
How we attribute share-of-voice across the category.
For each prompt, we identify all named brands in the response. We attribute mentions to the customer's defined competitor set and report share-of-voice per provider and overall. Brands not in the defined set are aggregated into "other" but remain inspectable in the raw response.
Variability and confidence
How we handle the fact that LLMs aren't deterministic.
Single-shot results are noisy. We address this in three ways: (1) by running broad prompt sets so individual prompt variability averages out, (2) by shrinking presence and citation toward fixed baselines (§06) so a single flipped answer cannot swing the score, and (3) by monitoring over time so short-term fluctuations are distinguishable from real shifts.
Every run also carries a reliability label, set from the share of queries that failed across the run: under 5% is complete, up to 30% is partial, and above that is low confidence. Failures are counted, not hidden — a query that errored or timed out is excluded from scoring rather than counted as an answer that did not mention you, and the run is labelled so you can see the difference.
Recommendations
How fix suggestions are derived from the data.
Recommendations are generated from observed gaps: prompts where the customer is unmentioned but a competitor is, citations that point to weak source pages, and framings that misrepresent the customer's positioning. Each recommendation includes rationale, target page (where applicable), and expected impact.
Limitations and disclosures
What we cannot tell you.
We cannot guarantee an AI model will respond identically to a previous run. We cannot measure what happens inside a customer's private AI deployment. We cannot attribute revenue. We cannot promise any specific change will lift your score — only that the recommendations are derived from the actual gap observed.
Our methodology evolves as models and provider APIs evolve. We version this document and publish changes.
Changes in v2.0. Perplexity added as a fourth engine. Provider tiers documented: we run fast general-availability tiers. Query execution documented: every engine runs with its search tool enabled, and no system prompt is sent. Scoring specified against the shipped v2.0.0 model: three components with published weights, computed per engine and averaged equally. Reliability thresholds published.