Investigate the recommendation. Don’t invent the reason.
When a competitor appears instead of you, the useful starting point is the answer itself. Citation patterns can support an investigation; they do not expose a model’s hidden ranking logic.
First, verify that it is a lost recommendation
Read the full buyer question and answer. Did the answer actually shortlist or recommend the competitor? Was your own brand absent or only mentioned? A competitor named in a warning or a historical reference is not automatically a competitive win.
Use the four-state definitions, retaining the supporting excerpt and confidence. Check aliases and product variants. Separate an ambiguous classification from an evidence gap; otherwise the investigation can begin with a false premise.
Check whether the pattern repeats
Review comparable answers for the same question, version and surface. A single result can suggest something to examine, but it should not be presented as a stable ranking. Record how often the competitor qualifies, how often your brand qualifies, and how many usable answers were collected.
Keep region, language, date and engine/model visible. A comparison between an API sample and a consumer-app screenshot is a surface-divergence observation, not a clean before/after comparison. The baseline guide explains how to establish a repeatable sample.
Separate observed citations from later research
For each cited page, retain the URL, relevant passage, publication or update date when available, and the question it appears to address. Check whether the page concerns the correct product and whether the cited claim is accurate. A citation can be present without supporting every statement in the answer.
Keep a separate list for sources your team found later. Do not add those to the answer’s original citation record. A result with no citations still exists, but it gives less direct source evidence. Never fill that gap with a guessed source and call it observed.
Look for recurring source patterns: first-party documentation, comparison pages, reviews, or independent guides. Report those as associations in your sample, not as proof that any source category caused the recommendation.
Compare the buyer’s need with the available evidence
Work from the requirements in the question. Can a buyer verify fit, limitations, setup, integrations, pricing conditions or migration requirements from your public pages? Is the information current and consistent? Does the answer repeat an outdated claim that you can substantiate and correct?
| Observation | Reasonable investigation | Unsupported conclusion |
|---|---|---|
| A competitor’s setup guide is cited repeatedly. | Compare whether your own guide clearly answers the setup constraint. | The model always favors longer guides. |
| An answer says your product lacks an integration. | Verify actual support and whether its plan limits are documented. | Adding the integration name guarantees a recommendation. |
| No first-party source is cited. | Check crawl access and the relevance of your public evidence. | A crawler visit will make the model cite you. |
Worked investigation: fictional integration gap
Imagine a fictional Acme onboarding product that genuinely supports a CRM on a specific paid plan. In a hypothetical sample, a competing product is shortlisted for that CRM requirement, while Acme’s documentation makes neither plan eligibility nor setup limitations clear. This is an instructional scenario, not a measured customer finding.
The hypothesis is narrow: clearer, accurate integration documentation may reduce ambiguity for buyers and future retrieved answers. The work is to publish verified eligibility, prerequisites, setup steps and limitations, and link it from the relevant product page. It is not to claim that the model’s preference has been explained.
If Acme does not actually support the requirement, do not manufacture favorable copy. The result may be evidence of product mismatch rather than a content problem. Record that conclusion and choose a more appropriate buyer segment.
Write a brief that can be reviewed
Include the buyer question and version, observed answers, competitor states, cited URLs, suspected evidence gap, confidence, proposed change, owner and affected pages. State the acceptance criteria in terms of truthful, useful content: a reader should be able to verify the supported plan and complete the setup.
Prioritize by buyer relevance, evidence quality, scope and effort. Keep any prioritization score separate from Recommendation Share and show its assumptions. Do not imply that a two-hour task will produce a particular percentage increase.
Re-measure and report what happened
Record the shipped date and page revision. Repeat the collection protocol and compare the same questions; include the untreated set when the experiment supports one. Note provider changes, other content work, citation changes, failures and uncertainty.
A rise in recommendations is an observed result. It becomes a causal claim only with adequate experimental support. Stable results or a decline are still useful evidence. Keep referrals and conversions as separately attributed business outcomes, not ingredients in the answer metric.
Use the intervention protocol to document those limits, and the intended Mentionloom loop to connect investigation, shipped work and measurement.
Your next move starts with evidence.
Help shape a better way to understand AI recommendations. Join the Mentionloom waitlist.
Join the waitlistFree to join. No payment details.