Why EAN matching is giving you few or wrong matches

Back to overview

Our solution

Your benefit

If you run an EAN-based business and you're benchmarking competitors, you've probably run into one of two frustrating outcomes, sometimes both at once. Either you don't have enough matches to draw reliable conclusions from, or the matches you do have are wrong: a single unit compared against a multipack, a 1-liter product compared against a 5-liter one, a match that looked solid on paper but leads to a pricing decision that turns out to make no sense.

Both problems come from the same root cause: EAN is treated as a simple, exact key, when in practice it behaves more like a strong but imperfect signal that needs to be handled carefully.

Why doesn't matching on EAN alone give you enough matches?

The most basic reason is coverage. EANs are frequently missing, inconsistently published, or simply absent on competitor product pages, particularly for private-label ranges, bundles, and regionally specific assortments. If your matching logic requires an EAN to be present on both sides to even attempt a comparison, every product where a competitor omits it silently disappears from your benchmark, even when it's exactly the kind of product you most need visibility on.

The deeper reason is structural. Private-label products are, by definition, retailer-specific: your own private-label toothpaste and a competitor's equivalent private-label toothpaste were never going to share an EAN, because they're genuinely different products manufactured under different labels. The same applies to generic, low-differentiation categories like USB cables, phone cases, or basic kitchenware, where dozens of near-identical products exist across brands with no shared identifier connecting them at all. If your customers care about how you're priced against these comparable, not identical, products, EAN-only matching structurally can't answer that question, no matter how well it's implemented.

Why do the matches you do have sometimes turn out to be wrong?

Assuming EAN is present, it still isn't a guaranteed clean key. A few patterns show up constantly in real catalogs:

Multipacks are one of the most common pitfalls. It's routine for a 3-pack or 6-pack to be listed under an EAN that's identical to, or barely distinguishable from, the single unit's EAN. An exact-match algorithm has no way of knowing this and will happily compare your single unit's price to a competitor's 6-pack price, producing a benchmark number that looks precise and is commercially meaningless.

Package and volume variants create the same failure in a different shape. Paint sold in 1, 5, and 10-liter tins, or detergent in 500ml, 1L, and 5L bottles, typically does carry a distinct EAN per size, which helps, but only if the matching logic actually reads and compares that volume as an explicit attribute rather than assuming "same product line" automatically means "same size."

Manual data entry and legacy product feeds introduce simple errors: a mistyped digit is enough to either produce a false match against an unrelated product or, more often, no match at all, since the two EANs now differ by one character with no obvious reason why.

So how should EAN actually be used in a matching pipeline?

Treat it as a strong signal to anchor on, not an infallible key to trust blindly. In the language of data matching, this is a case for combining deterministic matching, exact agreement on an identifier, with additional attribute-level comparison rather than relying on deterministic matching alone. In practice, that means every candidate match found via EAN still gets checked against secondary attributes: brand, pack size, unit of measure, and title similarity, before being accepted as a valid comparison. A match that agrees on EAN but disagrees sharply on pack size or brand is a signal that something upstream is wrong, not a match to accept at face value.

It's also worth building in a validation step against an authoritative source. Cross-referencing a suspicious-looking EAN against GS1's own registry data can confirm whether it's genuinely registered to the brand in question, catching mistyped, reused, or fraudulent codes before they ever reach a pricing dashboard. Few in-house pipelines include this step, which is exactly why bad EANs so often flow straight through into benchmarks unnoticed.

How do you match products that don't share any identifier at all?

For private-label ranges and generic, attribute-heavy categories, matching has to be based entirely on product attributes and descriptions rather than a shared code, which is a well-studied problem in its own right, usually referred to as entity resolution or record linkage.

The general approach works in stages. First, blocking narrows an otherwise unmanageable number of possible product pairs down to a realistic candidate set, for example by grouping on category and brand before comparing anything in detail, since comparing every product against every other product simply doesn't scale. Within each candidate group, similarity is then scored using a combination of techniques: simple string-distance measures like Levenshtein or Jaro-Winkler for catching near-identical titles with minor spelling differences, TF-IDF-style weighting for comparing longer descriptions where certain words matter more than others, and increasingly, embedding-based models (transformer-based language models trained specifically for product matching) that capture semantic similarity even when two listings describe the same product in noticeably different words. For visually distinctive but poorly described products, incorporating product images alongside text attributes has been shown to meaningfully improve match quality over text alone.

The output of this process isn't a binary match or non-match for free. It's a similarity score that still needs a threshold, and setting that threshold is itself a genuine trade-off, which brings us back to the same tension EAN-based matching runs into, just from the other direction.

How do you balance enough matches against accurate matches?

Every matching approach, EAN-based or attribute-based, ultimately has a dial that can be turned stricter or looser, and both directions carry a real cost.

Turn it stricter, and false matches drop, but so does coverage: entire sub-categories become sparsely matched or empty, leaving pricing and commercial teams working from an incomplete view of the market without necessarily realizing which segments are the blind spots. Turn it looser, and coverage improves, but so does the risk of comparing products that only resemble each other on the surface, which is arguably the more dangerous failure mode, since a wrong match doesn't just create a gap, it actively feeds a pricing decision with misinformation.

There is no single correct threshold. The right setting depends on the category (a commodity category like basic cables tolerates looser matching better than a category where small spec differences genuinely change value, like electronics or appliances), and it needs to be revisited as assortments evolve, not set once and forgotten. Many mature matching pipelines also route borderline-confidence matches to a human review queue rather than forcing a fully automatic yes/no decision, using manual review specifically where the algorithm itself is uncertain, which is a far more efficient use of human attention than reviewing everything or reviewing nothing.

Build it yourself, or have it managed?

None of this is conceptually out of reach for a capable data team. Entity resolution is a well-documented field, and libraries and techniques for it are publicly available. What's harder to sustain is the ongoing tuning this requires: recalibrating thresholds per category as your own and competitors' assortments shift, catching new patterns of bad data as they appear, retraining or adjusting matching logic as new product types enter the catalog, and validating that accuracy holds up over time rather than quietly decaying as the underlying data changes shape.

That ongoing calibration work, done well and per category rather than generically, is usually where in-house efforts either stall or start consuming far more data science time than anyone budgeted for at the outset.

At Competify, this is exactly the discipline we run for clients: EAN used as the anchor wherever it's available, enriched and cross-checked against brand, pack size, and volume; attribute and text-based matching built and tuned specifically for categories and private-label ranges where no shared identifier exists at all; and thresholds actively managed per category to keep the balance between coverage and accuracy right as assortments change. If getting this right for your own catalog sounds like the gap you're currently stuck on, feel free to reach to contact us for a free introduction meeting.

Want to know how we work?

We’ve designed a simple 3-step approach for easy onboarding.

Get inspired

We build and maintain custom webscrapers that turn any website into structured data and insights.

Discover more inspiration

Discover insights, trends and company news.

All inspiration
Insights
Why EAN matching is giving you few or wrong matches
Discover how to build a matching pipeline solid enough to base pricing decisions on.
Read more
Insights
Why your web scraper keeps breaking
What it takes to keep your scraper reliable: validation, an automated repair path, and a proxy strategy that adapts.
Read more
Insights
Competitive monitoring in telecom: 7 principles that make the difference
Discover why competitive monitoring in telecom is so difficult and how we solve it
Read more
Ready to outsmart your competitors?
Do you have a specific business challenge to solve or simply want to brainstorm on ways to outsmart your competition? Get in touch!
Bas Swierstra
Managing Partner