Răspuns scurt: entity resolution este problema reală în financiar când brand, legal entity, product, plan sau market sunt confundate în sursele publice. Nu este o explicație universală pentru ranking slab sau citări instabile. Google documentează Organization și Product structured data, dar nu publică un entity-resolution score. Diagnosticul trebuie să identifice ce entitate este descrisă, cine deține claim-ul și în ce perioadă este valabil.
Failure mode 1: brand și legal entity sunt tratate ca identice
Un brand poate fi operat de entități juridice diferite pe piețe diferite. Dacă registry-ul păstrează doar brandul, terms și product ownership pot fi atribuite greșit.
Failure mode 2: product și plan sunt amestecate
Un produs poate avea mai multe plans sau tiers. Plan limits nu trebuie ridicate la nivelul întregului produs.
Failure mode 3: market-ul lipsește
Aceeași ofertă poate avea rates, fees și eligibility diferite între țări. Product identity fără market context este insuficientă.
Failure mode 4: rebrand creează entități duplicate
Numele vechi și nou apar simultan ca active, deși relația este historical/legacy.
Failure mode 5: issuer și distributor sunt confundați
Un partener poate distribui un produs fără să fie legal issuer sau product owner.
Failure mode 6: comparison site devine source of truth
Un comparator poate fi util pentru discovery, dar nu trebuie să definească oferta curentă dacă first-party owner există.
Failure mode 7: terms și marketing se contrazic
Product page spune o condiție, terms alta. Problema este first-party governance înainte să fie external entity resolution.
Failure mode 8: aliases nu au effective dates
Numele istorice pot fi legitime, dar trebuie contextualizate.
Failure mode 9: structured data descrie altă entitate decât pagina
Markup-ul nu repară contentul contradictoriu și trebuie să reflecte entitatea reală.
Failure mode 10: acquisition rescrie istoria
După o achiziție, vechile documente pot rămâne corecte istoric. Nu le actualiza ca și cum noua entitate ar fi existat mereu.
Failure mode 11: product lifecycle este ignorat
Retired, legacy-serviced și active sunt stări diferite. Un produs retras poate rămâne relevant pentru servicing.
Failure mode 12: un tool score înlocuiește auditul
Un scor fără metodologie nu poate spune ce identity edge este greșit.
Decision tree reproductibil
- Este vorba despre brand, legal entity, product, plan sau market?
- Există canonical name și owner?
- Aliases au status temporal?
- Product-market relation este explicită?
- Issuer/distributor relation este corectă?
- Lifecycle status este actual?
- Terms și product page corespund?
- Structured data reflectă pagina?
- External profiles prioritizează aceeași entitate?
- Conflictul este material sau cosmetic?
- Expected state are source adecvată?
- Finding-ul are owner și criteriu de închidere?
Cum construiești registry-ul
Păstrează entity ID, type, canonical name, aliases, parent relation, product relation, market, owner URL, lifecycle și `last_verified`.
Cum tratezi legal entity
Nu afișa detalii juridice fără relevanță pentru utilizator, dar păstrează intern mapping-ul necesar pentru terms, servicing și disclosures.
Cum tratezi products și plans
Product este containerul, plan/tier descrie variația. Păstrează relația și evită să copiezi limits de plan în content generic despre produs.
Cum tratezi mergers
Versionează registry-ul. Păstrează historical aliases și effective dates. Nu forța un singur nume peste toate arhivele.
Cum tratezi partnerships
Partner, affiliate, distributor, issuer și service provider trebuie să fie relation types distincte.
Cum tratezi external profiles
Selectează sursele relevante pentru buyer journey și păstrează control status. `External unresolved` nu este internal failure.
Cum tratezi product retirement
Decide dacă pagina rămâne pentru servicing, migrează spre replacement sau se retrage. Identity mapping trebuie să păstreze legătura cu produsul succesor fără a pretinde equivalență perfectă.
Cum tratezi missing data
Folosește `unknown` sau `not applicable`. Absența unui profile nu este automat conflict.
Prioritizare
P0: legal/product identity greșită cu impact material. P1: market, lifecycle sau terms relation stale. P2: external profile conflict. P3: variație cosmetică.
Cum verifici după fix
Reverifică registry, product owner, terms, structured data, internal links și external critical profiles. Dacă doar un strat este corectat, finding-ul poate rămâne deschis.
Cum măsori
Identity conflict rate, product-market consistency, relation integrity, owner coverage, lifecycle lag și regression rate.
Când entity resolution chiar este problema
First-party este crawlable și actual, dar brand/product/legal entity relations se contrazic material.
Când este explicație comodă
Pricing este stale, product page este neclară sau canonical/indexability este defectă. Repară cauza directă înainte.
Criteriu de oprire
Auditul intră în monitorizare când P0/P1 sunt închise, lifecycle triggers funcționează și registry-ul poate explica relațiile fără contradicții materiale.
Cum tratezi products white-label
Un produs poate fi oferit sub brandul unui partener, în timp ce issuerul, servicing entity și contractual owner sunt diferite. Registry-ul trebuie să păstreze toate relațiile și să indice ce nume este public pentru fiecare suprafață. Nu transforma distribuția white-label într-o singură entitate doar pentru consistență vizuală.
Cum tratezi schimbarea servicing entity
După migrarea unui portofoliu, brandul și produsul pot rămâne neschimbate, dar servicing entity se schimbă. Păstrează effective date și verifică terms, support pages și disclosures. Un model de entity resolution fără această dimensiune poate arăta „curat” și totuși să trimită utilizatorul la ownerul greșit.
Cum tratezi identificatorii interni versus publici
Product IDs și legal entity IDs pot fi stabile intern chiar dacă numele public se schimbă. Folosește identificatorii pentru continuitate și aliases pentru prezentare. Această separare reduce duplicate entities la rebrand și face auditul istoric reproductibil.
Claim ledger
- FACT/EVIDENCE: Google documentează Organization și Product structured data.
- PRACTITIONER GUIDANCE: financial entity resolution trebuie să separe brand, legal entity, product, plan și market.
- INFERENCE: relation consistency poate reduce ambiguity și rework.
- NOT PROVEN: un entity-resolution score universal sau efect direct asupra ranking/citărilor AI.
Concluzie
Entity resolution în financiar este o problemă de identitate și relații, nu un scor. Dacă brandul, produsul, piața și entitatea contractuală pot fi explicate coerent și versionat, ai o bază mult mai solidă pentru Search și orice sistem extern.
Surse revizuite
- Google Search Central, Organization structured data: https://developers.google.com/search/docs/appearance/structured-data/organization
- Google Search Central, Product structured data: https://developers.google.com/search/docs/appearance/structured-data/product-snippet
- Google Search Central, canonicalization: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls