AI Visibility Attribution: When the Mention Isn't You

A buyer asks an assistant for a recommendation and gets three names. One of them sits close to yours. Same category, same metro, sometimes a near-identical brand string. The category match is correct. The entity match is wrong, and the difference decides who gets the call.

That difference is the attribution gap. A mention exists inside an AI answer and lands on a domain that belongs to someone else. An assistant retrieves an outdated directory profile carrying your old address and cites it. It reads a franchise page that outranks the individual location and names the parent. Both events are real mentions of something near your business. Neither produces a referrer that a web analytics platform can read.

Measurement varies by assistant and by mode. A response from ChatGPT with search enabled cites live pages. A response from the same model answered from training data, with its cutoff, cites nothing. The same question can return a mention in one path and silence in the other on the same afternoon.

A visibility record tracks which assistants named which businesses and which URLs received the citation. When an answer names an entity adjacent to yours, that adjacency belongs in the record.

The question shifts from whether a mention happened to what exactly got counted. Everything downstream depends on that label.

What AI visibility attribution actually measures

Attribution is the labeling step between an answer and a metric. An assistant writes a sentence with a name in it. A mention tracker sees a string. The tracker compares that string to a business name and increments a count. That comparison assumes string match equals business identity. The assistant does something else. It resolves entities from retrievable records first. It reads indexed pages and business profiles. It uses knowledge panels and review sites. It maps a name to an entity, then answers. Attribution reverses that process. Given that a name appears, which entity does the answer mean? If the label is wrong, the mention count is wrong. Mentions, citations, and position all depend on attaching answer spans to business records. The labeling step decides whether a mention belongs to the business.

Four failure modes cause most attribution errors.

A same-name company. Two businesses share a name. The assistant names “Acme Plumbing” and means the one in another city. A string match credits the wrong entity.

A generic or dictionary-word name. A business named “Trust” or “Quality Cleaners” appears in an answer as an ordinary word. The tracker counts a mention that never referred to the business. This failure mode also sits behind part of why AI assistants recommend the same businesses: the assistant resolves the word to the most retrievable entity, which is the larger or better-documented one. See why AI assistants recommend the same businesses.

A brand-versus-product split. The buyer asks about a company. The assistant recommends a product line or a parent brand. The name in the answer belongs to a different entity in the record. A brand accuracy audit starts with this labeling step because the audit needs to know which entity the answer names.

Merged profile records. Directory records combine two locations or two companies with similar names. The assistant retrieves a merged record and answers with a name that maps to multiple entities. Attribution has to split the label or reject it.

These four account for the bulk of attribution errors, and the first is the most common. One in twenty companies is confused with another business.

One in twenty companies is confused with another business

An aeod.app study examined how ChatGPT, Gemini, Claude, and Perplexity represented 250 companies. In 5% of cases, an assistant confused a company with an entirely different business. That rate is small only if you treat AI answers as a broad popularity signal. In buyer research, the shortlist is the product. A 5% misattribution rate sits inside the same range as the gap between a second-place mention and a fourth-place mention. A brand that loses that slot to another company loses the buyer’s consideration at the same moment the answer is generated. The error lands inside the shortlist, where it changes the outcome.

The same study found that 28% of responses omitted important products or services. A company can be named correctly and still be described incompletely. The assistant lists one service line and leaves out the one the buyer needs. The buyer sees a partial version of the business and moves on. The omission rate is larger than the confusion rate, and it affects the shape of the answer even when the brand name is right.

Confusion varies by assistant. ChatGPT, Gemini, Claude, and Perplexity do not make the same attribution errors at the same rates. One platform can merge two similarly named companies. Another can pull an outdated product line into the answer. A third can favor a competitor with a cleaner entity footprint. This variation makes the same brand look stronger on one platform than another for reasons unrelated to its content. The business did not change. The assistant’s representation did.

That platform-level difference matters for measurement. A single AI visibility number hides the assistant that confused the entity and the competitor that received the credit. It also hides the product that was dropped. The assistant-by-assistant view shows where the error concentrates. Without that split, a team can fix content that was never the problem.

These findings frame the next question. A mention can be present and still be wrong, and the error takes a few repeatable forms.

Four ways a mention gets credited to the wrong company

A mention can carry the right name and the wrong facts. These mismatches are worth tracking because a citation to a business page does not guarantee the answer describes that business. Four patterns recur, and each shows up in the answer text itself, which is what makes them checkable.

First, a namesake in a different category or city. The assistant returns the correct brand string and attaches services from another company with the same name. The observable symptom is a plumber described as offering roofing, or a Chicago branch given a Phoenix address. The answer contains no signal that two entities were merged. The buyer sees one coherent company that does not exist.

Second, a brand whose name is also a common word or a fictional character. The answer resolves the string to the dominant entity in its training data. A company named “Atlas” receives facts about the Titan or a map product. The symptom is a wrong parent company or a category the business does not operate in. In comparison prompts, this produces a verdict that credits one company’s feature set to another. See AI comparison prompts X vs Y verdict.

