Entity resolution în B2B SaaS devine problematică atunci când produsul, compania, suite-ul, edițiile și integrările sunt descrise inconsistent. Un model sau un motor de căutare poate ajunge să combine două produse cu nume similare, să atribuie o funcție companiei greșite sau să folosească o pagină veche pentru un nume rebranduit.
Un experiment bun nu pornește de la presupunerea că markup-ul sau sameAs "rezolvă entitatea". Pornește de la cazuri concrete de ambiguitate, definește o intervenție și măsoară dacă erorile observate scad pe un set stabil de întrebări.
Definește entitățile care intră în test
Construiește o hartă simplă: organizația, produsul principal, modulele, planurile, integrările și eventualele nume istorice. Pentru fiecare element, notează numele canonic, URL-ul principal și relația cu celelalte entități.
Dacă produsul poartă același nume cu firma, scrie explicit asta. Dacă suite-ul conține mai multe aplicații, nu folosi același termen pentru toate fără context.
Identifică erorile reale înainte de intervenție
Colectează exemple în care entitatea este confundată, o funcție este atribuită altui produs, o achiziție este tratată ca brand independent sau o integrare este descrisă ca produs propriu. Păstrează promptul, răspunsul, sursele și data.
Nu include simpla absență a unei mențiuni în aceeași categorie. Entity resolution privește identitatea și relațiile, nu doar frecvența apariției.
Formulează ipoteza
Exemplu: dacă paginile despre organizație și produs folosesc nume coerente, relații clare și referințe stabile, proporția răspunsurilor care confundă produsul cu entitatea concurentă va scădea în setul testat.
Ipoteza trebuie să specifice eroarea și populația. "Vom îmbunătăți GEO" nu poate fi testată.
Alege controlul
Păstrează o familie de pagini sau un produs secundar comparabil fără intervenția principală. Controlul ajută la distingerea schimbării specifice de variația generală a răspunsurilor.
Într-un portofoliu mare, controlul poate fi o altă linie de produs cu identitate deja stabilă. Documentează de ce este comparabilă și unde nu este.
Intervenția 1: clarifică numele și relațiile vizibile
Pe paginile tratate, elimină inconsistențele de nume, explică relația dintre companie și produs și folosește aceleași denumiri în navigation, headings și documentație. Nu supraîncărca textul cu numele brandului; claritatea este mai importantă decât repetarea.
Dacă un produs a fost rebranduit, păstrează contextul istoric acolo unde utilizatorii îl pot căuta, dar fă limpede numele actual.
Intervenția 2: aliniază Organization și SoftwareApplication unde se aplică
Google documentează Organization structured data, iar Schema.org definește SoftwareApplication și proprietăți precum identifier, owner și sameAs. Folosește doar proprietățile care reflectă informația reală și vizibilă.
Markup-ul nu trebuie să introducă relații pe care pagina nu le explică. Dacă ownerul sau identitatea produsului este ambiguă pentru om, JSON-LD nu este un substitut pentru clarificarea paginii.
Intervenția 3: elimină sursele proprii contradictorii
Un knowledge base poate folosi un nume vechi, o pagină de pricing poate folosi numele nou, iar release notes pot avea abrevieri. Aceste contradicții sunt o problemă de provenance internă.
Creează o listă a surselor controlate și reconciliază termenii materiali. Nu rescrie arhivele istorice fără motiv; adaugă context și linkuri către denumirea actuală.
Definește fereastra de observație
Nu evalua imediat după publicare. Păstrează mai multe rulări ale acelorași prompturi într-o perioadă stabilă. Înregistrează release-urile, campaniile și aparițiile media care pot modifica sursele disponibile.
Dacă produsul lansează simultan un feature major, testul de entity resolution poate fi contaminat de interes și conținut nou.
Măsoară eroarea, nu doar mențiunea
Metricile utile includ: numărul de răspunsuri cu entitate corectă, confuzii de produs, relații greșite companie-produs, nume vechi fără context și cazuri neconcludente. Raportează numitorul.
O creștere a mențiunilor fără reducerea confuziilor nu confirmă ipoteza de entity resolution.
Stop rules
Oprește testul dacă schimbi setul de prompturi, dacă produsul este rebranduit din nou, dacă paginile control primesc aceeași intervenție sau dacă nu mai poți verifica sursele. Păstrează rezultatul parțial și descrie de ce experimentul nu mai este comparabil.
Nu ajusta retroactiv definiția erorii doar pentru a obține un rezultat favorabil.
Ce înseamnă succes
Succesul local este o scădere reproductibilă a confuziilor în setul testat, fără apariția unor contradicții noi. Nu înseamnă că entitatea este "rezolvată" universal pe internet.
Repetă experimentul pe o a doua familie de întrebări înainte de rollout mai larg.
Verifică efectul asupra buying committee
După ce măsori confuziile de entitate, verifică și întrebările pe care le-ar pune roluri diferite dintr-un buying committee. Security poate folosi numele produsului altfel decât procurement sau engineering. Dacă intervenția reduce confuzia numai în prompturi de brand, dar nu în cele despre integrare și ownership, succesul este limitat. Raportează pe categorii și păstrează exemplele unde relația organizație-produs rămâne ambiguă. Acest strat ajută echipa să decidă dacă rollout-ul merită extins sau dacă problema este localizată într-o singură zonă de documentație.
Ce păstrezi după experiment
Chiar dacă rezultatul este neconcludent, păstrează harta de entități, lista de confuzii și change log-ul. Aceste artefacte pot deveni baseline pentru următoarea rundă și pot ajuta echipele de sales engineering sau support să folosească denumiri mai coerente. Nu transforma însă documentația experimentului într-o obligație de marketing de a repeta excesiv brandul. Scopul este claritatea relațiilor dintre organizație, produs și module.
Claim ledger
- FACT/EVIDENCE: Google documentează Organization structured data, iar Schema.org definește SoftwareApplication și relații de identitate precum sameAs.
- PRACTITIONER GUIDANCE: designul control/tratament și metricile de confuzie sunt metodologia experimentală propusă aici.
- INFERENCE: denumirile și relațiile mai coerente pot reduce ambiguitatea de entitate, dar efectul trebuie observat.
- NOT PROVEN: că markup-ul Organization sau SoftwareApplication produce direct citări AI sau ranking mai bun.
