Cum măsurăm impactul unei intervenții GEO

Un răspuns AI mai bun după ce am modificat un articol nu demonstrează că articolul a produs schimbarea. Între cele două momente se pot schimba modelul, indexul, interfața, concurența, interesul public sau sistemul de măsurare.

Putem spune imediat că rezultatul s-a modificat. Putem vorbi despre asociere temporală dacă schimbarea urmează intervenției. Pentru o concluzie cauzală avem nevoie de un design mai puternic și de ipoteze pe care datele le susțin.

Protocolul de mai jos nu promite certitudine perfectă. El reduce explicațiile alternative și arată exact cât de departe putem merge cu afirmația.

1. Definim intervenția înainte de rezultat

„Am optimizat conținutul” nu este o intervenție reproductibilă. Construim un bundle cu:

• ID și versiune;
• URL-urile și fișierele modificate;
• hash-ul sau snapshotul înainte și după;
• lista exactă a schimbărilor;
• autorul și aprobatorul;
• ora deploymentului;
• starea de rollback;
• alte schimbări publicate simultan.

Dacă rescriem titlul, adăugăm surse, schimbăm canonicalul și publicăm trei pagini suport în aceeași zi, măsurăm efectul bundle-ului, nu al unei singure propoziții.

2. Înghețăm baseline-ul

Baseline-ul include mai mult decât un scor:

• conținutul și starea tehnică a URL-ului;
• prompts, personas, scenarii și ramuri;
• motor, interfață/API, model afișat, limbă și geografie;
• răspunsuri brute, citări și clasificări;
• numărul de rulări, coverage și eșecuri;
• metrici first-party disponibile;
• data și distribuția valurilor de măsurare.

Un singur screenshot înainte și unul după sunt vulnerabile la variația normală. Preferăm mai multe valuri înainte de intervenție pentru a observa nivelul și volatilitatea.

Formulele și numitorii trebuie fixați conform ghidului despre KPI-urile AI.

3. Verificăm că intervenția a ajuns live

Timestampul din editor nu este suficient. Verificăm URL-ul public, statusul HTTP, conținutul, canonicalul, schema, sitemapul și eventualele cache-uri. Salvăm hash-ul paginii servite.

Apoi separăm deploymentul de descoperire. Un crawler poate reveni mai târziu, iar indexul sau răspunsul generativ se poate actualiza într-un alt ritm. Data publicării nu este automat data expunerii efective.

Dacă pagina rămâne `noindex`, canonicalizează către alt URL sau servește vechiul conținut, experimentul testează un deployment defect, nu calitatea intervenției.

4. Păstrăm cohorta comparabilă

În valul post-intervenție folosim aceeași familie de scenarii, aceleași reguli de ramificare și aceeași clasificare. Păstrăm limba, geografia și interfața sau marcăm diferența.

Nu alegem după rezultat doar prompturile care s-au îmbunătățit. Nu eliminăm răspunsurile eșuate. Nu introducem brandul în prompt dacă baseline-ul măsura discovery organic.

Pentru conversațiile multi-turn păstrăm persoana, obiectivul, constrângerile și condițiile de oprire descrise în articolul despre traiectoriile conversaționale.

5. Stabilim fereastra și regula de oprire

Înainte de publicare declarăm:

• o perioadă de latență în care nu tragem concluzii;
• datele valurilor post-intervenție;
• numărul minim de observații;
• metricile primare și secundare;
• regula pentru date insuficiente;
• momentul în care închidem analiza.

Altfel putem continua să verificăm până găsim o zi favorabilă. Google avertizează că unele schimbări pot produce efecte în câteva zile, iar altele după luni și că nu există garanția unui impact vizibil. Ghidul de diagnostic Search recomandă comparații în timp și investigarea cauzelor alternative.

6. Folosim controale când este posibil

Un control este o pagină, un grup de scenarii sau o entitate comparabilă care nu primește intervenția în aceeași perioadă. Nu trebuie să fie identic, dar diferențele relevante trebuie documentate.

Putem folosi:

