AI Visibility Research Methodology v1.0
Adviora’s public methodology establishes a rigorous governance framework for analyzing generative AI visibility, defining explicit data protocols across prompt populations, execution environments, and evaluation metrics.
Published Oct 30, 2026Updated Oct 30, 2026

Core Methodological Principles
- Distinct Unit Counting: The framework strictly separates analytical units treating prompts, successful execution attempts, response records, and citation occurrences independently to prevent metric inflation.
- Execution & Prompt Integrity: Prompt records (767 total) are distinguished from normalized text hashes (723 strings) and semantic intent groups. Operational comparisons account for slight real-world prompt wording variations across engines rather than assuming identical controlled experiments.
- Controlled Environmental Tracking: Every observation records its specific tracking run, engine/model configuration, language code, requested market, and live web-search invocation flag. Missing data points (such as unclassified sentiment or absent citations) are explicitly recorded as valid observations of absence rather than coerced into negative or default values.
- Auditable Classification Pipelines: Sentiment scores and citation categories utilize versioned classification protocols (such as OpenAI API-assessed response tagging and a 10-class source taxonomy), separating algorithmic outputs from verified human judgment.
- Strict Research Governance: To protect participating businesses (17 anonymous tenants in the baseline extract), client identities, proprietary domains, raw prompts, and small intersecting cells are completely withheld from public reporting.
Executive methodological principles
- Count unique prompts, successful answers, attempts and citation occurrences separately, and never substitute one for another.
- Use fixed, versioned prompt panels for longitudinal work. A prompt ID on its own does not mean the executed wording stayed the same.
- Record the engine/model, locale, language and web-search configuration with every observation.
- Compare like with like. Observational cross-engine operational comparisons should be kept distinct from controlled identical-text experiments.
- Treat an absent mention or citation as a true observed zero, as confirmed for this extract. A missing sentiment classification should not be read as negative.
- Keep classifier labels, evidence, scoring and version metadata auditable. Model-assessed sentiment has not been independently adjudicated as human sentiment.
- Never release client names, domains, identifying quoted text or small-category combinations that would allow re-identification.
1. Study design and research unit
Adviora runs business-specific buyer questions against configured AI engines and records what comes back. The historical study is observational, with repeated measures wherever the same execution conditions recur. It is not a randomized causal experiment or a representative survey of all AI users, and it is not evidence of search-market share.
| Unit | Definition / permitted claim |
| Business | An internal business_id/tenant scope; externally reported only in aggregated, non-identifying form. |
| Prompt record | One ai_prompts.id; multiple records can contain identical or equivalent text. |
| Canonical question | Deduplicated buyer-question meaning after documented normalization and semantic review. Not identical to prompt record count. |
| Executed prompt | Actual executed_prompt_text from the response table; primary text for matching historical observations. |
| Attempt | An ai_prompt_executions.id, including failed and timed-out attempts. |
| Successful response | An execution with SUCCESS and its associated response record. |
| Tracking run | The tracking_run_id group; not automatically a calendar day or an independent statistical sample. |
| Citation occurrence | One ai_response_citations row; duplicate URL/domain citations may occur in a response. |
| Mention | One brand/competitor mention classification row; count unique response IDs for response-level presence. |
2. Data lineage and relational joins
The private analysis tables chain together like this: ai_prompts → ai_prompt_executions (prompt_id) → ai_prompt_responses (execution_id, unique) → ai_brand_mentions / ai_competitor_mentions / ai_response_citations (each by response_id). Analytical extracts should keep both execution_id and response_id.
Child tables should be joined independently or aggregated to response_id first. Joining brand mentions, competitor mentions and citations at row level in one step multiplies rows and falsely inflates metrics. Integrity checks compare response counts, distinct IDs, all foreign keys and duplicate primary keys.
The observed baseline extract reconciled 5,470 execution attempts with 5,039 successful responses. Of those responses, 878 have brand-mention records, 984 have competitor-mention records and 3,013 have citation records. For this dataset, absent records are confirmed as valid observations of absence and do not point to incomplete analysis.
3. Prompt population, provenance and construction
The prompt inventory stores prompt_text, business_id, discovery_source, prompt_cohort, category, language_code, country_code, prompt_set_version, created_at and other provenance fields. Recorded cohorts include unbranded_paa, paa_derived and generated, and source labels include website_derived and manual. These labels describe stored classifications. They are not a fully evidenced, step-by-step record of how prompts were historically generated.
3.1 Method of documenting prompt creation
- Document the upstream source type and, where recorded, its reference (for example a source question, website-derived evidence or manual input).
- Record whether a source question was rewritten into recommendation, comparison or buyer-intent phrasing, and keep transformation versions where available.
- Tag intent (discovery, comparison, recommendation, trust, local, transactional, informational and so on) separately from linguistic structure and journey stage. These finer categories are proposed for consistent tagging in future; nothing here assumes they were applied historically.
- Keep a language and market target for each prompt, and record whether the wording is brand-neutral or explicitly branded.
- Retain provenance, creation batch, quality review and deduplication decisions when they exist, and mark unavailable historical steps as not recorded.
3.2 Unique prompt counting rules
- Prompt record count: COUNT(DISTINCT prompt_id) within the defined research scope.
- Normalized text uniqueness: COUNT(DISTINCT hash(lowercase + trim + documented Unicode/whitespace normalization of executed or stored question text)), with the exact specification disclosed.
- Semantic canonical uniqueness: the number of question-equivalence groups, counted only after a documented semantic deduplication protocol. It should not be equated with a hash count.
Prior validation of the October extract found 767 distinct prompt records and 723 normalized distinct text strings. The two denominators measure different things. Prompt modifications and engine-specific rewrites need to be represented separately, and matched panels should be built from the actual executed text.
4. Measurement scheduling and historical frequency
Each execution links to a tracking_run_id, engine_id, status, attempt time and retry_count. Observed frequency has to be kept apart from planned frequency, which can't be fully inferred without the run-schedule configuration. A date span of several weeks is not the same as daily sampling.
- Attempt count: distinct execution IDs in the defined time window, including failures and timeouts.
- Success rate: successful execution IDs / all eligible attempted execution IDs, with retry treatment reported.
- Measurement days: distinct local calendar dates with eligible attempts per comparable prompt–engine–configuration panel.
- Observed frequency: total eligible successful observations, with distinct measurement days per panel reported separately; report the median and distribution, not only the mean.
- Scheduled coverage: observed scheduled slots / planned eligible slots, computed only when the original schedule and suppression rules are known.
Repeated-measurement estimates require a stable business, prompt identity, actual executed wording (or an audited semantic-equivalence class), engine/model, language/locale and relevant search mode, and any relaxation of these must be reported. When a panel has several successful observations on the same day, choose one explicit policy (first, last, median or per-slot) and document it before calculating.
The baseline covers eight execution dates between 5 and 23 October 2026 and 4,005 prompt–engine combinations. Of these, 3,293 appear on one day, 205 on two and 507 on three, so the data cannot be described as a continuous 14-day daily panel.
5. Locale and AI engine execution conditions
Requested market (country_code), prompt language (language_code), actual locale_method, engine/provider, model_name, model version where available and search invocation settings should each be stored and kept distinct. A target-market instruction written into a prompt is not evidence that retrieval was geographically restricted.
Country and language labels should be normalized for analysis, while the original values and the mapping dictionary are preserved. Raw labels include language variants such as en, en-US, english, es, es-PA and es-DO, and countries appear as names as well as codes. Markets should not be pooled until they are harmonized and the pooling is justified.
web_search_used is a flag recorded at execution. It cannot be used interchangeably with verified tool invocation, successful live retrieval or citation presence. For each provider, record which of these behaviors raw_response actually evidences, and classify unsupported fields as unknown instead of guessing.
When cross-engine panels differ in executed wording, retrieval support, location method or model, they are described as operational comparisons. A controlled identical-question comparison requires matching substantive wording, intent, locale and retrieval conditions as far as each provider supports.
6. Response and entity annotation
Response text and raw provider output are kept privately, along with response_hash, analysis_version, scoring_version and position_analysis_method. Entity detections are stored as structured mention rows. Target-brand detection and competitor detection are separate tasks, and a response with several competitor mention records counts once as a competitor-present response in the response-level denominator.
- Target mention rate: eligible successful responses containing ≥1 validated target-brand mention / total eligible successful responses.
- Competitor mention rate: eligible successful responses with ≥1 competitor mention / total eligible successful responses.
Mention position and citation position are the positions stored by the engine or classifier. They must not be described as a recommendation ranking until the implementation-specific definition has been verified. Where recorded, mentions in prose, lists, links or summaries may need separate display categories.
7. Sentiment classification protocol
The engine operator confirmed that sentiment was classified by submitting response text and contextual content to the OpenAI API. The saved labels and scores are genuine completed classifications in this dataset. For both target and competitor mentions, the schema stores sentiment, sentiment_score, sentiment_confidence and sentiment_version. This document makes no claim about the exact system prompt, score calibration, OpenAI model ID, independent human agreement or rubric details, because none of these were supplied.
Counts should be reported as model-classified, mention-level labels. They are neither human-reviewed truth nor a measure of general consumer favorability. Positive and negative labels interpret the observed answer and its context; they do not show causal effects on a brand. A null label means the mention field is unclassified, not negative, and confidence=0 is a stored value that does not automatically mean the classification failed.
- Positive share among labeled mentions: positive mention records / mention records with a positive, neutral or negative classification. Report unlabeled counts separately.
Any comparison of sentiment across cohorts or over time should stratify by, or disclose, sentiment_version, model and prompt composition. A change in the classifier can look like movement in brand perception.
8. Citation extraction and classification
Each citation record keeps the URL, raw URL, registrable domain, source_host, extraction_method, citation_position, target-domain flag, category, confidence, classification_version and an optional manual override. A reference here is a recorded citation occurrence. It is not necessarily an independent publisher, a distinct page or an externally verified endorsement.
- Citation-bearing response rate: successful responses with ≥1 extracted citation / eligible successful responses, by engine and search mode.
- Citation occurrences: count of citation rows, with repeated occurrences retained for occurrence-based analyses.
- Unique URL/domain breadth: COUNT(DISTINCT canonical URL) or COUNT(DISTINCT normalized registrable domain), with the canonicalization rules specified.
- Target-domain citation response rate: successful responses with ≥1 target-domain citation / eligible successful responses, by comparable cohort.
Category analysis uses COALESCE(manual_override_category, category) as the effective saved category. The current taxonomy has ten classes: commercial providers and brands; retailers and marketplaces; editorial publishers and review sites; directories and review platforms; communities and forums; social and creator platforms; government and public bodies; academic and research sources; associations and nonprofit organizations; and other/unclassified.
Citation-support flags are separate from category, and they are not proof of causal influence. A null supports_client_brand means the field is unknown or not populated, and it must not be merged with zero. In the baseline, 25,334 of 33,384 citation records have a null support flag. Because the support classifier is selective, support rates should be calculated only within an explicitly eligible classified subset.
9. Comparison and longitudinal estimands
| Analysis | Required cohort and denominator |
| Engine disagreement | One comparable tracking_run × canonical/verified-equivalent prompt × business/locale group with ≥2 successful engines; report how many engines present, and whether executed wordings differed. |
| Prompt-cohort association | Stratified rates by prompt_cohort and business/engine/market; observational differences are not controlled prompt causal effects. |
| Presence switching | For repeated prompt–engine–execution-condition panels, whether observed binary presence differs across distinct dates. Report panels with at least one mention separately. |
| Citation persistence | Same normalized URL or domain observed in consecutive eligible measurements of same panel; disclose time gap and occurrence vs distinct-source unit. |
| Sentiment movement | Labeled mention-level or response-level change under consistent rubric and entity identity; avoid averaging arbitrary ordinal labels. |
| Brand–citation intersection | Brand mention present with / without a recorded target-domain citation in same successful response; report search and extraction modes. |
The baseline operational cross-engine analysis contained 1,014 groups with ≥3 engines, 387 of them with mixed stored target-mention presence. These groups are not automatically controlled experiments with identical text. Historical repeat panels and the switching measured in them should not be generalized to all buyer questions unless the conditioning and sampling design are specified.
10. Data validation and publication QA
- Verify 1:1 linkage between executions and responses, ID uniqueness, referential integrity and exact reconciliation to control totals.
- Compare status totals across the export, database verification and analytical materializations, and keep zero-event observations.
- Cross-check model mappings, run timestamps, timezone, locale and stored web-search flags. The operator confirmed these for this baseline.
- Record citation extraction-method coverage by engine, and avoid implying that zero citations means a model has no citation capability.
- Audit classification-version consistency and manually review samples of edge cases, particularly abbreviation-based entity mentions, duplicates and category boundaries.
- Keep raw row-level data, scripts, query versions, filter logic, the normalization dictionary and calculated tables in a restricted reproducibility package.
- For every published claim, archive the numerator, denominator, observation window, inclusion/exclusion rule and grouping keys.
- Suppress or generalize rare categories, market combinations and example prompts that could reveal a particular business.
11. Statistical interpretation and limitations
The study draws on a convenience set of participating businesses and the prompt panels those businesses selected. It is not a probability sample of industries, users or all AI responses. Repeated executions within a prompt or business are correlated and should not be presented as independent experimental subjects. When intervals are needed, compute them at the relevant clustered unit (such as prompt or business) with an explicitly declared method, and avoid naive standard errors based on response rows.
Temporal trends need enough consistent time points, and several observations spread across eight active calendar days do not establish daily 14-day behavior. Model changes, differences in prompt wording, country configuration and source extraction are all possible confounders. Observational association cannot establish that citation placement caused a recommendation, or that Adviora caused a visibility improvement.
12. Privacy, governance and external communication
Public materials may identify industries or categories, broad markets and aggregated findings, but only where the disclosure does not allow re-identification. Client or business names, business domains, raw prompts or responses with identifying features, private execution IDs, and individual competitor details that would reveal the client must never be published. Internal analysis may keep the original keys in a separately controlled environment.
Small cells and intersectional disclosures should be avoided, because a combination of category, locality, market and sample size can single out an organization even without its name. Every table, chart caption and sample quotation should be reviewed before release. Anonymous business codes belong only in restricted working files and should not serve as public pseudonyms when re-identification would be easy.
13. Mandatory methodology disclosure for each research publication
| Disclosure item | Minimum required content |
| Window | Exact start/end dates, timezone and active measurement dates |
| Sample | Businesses (aggregated), categories, prompt records, unique question definitions |
| Execution | Attempts, successes, excluded attempts, engine/model coverage, per-prompt frequency |
| Prompt design | Provenance/cohort mix, transformations/versions, comparability of executed text |
| Conditions | Markets, languages, locale method, web search by engine |
| Outcome definitions | Formulas, response/mention/citation unit, missing/null handling |
| Quality | Reconciliation checks, classification and extraction versions, validation caveats |
| Interpretation | Limitations, representativeness, observational nature, commercial disclosure |
14. Version policy and open implementation questions
Version 1.0 rests on the evidence and operator confirmations available by 28 October 2026. Later methodology versions should state what changed in formula definitions, prompt generation and validation procedures, locale control, model and extraction integrations, and classifier rubrics. Any metric series whose definition changes must be segmented or recomputed to a common version.
Several items are left for a later implementation appendix rather than assumed here: the full tracking-run schedule and intended-slot logic; detailed prompt rewriting and approval prompts; executable provider-specific search and tool settings, with evidence of actual invocation; the citation canonicalization algorithm; the exact sentiment classifier prompt, model and rubric; semantic-equivalence validation; and the confidence-calibration and human adjudication protocol.
Appendix A. Baseline audit context (not a substitute for study-specific sample disclosure)
| Audit statistic | Validated context |
| Time covered | 5–23 October 2026; 8 active dates |
| Attempted / successful | 5,470 / 5,039 |
| Prompt records / normalized texts | 767 / 723 (different uniqueness methods) |
| Business scopes | 17; client identities withheld |
| Run IDs / engines | 118 / 6 |
| Response-level target mention / competitor mention | 878 / 984 |
| Citation-bearing responses / occurrences | 3,013 / 33,384 |
| Distinct citation domains | 5,108 |
| Citation classification | 10 effective source types; classification version saved |
| Sentiment | OpenAI API–assessed response/context classification as confirmed by operator |
The source basis is the supplied database schemas; the validated historical execution JSON, measurement coverage CSV, verification CSV and joined mention/citation JSON exports; and the research audit dated 28 October 2026. This methodology deliberately does not expose original client data.
Research transparency
This publication contains no client names, identifying domains or identifying individual prompts. It describes observed samples and their methodological limits, and the primary execution data are kept private.
Frequently asked questions
Adviora’s public methodology establishes a rigorous governance framework for analyzing generative AI visibility, defining explicit data protocols across prompt populations, execution environments, and evaluation metrics.


