In eCommerce, "entity resolution" can explain some real confusions: two products with similar names, mixed variants, namesake brands or marketplaces that keep old data. But the term can also become a convenient excuse for simpler issues like an incomplete feed, wrong canonicals, out-of-date inventory, or poor product pages.
A useful diagnosis should show when identity is the likely cause and when it must be looked for elsewhere. Don't start from the markup. It starts from the observed error.
Define exactly the confused object
Is it the parent product, a variant, the brand, the store or the category? Note the name, SKU, GTIN/MPN if applicable, URL and brand. Without these benchmarks, two variants may be treated as the same entity, or the same product may appear twice under different names.
For large catalog, use a sample that includes single products, variants and cases with similar names.
Check the feed before copying
If the feed is sending a different brand than the product page or the identifiers are missing, fix the commercial source first. Merchant listing documentation recommends consistent product, offer, price and availability data.
A better editorial description cannot make up for a wrong SKU or inconsistent variant relationship.
Control the ProductGroup - Variant relationship
For products with sizes, colors or configurations, check that variants have unique identifiers and that the relationship to the group is clear. Google documents the ProductGroup and variant properties in structured data.
Don't assume that a single URL is always wrong or right. Check the actual architecture of the catalog and how the selections are represented.
Compare product names between systems
PIM, feed, product page, structured data and marketplace can have different versions of the name. Some differences are legitimate, but brand and model should not conflict.
Construct a matrix for the audited sample. If the same variant has three incompatible names, the finding is of data governance before it is of external entity resolution.
Check canonical and duplicates
Duplicate pages, filters and parameters can produce multiple URLs for the same product. The audit should include canonical and indexing rules. If the system encounters competing versions of the same page, entity clarity may be affected.
Do not attribute any duplication to AI. It's an SEO and architecture issue worth solving independently.
Separate lack of identity from lack of availability
An out of stock product is still the same product. If the response says not available, don't automatically mark entity failure. Check the commercial status at the time of observation.
In quick catalogs, save price and stock along with catches. Otherwise, you'll be comparing responses to a state that no longer exists.
Reviews do not define the product
Reviews may mention nicknames, old builds, or experiences with a particular variant. Do not use these texts as the primary source for product identifiers.
If an answer confuses two models due to mixed reviews, investigate how the reviews are related to variants and groups.
When the problem is actually the content
If the page doesn't explain the difference between the models, if the specs are missing, or if the images don't match the variant, entity resolution may just be the symptom. Complete the basics before sophisticated tactics.
A simple test: Can a human reviewer distinguish the variants using just the page and the feed? If not, automated systems are not the main problem.
Decision tree
- Is the confused entity defined by stable identifiers?
- Are the feed and page using the same brand and model?
- Are the variants correctly linked to the group?
- Don't canonicals and URLs compete unnecessarily?
- Is the price and stock current?
- Do the specifications and images distinguish the products?
- Do third-party sources use old data or other names?
- If the first six checks pass and confusion recurs, entity resolution becomes a stronger hypothesis.
Prioritize by commercial impact
A confusion between two colors may have less impact than attributing an incompatibility or the wrong price. Use materiality to prioritize.
For important findings, keep owner and correction path: PIM, feed, product page, markup, marketplace or other source.
Test a sample with difficult products
Do not build the audit only from best sellers with clean data. Includes products with many variants, similar names, bundles, rebranded models, and items that have been withdrawn and replaced. These cases show whether the identification rules hold up in the real catalog. For each example, keep the identifiers, canonical page, and commercial source. If the findings only occur in cases where internal data is inconsistent, remediation should begin in the PIM or feed, not in a generic entity optimization campaign.
Also check the fix path
For each finding, note the system in which the source must be corrected: PIM, feed, product page, structured data, canonical or marketplace. This mapping is important because the same visible error can have different origins. After the change, reread the source and page before repeating the external observation. If the problem reoccurs, don't assume the patch didn't work; first check if the change has propagated to all relevant surfaces.
Claim ledger
- FACT/EVIDENCE: Google documents Product, Offer and ProductGroup for representing products and variants in its experiences.
- PRACTITIONER GUIDANCE: systems matrix and diagnostic tree are proposed methods to separate identity problems from catalog problems.
- INFERENCE: More coherent identifiers and relationships can reduce ambiguity, but the effect on AI systems needs to be verified separately.
- NOT PROVEN: that structured data solves universal entity resolution or directly produces conversions.