• pagini similare neatinse;
• întrebări adiacente care nu depind de pagina modificată;
• țări sau limbi unde schimbarea nu a fost publicată încă;
• un rollout eșalonat;
• metrici negative care nu ar trebui să se schimbe.

Controlul ajută la distingerea unei creșteri specifice de una produsă de un update general. Contaminarea apare dacă paginile de control primesc legături, traduceri sau conținut din același bundle.

7. Diferența dintre diferențe

Presupunem:

• grup intervenție: visibility crește de la 30% la 42%, adică +12 puncte;
• grup control: crește de la 28% la 34%, adică +6 puncte.

Estimarea descriptivă difference-in-differences este:

(42% − 30%) − (34% − 28%) = +6 puncte procentuale.

Nu spunem automat că intervenția a cauzat +6 puncte. Interpretarea cere trenduri comparabile înainte, lipsa schimbărilor diferențiale, control necontaminat și măsurare stabilă. Cu puține observații, incertitudinea poate acoperi complet diferența.

8. Separăm datele first-party de observațiile externe

Search Console poate furniza impresii și clickuri pentru suprafețele Google. În 2026, Google a anunțat rapoarte dedicate impresiilor în funcțiile generative pentru un subset inițial de site-uri, cu pagini, țări, dispozitive și date. Acestea sunt date first-party Google.

Un instrument extern poate rula conversații eșantionate pe mai multe motoare și măsura mențiuni ori recomandări. Cele două surse nu au același numitor și nu trebuie combinate într-un „impact score”.

Raportăm alături, nu adunăm: impresii first-party, referral/clickuri și rezultate din cohorta conversațională.

9. Ținem un jurnal al explicațiilor alternative

În fereastra experimentului notăm:

• schimbări de model, interfață sau instrumente de search;
• actualizări ale indexului și sistemelor de ranking;
• evenimente de știri și sezonalitate;
• publicații importante din categorie;
• indisponibilitatea crawlerului ori a site-ului;
• migrații, canonicale și redirecturi;
• schimbări ale trackingului;
• versiuni noi ale rubricii sau entity resolution.

Search Console publică anomaliile de date tocmai pentru că un bump sau dip poate proveni din logging, nu din comportamentul utilizatorilor. O anomalie relevantă se marchează, nu se ascunde.

10. Raportăm coverage și incertitudine

O creștere de la 3/10 la 5/10 conversații este +20 puncte procentuale, dar eșantionul este mic. Afișăm numărătorii, numitorii și intervalele, nu doar diferența.

NIST AI 800-3 arată de ce ținta măsurării și ipotezele statistice trebuie explicite și de ce performanța pe un benchmark fix nu dovedește automat generalizarea.

Răspunsurile eșuate rămân în coverage. Dacă rata de succes se schimbă între valuri, analizăm dacă selecția observațiilor a modificat artificial KPI-ul.

11. Publicăm și rezultatele nule sau adverse

O intervenție poate să nu producă diferență detectabilă. Poate crește citările și reduce clickurile, poate îmbunătăți acuratețea fără să schimbe recommendation SOV sau poate afecta o pagină de control prin canibalizare.

Un rezultat nul este util: limitează afirmațiile și informează următorul test. Un rezultat advers cere verificare și, dacă riscul o justifică, rollback.

Nu schimbăm retrospectiv metrica principală cu singura care a crescut. Metricile secundare pot genera ipoteze, nu pot rescrie obiectivul experimentului.

12. Preînregistrăm analiza și criteriile de decizie

Înainte de primul val post-intervenție scriem un plan scurt, datat și nemodificabil. El precizează ipoteza, unitatea de analiză, metrica principală, cohorta, excluderile permise, controlul și calculul care va susține concluzia. Păstrăm separat orice analiză exploratorie apărută după ce am văzut rezultatele.

Preînregistrarea nu trebuie să fie academică sau publică. Poate fi un fișier versionat în proiect, atât timp cât arată ce știam și ce urma să facem înainte de rezultat. Dacă schimbăm protocolul deoarece un motor devine indisponibil, salvăm o versiune nouă și explicăm abaterea; nu rescriem documentul inițial.

