A/B testing sui link contestuali: framework operativo per esperimenti che aumentano davvero le conversioni

L'A/B testing sui link affiliati e contestuali è la tecnica più invocata e più spesso applicata male nei siti editoriali italiani. Ci sono decine di "test" eseguiti ogni mese che consumano settimane di traffico per confermare un'ipotesi già nota a priori, e pochi test davvero informativi che vengono abbandonati prima del campione minimo. Questa guida descrive un framework operativo: cosa vale la pena testare, come dimensionare il test, quali errori evitare, e quando il test stesso è il problema.

L'obiettivo è che al termine abbiate un processo riproducibile per eseguire esperimenti che producano decisioni utili, senza sprecare volume di traffico su domande retoriche.

1. Cosa vale la pena testare: matrice di priorità

Non tutti i test hanno pari valore. La matrice di priorità ICE (Impact, Confidence, Ease) aiuta:

• Impact: quanto sposta una revenue del 20%+ se vince?
• Confidence: quanto sei sicuro del risultato a priori? Paradossalmente, i test più utili sono quelli a bassa confidence.
• Ease: quanto è rapido implementare il test?

Test con alto Impact e bassa Confidence sono i più utili. Esempi:

• Copy del primo paragrafo di un articolo longform (hero del testo): impact alto, confidence bassa.
• Struttura del box comparison (4 colonne vs 6): impact medio, confidence bassa.
• Colore del CTA newsletter: impact basso, confidence bassa — comunque utile perché facile.

Test con alto Impact e alta Confidence (vincitore noto a priori) sono da implementare senza test:

• Posizione del primo link affiliato (prima vs fine articolo) — vince sempre il primo.
• Anchor text specifico vs generico — vince sempre lo specifico.
• Tooltip vs link nudo su keyword prodotto — vince sempre il tooltip.

Eseguire questi test spreca traffico. Implementali direttamente.

2. Metodologia di test: sei step

Step 1 — Ipotesi esplicita

Scrivi l'ipotesi in forma "se X allora Y perché Z":

Cattiva: "Voglio testare la posizione del link." Buona: "Se sposto il primo link affiliato dalla posizione 450 alla posizione 250 parole, il CTR aumenta del 15% perché il lettore incontra il link prima della curva di attention decay."

Un'ipotesi vuota è un test vuoto.

Step 2 — Variabile singola

Testa una sola variabile per volta. Se cambi posizione E anchor text, non saprai quale ha fatto la differenza. L'eccezione è quando due cambiamenti sono confonditori "impossibili da separare" — raro.

Step 3 — Sample size calculation

Usa calcolatori come Evan Miller o AB Testguide:

• CTR base atteso (da dati storici): 2%.
• MDE (Minimum Detectable Effect): 15% relativo (da 2% a 2,3%).
• Significance: 95%, power: 80%.
• Result: ~37.000 esposizioni per variante, ~74.000 totali.

Se il tuo articolo ha 500 pv/giorno, servono 148 giorni. Inaccettabile. Conclusione: il test è troppo lungo, bisogna consolidare su articoli più grandi o aumentare l'MDE accettabile al 25% (campione più piccolo).

Step 4 — Random assignment

Lato client, hash del user_id (o del cookie first-party) modulo 2 per split 50/50. Lato server, funzione di hash deterministica. In GrowthBook o VWO il tool lo fa per te.

Evita di usare il timestamp come seed — produce distribuzioni sbilanciate se il traffico non è uniforme.

Step 5 — No peeking

Dichiara il sample size in anticipo. Non guardare i risultati intermedi — ogni "occhiata" aumenta la probabilità di un falso positivo. Se usi il sequential testing (disponibile in GrowthBook e VWO SmartStats), puoi monitorare in continuo senza inflazione del false-positive: il sequential testing è la soluzione statistica al peeking. I motori Bayesiani offrono risultati interpretabili a qualsiasi sample size, ma non eliminano da soli l'inflazione del false positive se si adotta una stopping rule su soglia fissa.

Step 6 — Analisi e decisione

Quando raggiungi il sample size:

• Variante A (controllo): CTR = 2,0%, IC 95% [1,85%, 2,15%]
• Variante B (test): CTR = 2,4%, IC 95% [2,24%, 2,56%]
• Lift: +20%, IC 95% [+10%, +30%]

L'IC al 95% è completamente sopra lo zero: decisione di prendere B.

Se l'IC include lo zero ("lift [-3%, +18%]"), il test è inconclusivo. Non dichiarare vincitore.

3. Errori tipici nei test sui link contestuali

Errore 1 — Cambiare variabili a metà. "Il test stava andando male, ho corretto l'anchor". Risultato: dati incastrati, impossibile attribuire il lift.

Errore 2 — Sottostima del sample size. Dichiarare vittoria dopo 5.000 esposizioni su un test che ne richiederebbe 60.000. Il "vincitore" spesso regredisce alla media dopo.

Errore 3 — Non segmentare per device. Mobile e desktop hanno pattern di CTR molto diversi sui link contestuali. Un test che vince complessivamente può perdere su mobile (che è il 70%+ del traffico).

