Cum găsim scenariile în care concurentul este recomandat, iar noi nu
Nu orice captură cu un concurent recomandat este un gap. Verificăm recomandarea, absența, eligibilitatea, recurența și cauza înainte de a crea conținut.
Scenariul în care un concurent este recomandat, iar brandul nostru lipsește, nu se descoperă prin colecționarea capturilor convenabile. Îl găsim într-o matrice de nevoi reale, apoi verificăm cinci lucruri: entitatea concurentă, forța recomandării, absența tuturor aliasurilor brandului, eligibilitatea pentru constrângerile utilizatorului și recurența observației.
Fără aceste filtre, o absență corectă devine fals „content gap”, un produs-alias este ratat de evaluator, iar trei repetări ale aceleiași întrebări sunt prezentate ca trei oportunități comerciale. Protocolul de mai jos transformă observația într-un registru de scenarii acționabile, cu dovadă și limite.
1. Definiția strictă a scenariului ratat
Într-o celulă de observație avem un candidat brut atunci când un concurent validat este recomandat explicit, iar brandul analizat este absent. Formal:
candidat_gap = concurent_recomandat AND brand_absent
Candidatul devine oportunitate ratată calificată numai dacă brandul era eligibil pentru nevoia, geografia, segmentul și toate constrângerile din scenariu. Eligibilitatea nu se deduce din răspunsul AI, ci din documentație curentă, disponibilitate și adevărul produsului.
Dacă brandul apare, dar nu este recomandat, avem alt eveniment. Dacă este respins explicit, este prezent cu poziție negativă. Dacă un produs sau un alias apare fără numele companiei, avem o problemă de rezoluție a entității. Niciunul nu intră automat în registrul „brand absent”.
2. Recomandarea trebuie demonstrată, nu intuită
Prima poziție într-o listă, un adjectiv pozitiv, o citare sau simpla mențiune nu sunt suficiente. Folosim taxonomia din ghidul mențiune, citare și recomandare. Recomandarea cere o indicație clară că entitatea este potrivită, selectată sau preferată pentru condițiile utilizatorului.
Păstrăm pasajul exact, rolul în răspuns și calificativele. „Analizează și opțiunea B” este considerare. „Pentru echipe cu cerința X, alege B” este recomandare condițională. „B este cea mai potrivită opțiune” poate fi alegere principală. Codebook-ul decide înaintea analizei, nu după ce vedem brandul.
3. Pornim de la jobul clientului, nu de la numele concurentului
Un set format numai din întrebări precum „care este alternativa la Brand B?” va produce inevitabil Brand B și vecinii lui. Acesta poate fi un test confirmator, dar nu măsoară descoperirea spontană. Setul de bază pornește din joburi, criterii și situații reale fără nume de furnizor.
Sursele pot include întrebări din vânzări și onboarding, interviuri, căutarea internă, categorii din Search Console, documentația produsului și constrângeri de achiziție. Nu copiem taxonomia publică a unui concurent. Construim limbajul clientului și păstrăm proveniența fiecărui scenariu.
4. Matricea acoperă etape, persoane și constrângeri
Același produs poate fi relevant la explorare și absent corect la implementare. Construim o matrice pe etape: conștientizare, explorare, shortlist, selecție și utilizare. Adăugăm persona sau tipul organizației, jobul urmărit și constrângerile tari.
Constrângerile pot include țara, limba, bugetul, integrarea, rezidența datelor, certificarea, volumul, modelul de suport sau timpul de implementare. Nu combinăm mecanic toate valorile. NIST descrie designul experimental ca un plan stabilit înaintea rulării, cu obiective, factori și răspunsuri măsurate. Alegem combinațiile plauzibile și documentăm ce rămâne în afara eșantionului.
5. Query fan-out face o singură formulare insuficientă
Google explică faptul că AI Overviews și AI Mode pot folosi query fan-out, adică mai multe căutări asociate pe subteme și surse. Documentația ChatGPT Search spune că promptul poate fi rescris în una sau mai multe interogări țintite și că pot urma căutări suplimentare.
De aceea rulăm familii de formulări naturale, nu o singură propoziție „canonică”. Variațiile păstrează aceeași nevoie și schimbă controlat nivelul de specificitate, ordinea constrângerilor sau vocabularul persoanei. Suprafața, limba, geografia, starea contului și momentul rămân câmpuri de observație, fiindcă pot schimba contextul.
6. Descoperirea și confirmarea sunt două straturi
În stratul de descoperire nu numim nici brandul țintă, nici concurentul. Observăm opțiunile produse spontan. În stratul confirmator putem testa o comparație explicită, o constrângere izolată sau o ipoteză despre eligibilitate. Rezultatele nu se amestecă într-o singură rată.
Schimbarea unui factor ajută diagnosticul local, dar are limite. Ghidul NIST despre one-factor-at-a-time arată că această abordare poate rata interacțiunile. Dacă geografia și integrarea se influențează, avem nevoie de combinații planificate, nu doar de modificări succesive ale unui prompt.
7. Capturăm celula înainte să o interpretăm
Fișa brută include ID-ul scenariului, promptul exact, suprafața și interfața, data și ora, limba, geografia disponibilă, starea contului, răspunsul complet, pasajul de recomandare, citările vizibile și orice eroare de captură. Nu este necesară o captură de ecran dacă textul și metadatele pot fi păstrate mai sigur și mai complet.
W3C PROV-O oferă un vocabular pentru Entity, Activity și Agent, plus utilizare, generare, derivare, revizie și timp. Putem reconstrui ce set și ce regulă au generat un verdict fără să confundăm răspunsul brut cu interpretarea evaluatorului.
8. Rezolvăm identitatea înainte să declarăm absența
Brandul poate apărea printr-un produs, o abreviere, un nume anterior, compania-mamă sau o grafie localizată. Registrul de identitate conține numele canonic și aliasurile permise, dar și relațiile care nu trebuie contopite. Un reseller nu devine automat brandul; două produse ale aceleiași companii pot avea eligibilități diferite.
Aplicăm același standard concurentului. Procesul de identificare a concurenților validează entitatea și rolul în nevoia respectivă. O publicație citată, o integrare sau un produs complementar nu devin concurenți doar fiindcă apar lângă recomandare.
9. Eligibilitatea este poarta care elimină cele mai multe false gap-uri
Pentru fiecare candidat întrebăm: produsul servește jobul exact? Este disponibil în țara și limba cerute? Respectă bugetul și constrângerile obligatorii? Integrarea sau funcția există acum? Segmentul este acceptat? Verificăm răspunsurile în surse primare și le datăm.
Disciplina seamănă cu verificarea substituției din perspectiva clientului. Comunicarea Comisiei Europene privind definirea pieței tratează substituibilitatea cererii și dovezile aferente. Aici împrumutăm doar rigoarea întrebării; auditul nostru nu definește o piață relevantă în sens juridic.
Dacă brandul nu îndeplinește o constrângere tare, absența poate fi corectă. O pagină nouă nu repară indisponibilitatea, lipsa funcției sau incompatibilitatea. Cazul devine „excludere validă” ori este trimis proprietarului de produs, nu echipei editoriale.
10. Verificăm și recomandarea concurentului
Faptul că un sistem recomandă o entitate nu înseamnă că recomandarea este corectă. Descompunem motivele în afirmații și deschidem sursele. Verificăm potrivirea cu nevoia, actualitatea, aria geografică și forța dovezii. O recomandare bazată pe o funcție inexistentă este o problemă factuală, nu dovadă curată a unui avantaj competitiv.
Programul NIST Building Evaluation Probes into Agentic AI urmărește un audit trail care arată ce a fost găsit, unde și cum susține dovada concluzia. Separă faithfulness, completeness și sufficiency. Folosim aceeași idee editorială: o citare poate exista și totuși să nu ducă sarcina afirmației.
11. Funnelul de calificare
Funnelul păstrează respingerile, nu le șterge. O observație trece prin recomandare, identitate, rol competitiv, eligibilitate, dovadă și recurență. La fiecare poartă salvăm verdictul, motivul, evaluatorul și versiunea regulii.
Ieșirile sunt: oportunitate ratată calificată, gap condițional sau limitat la segment, excludere validă, eroare de identitate/măsurare și neconcludent. Același răspuns nu este forțat într-o categorie acționabilă doar pentru a alimenta calendarul editorial.
12. Numărăm scenarii, nu capturi
Trei repetări pe două suprafețe produc șase celule pentru aceeași nevoie. Aceste celule măsoară recurența și variația; nu sunt șase oportunități. Grupăm observațiile după job, etapă, persona și setul de constrângeri care schimbă eligibilitatea.
Dacă vrem să cuantificăm diferența dintre cele două branduri în cohorta astfel curățată, folosim separat protocolul pereche de comparare a vizibilității AI. Aici decizia este anterioară calculului: stabilim dacă scenariul este o oportunitate validă care merită să intre în acel raport.
Scenariul păstrează distribuția: câte rulări recomandă concurentul, în câte lipsește brandul, pe ce suprafețe și în ce ferestre. Nu folosim numai cel mai favorabil răspuns. O observație izolată rămâne indiciu, iar o apariție repetată pe aceeași suprafață nu dovedește generalizare.
13. Exemplu: 22 de capturi devin două priorități
Presupunem 16 familii de scenarii, două suprafețe și trei repetări: 96 de celule. În 22 de celule vedem un concurent recomandat și aparenta absență a brandului. După deduplicarea repetițiilor și suprafețelor rămân opt scenarii candidate.
| Verdict după calificare | Scenarii | Interpretare |
|---|---|---|
| Oportunitate calificată | 3 | Brand eligibil, recomandare validă, absență confirmată. |
| Gap condițional | 2 | Valabil numai într-un segment sau set de constrângeri. |
| Excludere validă | 2 | Brandul nu îndeplinește o condiție obligatorie. |
| Eroare de identitate | 1 | Un produs-alias al brandului era prezent. |
Dintre cele trei oportunități calificate, două se repetă pe ambele suprafețe și în mai multe rulări. A treia apare pe o singură suprafață, iar justificarea recomandării are dovadă slabă; rămâne investigație. Concluzia operațională este două priorități, nu 22 de articole.
14. Recurența are mai multe niveluri
Separăm repetarea în aceeași celulă, recurența între formulări, între scenarii apropiate, între suprafețe și între ferestre de timp. Fiecare extinde altfel concluzia. Cinci răspunsuri identice în aceeași sesiune pot fi mai puțin informative decât două observații coerente în contexte independente.
NIST AI RMF Core cere ca metodele, testele, metricile și limitările să fie documentate și urmărite în timp. Nu stabilim un prag universal. Declarăm pragul de review pentru proiect, păstrăm numitorul și arătăm unde semnalul nu se reproduce.
15. Prioritizăm transparent, fără un scor magic
Fișa de prioritate păstrează separat relevanța comercială, încrederea în eligibilitate, recurența, forța recomandării, calitatea dovezii, riscul unei afirmații greșite și caracterul acționabil. Valorile pot fi scăzut, mediu și ridicat sau clase definite operațional.
„Acționează” cere eligibilitate verificată, eveniment repetat, dovadă suficientă și o cauză pe care o putem aborda. „Proiectează test” acoperă un gap important, dar condițional. „Investighează” păstrează cazurile cu ambiguitate ori surse slabe. „Respinge/arhivează” păstrează excluderile valide și erorile de măsurare pentru a preveni redescoperirea lor.
16. Cauza decide intervenția
Un gap de conținut cere o pagină care răspunde nevoii și constrângerilor cu afirmații verificate. Un gap de discoverability cere crawlabilitate, linkuri interne, canonical clar și informație importantă în text. Un gap de entitate cere relații coerente între brand, produse și aliasuri. Un gap factual cere corectarea sursei de adevăr.
Dacă informația adevărată există, dar nu are documentație primară suficientă, avem gap de dovadă. Dacă produsul nu satisface nevoia, avem product truth: conținutul nu trebuie să pretindă contrariul. Dacă observația nu se repetă, intervenția poate fi doar o remăsurare mai bună.
17. Brief-ul de intervenție păstrează scenariul
Un brief bun conține întrebarea utilizatorului, etapa și persoana, condițiile obligatorii, pasajele observate, entitățile normalizate, dovada eligibilității, cauza ipotetică, paginile existente, afirmațiile permise și interzise, sursele primare și criteriul de succes.
Nu scriem o pagină despre concurent doar fiindcă acesta a apărut. Scriem cea mai bună resursă proprie pentru jobul clientului, dacă produsul poate răspunde onest. Linkurile către paginile relevante și claritatea entității servesc cititorul; nu sunt promisiuni că un sistem AI va include brandul.
18. Remăsurarea folosește cohorta înghețată
Înainte de intervenție salvăm scenariile, prompturile, suprafețele, codebook-ul, datele și rezultatele. După ce schimbarea poate fi descoperită și procesată, reluăm cohorta originală și păstrăm separat scenariile noi. Evals API documentează evaluarea ca set de criterii și schemă a sursei de date; principiul relevant este să nu schimbăm simultan testul și obiectul testat.
O scădere a gap-ului după publicare este asociere temporală, nu cauzalitate demonstrată. Suprafețele, modelele, indexurile și sursele se pot schimba. Marcăm rupturile de serie și raportăm „observat în cohorta X”, nu „articolul a forțat recomandarea”.
Checklist de calificare
- scenariul provine dintr-o nevoie independentă, nu doar din numele concurentului;
- recomandarea este explicită conform codebook-ului;
- entitatea concurentă și rolul competitiv sunt validate;
- brandul este absent după verificarea aliasurilor și produselor;
- eligibilitatea este dovedită pentru toate constrângerile;
- afirmațiile și citările recomandării au fost verificate;
- celulele sunt grupate în familii de scenarii;
- recurența este raportată pe rulări, suprafețe și ferestre;
- verdictul și cauza au reviewer și versiune;
- intervenția nu depășește adevărul produsului;
- cohorta de remăsurare este înghețată înainte de schimbare;
- raportul nu promite controlul recomandărilor AI.
Verdict
Cel mai valoros scenariu nu este cel mai spectaculos screenshot, ci cel în care un concurent validat este recomandat repetat, brandul eligibil lipsește, dovada este suficientă și cauza poate fi abordată onest. Funnelul reduce 22 de capturi la două priorități, dar acele două priorități pot susține conținut și măsurare mult mai bune decât un calendar construit din presupuneri.