Criteriul de decizie este diferit de pragul statistic. De exemplu, putem decide să păstrăm intervenția dacă acuratețea factuală nu scade, coverage rămâne peste pragul operațional și diferența față de control este pozitivă în două valuri consecutive. Putem decide rollback dacă apar erori factuale grave, chiar dacă media visibility crește.

Astfel, experimentul nu devine o căutare retrospectivă a unei povești favorabile. Rezultatul răspunde unei întrebări declarate, iar observațiile neașteptate sunt marcate ca ipoteze pentru un test ulterior.

13. Facem verificări de robustețe

Un rezultat credibil nu ar trebui să dispară imediat când alegem o fereastră vecină sau o formulă rezonabilă alternativă. Refacem calculul cu și fără zilele afectate de o anomalie documentată, pe fiecare motor separat și, unde avem suficiente observații, pe segmente precum limbă, țară ori tip de scenariu.

Aceste verificări nu ne dau voie să selectăm varianta cea mai convenabilă. Raportăm specificația principală exact cum a fost preînregistrată, apoi arătăm dacă direcția și ordinul de mărime rezistă în variantele secundare. Dacă efectul apare doar într-o singură zi sau numai după eliminarea unui segment important, concluzia trebuie slăbită.

Verificăm și stabilitatea rubricii de evaluare. Un eșantion de răspunsuri poate fi recodificat fără acces la eticheta „înainte” sau „după”. Dezacordurile dintre evaluatori se documentează, iar regulile ambigue se clarifică pentru următorul experiment, nu se aplică retroactiv doar cazurilor care schimbă rezultatul.

Pentru proporții raportăm și un interval de încredere adecvat eșantionului; NIST descrie intervalul Wilson ca alternativă la aproximația normală simplă. Intervalul nu repară un eșantion părtinitor, dar face vizibilă precizia limitată a estimării.

14. Nivelurile concluziei

Nivel	Formulare permisă	Dovadă
Observație	„KPI-ul a crescut după data X.”	before/after comparabil
Asociere	„Creșterea este asociată temporal intervenției.”	valuri repetate și cronologie
Estimare controlată	„Diferența față de control a fost Y.”	control, ipoteze și incertitudine
Cauzalitate	„Intervenția a produs efectul estimat.”	design și ipoteze cauzale puternice

Majoritatea testelor editoriale observationale vor rămâne la primele trei niveluri. Asta nu le face inutile; le face oneste.

Fișa minimă a experimentului

1. ipoteză și metrică primară;
2. baseline și volatilitate pre-intervenție;
3. bundle, hash, owner și timestamp;
4. cohortă, motor, interfață, limbă și geografie;
5. control și risc de contaminare;
6. latență, ferestre și stop rule;
7. coverage, eșecuri și intervale;
8. jurnalul evenimentelor externe;
9. rezultate first-party și externe separate;
10. concluzie, limitări și decizie de rollback/continuare.

Auditul editorial al paginii înainte de intervenție poate folosi checklistul din ghidul de analiză GEO/AEO.

Verdict

„Am schimbat pagina, apoi scorul a crescut” este începutul investigației, nu concluzia.

Un experiment credibil păstrează baseline-ul, versiunea intervenției, cohorta și controalele; așteaptă o fereastră declarată; verifică anomaliile și publică incertitudinea.

Când designul nu permite cauzalitate, spunem exact ce permite: o observație, o asociere sau o diferență față de control. Disciplina afirmației este la fel de importantă ca valoarea KPI-ului.

Surse

• Google Search Central — Debugging Search traffic drops
• Search Console Help — measuring the impact of a change
• Search Console Help — data anomalies
• Google Search Central — Generative AI performance reports
• NIST AI 800-3 — Expanding the AI Evaluation Toolbox
• NIST/SEMATECH — Confidence intervals for proportions

Ultima verificare a surselor: 31 iulie 2026. Protocolul este metodologie editorială și nu afirmă existența unui sistem AYSA de experimentare sau remăsurare deja lansat.