Acasă › Blog › Entity resolution: sistem operațional pentru echipe de eCommerce
Entity Identity & Commerce Operations

Entity resolution: sistem operațional pentru echipe de eCommerce

Razvan G. Niculae · 5 min citire · actualizat 27 septembrie 2026

Răspuns scurt: entity resolution în eCommerce trebuie tratată ca infrastructură de date editoriale: seller, brand, produs, familie de produs și variantă trebuie să aibă identități stabile, iar feed-urile, paginile și structured data să reflecte aceeași realitate. Google documentează Product și Organization structured data ca tipuri distincte. Un sistem operațional bun nu urmărește un scor de „entity authority”; urmărește conflictele, ownership-ul și timpul de rezoluție.

Precondiția: registry canonical

Fiecare produs critic trebuie să aibă o înregistrare cu:

  • nume canonical;
  • brand;
  • manufacturer când diferă;
  • SKU/GTIN unde există;
  • variantă;
  • canonical URL;
  • categorie;
  • lifecycle status;
  • owner intern.

Registry-ul trebuie să fie sursă pentru QA, nu încă un document manual care poate deveni stale.

Rolurile entităților

Nu combina:

  • sellerul cu producătorul;
  • familia de produs cu varianta;
  • brandul cu numele companiei atunci când sunt diferite;
  • product review cu seller review.

Această separare este baza oricărei implementări ulterioare.

Etapa 1: ingest validation

La importul catalogului, verifică identificatorii, numele și variant mapping. O eroare upstream se poate propaga în mii de pagini.

Blochează sau marchează pentru review valorile imposibile, duplicatele și schimbările neașteptate de brand/model.

Etapa 2: page generation rules

Nu genera URL separat pentru fiecare atribut minor. Definește când o variantă merită pagină proprie și când trebuie reprezentată pe pagina principală.

Această regulă trebuie să țină cont de diferențele reale pentru utilizator și de canonicalization.

Etapa 3: structured data alignment

Product markup descrie produsul/oferta. Organization markup descrie organizația. Datele din markup trebuie să corespundă conținutului vizibil.

Dacă o proprietate nu poate fi susținută, elimin-o în loc să o ghicești.

Etapa 4: feed reconciliation

Compară periodic website-ul cu feed-urile comerciale. Caută:

  • preț diferit;
  • disponibilitate diferită;
  • nume/variantă diferite;
  • URL greșit;
  • brand mapping greșit.

Orice conflict material primește owner.

Etapa 5: review mapping

Review-urile trebuie legate de entitatea potrivită. Dacă o generație nouă păstrează același nume comercial, nu transfera automat toate review-urile ca și cum produsul ar fi identic.

Păstrează model/version context acolo unde experiența poate fi diferită.

Etapa 6: external profile registry

Mapează marketplace-urile și profilele care contează. Nu inventaria tot internetul.

Pentru fiecare profil notează:

  • entitatea descrisă;
  • URL;
  • controlabil sau nu;
  • last verified;
  • conflict status.

Etapa 7: incident workflow

Când apare un conflict P0/P1, definește pașii:

  1. identifică source of truth;
  2. corectează first-party;
  3. corectează feed-ul;
  4. propagă spre suprafețele controlabile;
  5. reverifică;
  6. marchează external unresolved unde nu ai control.

Un ticket deschis nu este un finding închis.

Etapa 8: regression set

Păstrează produse dificile ca test set: multe variante, bundle-uri, rebranduri, produse retrase, modele cu nume similare.

După schimbări de catalog, rulează regression checks pe acest set.

Etapa 9: metrics

Urmărește:

  • first-party conflict rate;
  • feed conflict rate;
  • variant mismatch rate;
  • external critical-profile conflicts;
  • time-to-resolution;
  • recurrence rate.

Aceste metrici produc acțiuni clare.

Etapa 10: governance

Definește cine deține naming conventions, variant rules, redirects și schema. Un sistem fără ownership central va recrea aceleași probleme în echipe diferite.

Versionează regulile și schimbările materiale.

Acceptance criteria

Sistemul este sănătos când:

  1. produsele critice au registry;
  2. seller/brand/manufacturer sunt separate;
  3. variant mapping este explicit;
  4. canonical rules sunt documentate;
  5. structured data reflectă pagina;
  6. feed conflicts materiale sunt sub control;
  7. reviews sunt mapate corect;
  8. profilele externe critice au status;
  9. incidents au owner și evidence de închidere;
  10. regression suite există.

Rollback și limitări

Dacă o schimbare de mapping produce masiv URL-uri greșite, oprește pipeline-ul afectat și revino la ultima regulă validată. Nu încerca să „repari” downstream mii de pagini înainte de sursa erorii.

Stop condition

Când conflictele materiale sunt sub pragul acceptat, recurrence scade și regression set-ul trece, sistemul intră în monitorizare. Entity work nu trebuie să devină o căutare infinită de mențiuni.

Release gate pentru produse noi

Înainte ca un produs să intre în catalogul public, verifică obligatoriu numele, brandul, manufacturerul, identificatorii disponibili, variantele și URL-ul canonical. Feed-ul comercial și structured data trebuie generate din aceeași identitate aprobată sau reconciliate înainte de publicare.

Acest gate previne mai multe clase de defecte decât o curățare ulterioară: review-uri atașate greșit, profile externe create cu nume diferit și duplicate URL-uri greu de consolidat după indexare.

Ownership pe sursa erorii

Când găsești un conflict, marchează sistemul care l-a introdus: PIM, CMS, feed transform, marketplace sync sau editare manuală. Repararea doar pe pagina finală lasă cauza activă. După incident, adaugă un regression check în componenta care a produs eroarea.

Condiție de promovare a regulilor

O regulă de mapping devine standard doar după ce trece regression set-ul și nu introduce conflicte noi în feed, pagini sau review association. Versionează regula, păstrează ownerul și tratează orice schimbare de model de produs ca o nouă evaluare, nu ca o simplă excepție manuală.

Claim ledger

  • FACT/EVIDENCE: Google documentează Product și Organization structured data separat și canonicalization ca mecanism distinct.
  • PRACTITIONER GUIDANCE: registry + reconciliation + regression transformă entity resolution într-un proces operabil.
  • INFERENCE: identitatea coerentă reduce conflictul între suprafețe care consumă aceleași date.
  • NOT PROVEN: un scor universal de entity authority folosit de Search sau sisteme AI.

Concluzie

Entity resolution eCommerce nu este o tactică GEO. Este o disciplină de date, ownership și release engineering editorial. Când aceeași identitate curge corect prin pagini, feed-uri, reviews și profile externe, Search și sistemele AI primesc o bază mai coerentă fără ca echipa să inventeze semnale speciale.

Surse revizuite

Razvan G. Niculae
Marketing & AI Transformation Executive · Profil executiv