Third, a company and its product treated as separate entities. The answer names the product and omits the maker, or assigns the product to a competitor. The symptom is a product credited without its maker. The buyer learns the product name and searches for it, then lands on a different vendor. This pattern appears in category prompts where the product has stronger anchor text than the company.

Fourth, sibling locations whose facts get attached to the wrong branch. Multi-location businesses share brand names and service lists. The answer pulls hours, phone numbers, or specialties from one branch and applies them to another. The symptom is a correct brand with the wrong city or the wrong service mix. Location pages with near-duplicate copy make this pattern more frequent. See AI visibility by location.

These four patterns share one cause: the assistant has no reliable join key between the name in the prompt and the entity in its index.

Why entities merge: weak anchors and conflicting join keys

Retrieval does not look up a brand by name alone. The assistant builds a candidate entity from a set of join keys: legal name, domain, address, phone, category, and knowledge identifiers such as a Wikidata QID or Google Knowledge Graph MID. It then scores evidence against that candidate record. A domain-anchored canonical string gives the resolver a stable key. A name on a directory page gives it a string that many businesses share.

When a brand has no domain-anchored canonical string, every source becomes a weaker anchor. A review page lists “Smith Plumbing” at 14 Oak Street. A franchise page lists “Smith Plumbing” at 88 Pine Road. A wiki entry mentions both in one paragraph. The index stores that paragraph as one passage. The resolver sees one name and two addresses. It has no join key that separates the two records. The entities merge.

Conflicting facts across sources push the same outcome. One directory lists phone A and category “plumber.” Another lists phone B and category “HVAC contractor.” The model reads inconsistent evidence against one candidate record. It responds with a merged summary, or it hedges with a generic line about services. Both outcomes weaken attribution: the answer carries the name with facts from the merged record or a generic service line. When the cited source cannot be tied to the business record, the case is an attribution failure.

The entity can also be re-resolved mid-conversation. A follow-up turn rebuilds retrieval with new tokens from the user. The first answer names a company at the Oak Street address. The second question asks about emergency fees. If the new retrieval returns the Pine Road passage, the assistant answers about a different same-name company. The mention count from turn one does not attach to turn two. That behavior is documented in the follow-up question pattern.

Pricing questions show the same mechanics. Two same-name firms with different price lists in the index create a collision. The assistant blends the numbers or cites the wrong source. See the pricing question retrieval pattern. The join key problem is the root.

Before counting a mention, test the name against the domain anchor and the cited passage. That test is what separates a true attribution from a same-name collision.

Testing a mention before you count it

The test has three checks. Run them on a single answer before the name enters any visibility count.

First, read the sentence around the name. Check the stated category, city, and services against your business. If the answer says “Northside Plumbing, a Dallas emergency plumber” and your record is Northside Plumbing in Tulsa doing commercial drain work, the surrounding claim points at another entity. That mention is foreign. If the sentence matches category and city but lists a service you do not offer, the label is ambiguous. A full match across category, city, and services supports an owned label.

Second, check the cited domain. Open the citation and compare it to your registered domain. A citation to your site plus a passage that describes your business supports owned. A citation to a namesake’s site, a directory page for another company, or a social profile with the same name points to foreign. When the answer carries no citation, the label stays ambiguous until another check resolves it. This is the domain anchor from the previous step.

Third, re-ask with an explicit disambiguator. Add the city, the founder’s name, or a product line. Then compare the two answers. If the same name appears with the same details and the same cited domain, the label is owned. If the name disappears or gets replaced by a different entity with the same name, the label is foreign. If both answers keep the name but attach different cities, services, or domains, the label is ambiguous.

The output is an attribution label per mention, recorded next to the position the name held. “Owned at position 2” and “ambiguous at position 2” produce different readings of the same shortlist. The claim-level pass is where the label gets its evidence. The sentence, the domain, and the disambiguated re-ask supply the proof. This procedure is also the matching step inside a brand accuracy audit, which depends on tying claims to the right business.

A set of answers still needs a rate. If foreign and ambiguous mentions stay in the numerator, the rate measures name collisions alongside real visibility.

A contaminated rate hides a real gap

A foreign mention enters the numerator when an AI assistant returns a business name that matches the tracked entity in text only. The business does not own the answer: no owned domain or source citation supports it, and the mention cannot be traced to a source the business controls. In the buying conversation, the buyer sees a different company or a name shared by several firms. The report records visibility for the business. The buyer records a shortlist that does not include the business.

That mismatch has a cost. A run of foreign mentions can hold an aggregate score flat while the business is absent from the prompts that matter. The score shows a steady mention rate across the tracked set. The buying conversation shows no recommendation for high-intent questions such as emergency service and local availability. The false positive delays repair because the team sees a stable metric and schedules no intervention. In a quarterly review cycle, the gap surfaces after the quarter closes. The fix ships in the next quarter. Re-measurement lands one quarter after that. The delay runs to a quarter or more.

