Two Companies Named "BrandScope" Are Fighting Over AI — and Google AI Can't Tell Them Apart
Last week, Google's AI Overview answered "what is BrandScope AI" by describing a different company — wowai.ch, a Swiss brand-evaluation platform. Not us. We're BrandScope (brandscope.dev), an AI-visibility monitor.
Then I found brandscopeai.com — a direct competitor with nearly our exact name, tracking the same thing we do (brand mentions in AI platforms), at similar prices ($29-299 vs our $39-399).
Three companies, two of which are named BrandScope, all competing for one AI identity. Google can't tell us apart. Neither can ChatGPT or Perplexity.
What our data shows
We ran our own brand through the same monitoring we sell:
"brandscope ai" in Google search: we're #1 organic.
Same query in Google AI Overview: it describes wowai.ch. Not us.
Across 6 AI assistants: our own brand gets confused, misattributed, or cited from the wrong entity.
This isn't an edge case. Name collisions are the #1 thing we see when brands run their first scan. Powsight gets confused with PowerSight. Zarek gets recommended over its own competitors. A brand with a common name finds the AI quoting the other company's site.
Why this matters more than mention rate
A mention of your brand by AI is worthless — even harmful — if it's the wrong brand. "Mentioned" and "correctly represented" are different problems:
Mentioned but wrong entity → prospect goes to the wrong company
Mentioned but no source → probably hallucinated, can't be verified
Not mentioned → discoverability problem, fixable
We now split every report into these three buckets, each with its own next step. Because a founder's real question isn't "does AI know my brand" — it's "does AI describe the right brand, correctly, with evidence".
The uncomfortable part
We built a tool to catch brand misattribution, and then discovered our own brand was the victim of it. That's either embarrassing or validating — we're choosing to treat it as validation. The problem is real, it's growing, and every week we see more founders hitting it without knowing.
Check if AI knows your brand — and which one it thinks you are: brandscope.dev
We're BrandScope. The AI-visibility one. Probably.
"We hit the same 'mentioned but no source' problem building a grounding checker for strategy docs — ended up treating 'no source' as its own bucket instead of lumping it with 'wrong', because the fix is completely different (verify vs. correct)."
Oh nice — that's exactly the kind of distinction that has to come out of building one, not from reading about it. We treat "no source" and "misleading" separately too: verify vs correct are genuinely different follow-ups, and lumping them hides which action a team should take. Anything else the grounding checker taught you that's non-obvious?
One that surprised us: "has a source" isn't binary either. A claim can point to a real sentence in the source doc that's just a loose paraphrase, not an actual match — so "cited" and "supported" are different things. We ended up needing sentence-level similarity scoring instead of just checking "does a source exist," because plenty of technically-cited claims weren't actually backed by what they cited.
That's the next layer, and I think you're right that it doesn't stay binary for long. We already split "no source" from "misleading" separately; "has a source" is where our verified bucket sits today — we check existence and source type, but not yet loose-vs-true paraphrase. The cited-but-not-supported case is exactly why that bucket's threshold will have to move from "exists" to "actually backs the claim." Out of curiosity: how are you scoring sentence-level similarity — embeddings, and if so against the generated answer or the claim itself? And what threshold did you land on?
https://www.indiehackers.com/post/two-companies-named-brandscope-are-fighting-over-ai-and-google-ai-can-t-tell-them-apart-35a44663eb
Sorry, that link posted before I finished the thought — since you clearly think about this stuff carefully, we just put the actual tool live if you want to see how it plays out for real. No pressure at all, just thought you might find it interesting given the conversation here.
Congrats on shipping it — glad it's live. Will give it a real look; sentence-level similarity for citation support is exactly the kind of thing that's easy to hand-wave and hard to build. Curious to see how you frame the loose-paraphrase case in the UI.
It's not embeddings — we use character-level (bigram) string similarity between the claim text and the specific source sentence the citation points to, not the generated answer. We landed around 0.15 as the pass-through threshold. Funnily enough, we just found a real edge case in ours this week: entity-swapped claims (same numbers, wrong company name) score higher on bigram similarity than genuine fabrications do, because the sentence structure is nearly identical. So the loose-vs-true-paraphrase problem you're describing isn't just a threshold-tuning issue — it can point in exactly the wrong direction. We ended up adding an explicit proper-noun/number check that overrides the similarity score when they don't match.
That's a genuinely useful failure mode to share — entity-swap is exactly the case where pure text similarity doesn't just under-perform, it over-scores the wrong thing. It's also why our current checks prioritize which entity the source points to before content matching; without that layer, a similarity pass can confidently bless a claim that belongs in the "misleading" bucket. The bigram + proper-noun override combo is a clean guard. One thing I'd be curious about: when the citation points to a URL/sentence that doesn't actually exist (not paraphrase, not swap — just missing), how do you route that? We treat it as its own bucket (verify vs correct vs flag).
Good question, and yes — that's a genuinely separate bucket for us too. A missing/non-existent citation gets caught earlier than the fidelity check even runs: before we compare claim-text vs source-text similarity, we first resolve whether the cited reference actually points to real text in the source at all. If it doesn't resolve — hallucinated paragraph number, phantom sentence, whatever — that's a no_basis flag, not a fidelity failure, because there's nothing to run the similarity/entity-match logic against in the first place.
So the routing ends up close to your verify/correct/flag split: no citation resolves → flag (no basis). Citation resolves and content matches → pass. Citation resolves but entities/numbers don't → escalate/flag (the fix we just shipped). The one thing I'd add: keeping "doesn't exist" and "exists but wrong" as genuinely separate failure modes matters because the fixes are different — one's a retrieval/indexing problem, the other's a semantic-matching problem. Conflating them into one bucket made our error messages useless for a while.
That's a clean split — "doesn't resolve" being a retrieval/indexing problem vs "resolves wrong" being a semantic one is exactly the boundary worth keeping. Conflating them is how error messages end up useless; glad you called it out.
This is a good example of why AI visibility can’t just be measured by counting mentions. If the model recognizes the wrong company, a “successful” mention can actually send potential customers somewhere else. The entity-level attribution feels like the more useful metric here, especially for companies with generic or shared names.
Completely agree — and "entity-level" is the right lens. A generic or shared name is exactly where mention counts go from useful to misleading. It's why we check not just whether there's a source, but which entity that source actually points to — attribution is the metric, mentions are just the raw signal.
Appreciate you pushing on this — this whole exchange (starting from the entity-swap thing) directly led to a second bug getting caught this week: same class of problem, but with role titles and product names instead of company names. Wouldn't have gone looking for it without this thread. Thanks for taking the time.
Glad it had teeth beyond the thread — entity-swap generalizes past company names, and role/product names are the same trap one level over. That's a genuinely useful confirmation for the entity-check side of our work too. Good hunting.
Appreciate that — and it's held up in practice, too. Keeping them separate is what let us ship two different, targeted fixes instead of one mushy one: better retrieval/indexing for the "doesn't resolve" side, and the entity/number token gate for the "resolves wrong" side. If we'd bucketed them together, we probably would've just thrown more LLM calls at both and called it a day — which wouldn't have actually fixed either one.
The name-collision example is a strong reminder that being visible isn't enough if the system is attributing you to the wrong company. The distinction between being mentioned, being correctly represented, and being supported by evidence is especially useful.
Exactly — visibility is table stakes. The real test is whether the model can attribute you correctly, and whether it can point to evidence when it does. Most tools count mentions; almost none verify the citation actually resolves back to you. What's the most surprising attribution mismatch you've come across?
The name-collision example makes the problem much more concrete. It’s easy to see how “being mentioned” can create a misleading signal when attribution is wrong.
Right, that's the trap — it reads as coverage until you realize it's not even about you. Do you think most teams ever catch these attribution errors on their own, or only once something goes sideways?
That’s probably difficult to spot unless someone is actively checking for it. I’d be interested in continuing the conversation — would you be open to sharing the best email to reach you on?
Absolutely — thanks for the great back-and-forth on this. Happy to keep it going off-platform. You can reach me at
support@brandscope.dev
. Happy to talk attribution checks, evidence, or the before/after angle whenever you have something live to point at.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.