Errore 4 — Ignorare stagionalità e picchi di traffico. Se il test ha campione raccolto al 70% durante un picco virale (fonte traffico diversa dal baseline), il risultato non è generalizzabile.

Errore 5 — Testare su troppe pagine. Non mescolare 20 articoli di tipologie diverse nello stesso test. I tipi di contenuto hanno baseline diverse, il pool è disomogeneo.

4. Strumenti per publisher

• GrowthBook (self-hosted o cloud): raccomandato. Bayesiano, feature flag, SDK multi-linguaggio. Zero flicker su server-side, minimo su client-side.
• VWO: editor visuale, pricing scala con MAU. Flicker mitigato.
• Convert: pricing lineare, EU hosting, anti-flicker buono.
• PostHog: free tier generoso, A/B integrato in product analytics.

Evitare di usare "quasi-esperimenti" in GA4 (segmentazione per landing + calcoli manuali) per test critici — non hanno random assignment e confondono le variabili.

5. Quanto è realistico il tuo traffico

Tabella indicativa, articolo tipo 1.500 parole, CTR base 2%, MDE 15% desiderato:

Pagina views/giorno	Giorni per raggiungere 74k esposizioni	Ragionevole?
5.000	15	Sì
2.000	37	Sì
1.000	74	Borderline
500	148	No

Se il tuo articolo non è nella fascia "sì", unisci articoli con baseline simili per aumentare il pool, oppure accetta un MDE più largo (25-30%).

6. Dove l'A/B testing non è il problema

Torniamo al punto centrale. Molti test che i publisher vorrebbero eseguire sono "test di conferma" — l'ipotesi è talmente robusta che il test è una perdita di tempo. Alcuni esempi:

• "Voglio testare se inserire un link contestuale su una keyword prodotto migliora il CTR" → sì, lo fa, tipicamente 40-120% di uplift. Implementa senza testare, misura il delta su dati storici.
• "Voglio testare se un tooltip con nome-prezzo-link aumenta le conversioni rispetto a un link testo" → sì, il tooltip riduce la friction e rende esplicito il valore del click.
• "Voglio testare se il tooltip su tutte le keyword prodotto converte meglio di un box solo sul primo prodotto nominato" → sì quasi sempre, perché cattura più intent per sessione.

Questi "test" descrivono problemi dove l'architettura giusta è nota e il lavoro è implementarla. AnchorLabs, per esempio, implementa tutti e tre i pattern out-of-the-box: scansiona il DOM, riconosce le keyword prodotto, attiva tooltip con name-price-link su tutte le occorrenze. Il CTR uplift tipico del 40-120% è misurabile confrontando dati pre/post deploy, senza bisogno di A/B test formali. Il deploy è un tag <script>, il peso è 5 KB gzip, nessun impatto CWV.

Il budget di A/B testing è meglio speso su test veri: copy dell'hero su un pilastro, layout della pagina categoria, formato della newsletter signup form. Questi sì, richiedono sperimentazione perché la direzione non è ovvia.

Per il framework generale di ottimizzazione che non passa da A/B testing, vedi Aumentare il CTR sui link affiliati. Per modelli di misurazione delta pre/post senza testing formale, Come tracciare la revenue per articolo descrive il processo. Per il contesto di confronto tra format di conversione, Link contestuali vs banner.

Esempio completo: test utile su un publisher italiano

Articolo: "Migliori cuffie wireless sotto 300€", 3.000 pv/giorno, 2.100 parole, attualmente 2,8% di CTR sui link affiliati.

Ipotesi: "Se aggiungo una tabella comparativa con 5 colonne (modello, prezzo, autonomia, pro, link) subito dopo il primo paragrafo, il CTR aumenta del 25% perché il lettore trova il confronto decisionale prima della curva di attention decay".

Sample size: CTR base 2,8%, MDE 15% relativo (da 2,8% a 3,2%), significatività 95%, power 80%, servono ~26.000 esposizioni per variante, ~52.000 totali. A 3.000 pv/giorno, ~17 giorni.

Setup: variante A (controllo, senza tabella), variante B (tabella dopo primo paragrafo), split 50/50, random assignment client-side via user_id hash.

Run: 17 giorni. Non guardare i dati.

Risultato: Controllo 2,8% CTR, Test 3,7% CTR, lift +32% [IC 95%: +22%, +42%]. Decisione: adottare la tabella.

Cost: 25 giorni di traffico, due varianti. Benefit: un'ipotesi confermata con dati robusti, riutilizzabile per altri articoli simili.

Da dove iniziare

Prima di impostare il tuo prossimo A/B test, applica tre filtri:

1. Il risultato è davvero incerto? Se sai a priori cosa vincerà, non testare — implementa.
2. Hai traffico sufficiente per il sample size? Se no, cerca di aumentare l'MDE accettabile o accorpa articoli simili.
3. Il test misura una decisione utile, o solo curiosità?

Se il test passa i filtri, segui i 6 step. Se non passa, investi il tempo in implementazione diretta delle ottimizzazioni note.