A mention and a recommendation are different objects. A mention is a string in an answer. A recommendation carries a reason a buyer can act on: a service match and a cited source. AI assistants with retrieval, such as ChatGPT and Perplexity, surface citations in answers, and buyers use those citations to decide which name to contact. A foreign mention supplies no owned source and no buyer-actionable reason. It adds to a count without adding to the shortlist. The AI recommendation verification gap describes this distance between being named and being chosen.

A report built on mention and citation data surfaces a contaminated numerator as a visibility signal, and that signal is useful only after the entity is separated. A mention tied to another firm’s domain or another firm’s address belongs to that firm. It stays in the report only if the report tracks name collisions. That is the repair: remove foreign mentions from the numerator, then check whether the remaining mentions attach to the right entity.

Separating the entity: canonical name, domain anchor, disambiguating facts

The entity problem starts with the string. A model builds a join between a name, a domain, a category, and a set of facts. If the same business appears as “Acme Plumbing”, “Acme Plumbing Co.”, and “Acme Plumbing & Drain” across its homepage, Google Business Profile, Yelp, and schema.org markup, the model holds three weak records. Pick one canonical entity string. Use it identically in the site title, footer, About page, profile bios, directory listings, and structured data. The string becomes the stable label.

Anchor that label to the domain. The canonical string should appear next to the domain on every owned surface, and the domain should be the URL in sameAs and mainEntityOfPage properties. This gives the model a join key that survives directory truncation and profile drift. A directory can drop the legal suffix. A profile can add a keyword. The domain anchor keeps the record attached to the right business.

State the disambiguating facts on the site. Category, service area, ownership, and product lines belong in plain text and in structured data. If another “Acme Plumbing” exists in a neighboring county, an explicit service area and ownership statement prevent the model from merging the two records. Product lines do the same work at the entity level. A company that sells “Acme Water Heaters” and a manufacturer named “Acme” are separate entities. The site should say which one owns the product, which one services it, and which one holds the trademark.

Where a genuine namesake exists, build a disambiguation page. The page names the other entity, states the difference, and links to the correct profile. Then model the parent-child relation between company and product entities in structured data. The company entity gets its own canonical URL. Each product entity gets its own URL and a parentOrganization or manufacturer property pointing to the company. This prevents product mentions from being credited to the namesake.

Corrections travel only when the crawler can reach the page. If robots.txt or a firewall blocks the assistant’s crawler, the canonical string and disambiguation facts stay invisible. Blocking AI crawlers explains how crawler access changes what an assistant can read. Location facts need the same treatment: a service area statement on the homepage and a location page with matching entity data attach the business to the right geography. A name collision shows up as a mention tied to a foreign domain, so the numerator cannot be separated until the entity string and the domain anchor are fixed. A fresh pass over the same prompts then shows whether anything moved.

Re-measuring attribution after the entity fix

The location work changes what a crawler can read. Re-running the same prompt set produces the comparison. Keep the prompts identical and compare the new output to the prior pass. A raw mention rate alone hides the most common failure: the assistant says a name, and the name is not your business.

Report the owned, ambiguous, and foreign split next to that raw mention rate. Owned means the assistant names your business and attaches the correct entity. Ambiguous means the string matches your name while the entity link is unclear. Foreign means it names a different business, including a competitor with a similar name. The raw rate counts all three. The split shows which one moved. If the raw rate rises while foreign mentions rise, the prompt set captured a different business.

Two clocks govern the correction. Retrieval-layer records update after a crawl and an index refresh. A homepage service area statement and a location page with matching entity data enter that layer when the assistant’s crawler reaches them. Model recall facts hold until a training update. A fact baked into recall does not change when the page changes. That difference explains a result that looks inconsistent: the same attribution fix lands on one assistant this week and leaves another assistant unchanged. Do not read one assistant’s answer as a forecast for the rest. A citation half-life describes how retrieval evidence loses influence over time, while recall facts decay on a slower, stepwise schedule.

Log the label per prompt and per model on every pass. A single monthly mention rate collapses these differences. A pass-level log keeps the prompt, the model version, the date, and the attributed entity together, and shows whether a fix moved owned mentions or only shifted ambiguous ones.

Attribution is a labeling step that runs before counting. A mention rate is only as reliable as the entity resolution underneath it. If the resolver attached a competitor’s record to your brand name, the count was wrong at the source, and no downstream analysis repairs it.

Take the pass-level log and produce two outputs per model version. First, a split count: owned mentions named your record, foreign mentions named a different entity on the same prompt, and the remainder named no business in the category at all. A single 40% mention rate hides the difference between a prompt where the assistant picked the wrong plumber and a prompt where it picked none.

Second, a named cause for every foreign mention. Write it in plain words: same-name business in another state, franchise location mismatch, an old brand name still circulating in press coverage, a directory page listing a competitor under the same category term. The cause decides the fix, and most fixes here are identity work. A name collision needs disambiguating attributes repeated where assistants read them, such as street address, license number, service area, founding year. A retired brand name needs the old string consistently marked as former. A franchise needs a location-qualified name in every listing that carries it.

Set the expectation before spending on any of it. A canonical string and a disambiguation page change the probability that the resolver lands on your