MAISON CODE .
/ Growth · AB Testing · Edge · Performance · Statistics · Vercel

Test A/B all'edge: nessuno sfarfallio, nessuno spostamento del layout

Perché il test A/B "useEffect" danneggia la tua SEO e UX. Come implementare esperimenti lato server utilizzando middleware e cookie. Ingegneria della crescita senza sfarfallio.

AB
Alex B.
Test A/B all'edge: nessuno sfarfallio, nessuno spostamento del layout

Gli strumenti di test A/B tradizionali (Optimize, VWO) funzionano inserendo JavaScript.

  1. Il browser carica la pagina A.
  2. JS viene eseguito, controlla i cookie.
  3. JS riscrive il DOM in “Pagina B”. Ciò causa FOOC (Flash of Original Content). L’utente vede il vecchio titolo per 0,5 secondi, quindi passa a quello nuovo. Distrugge i tuoi Core Web Vitals (CLS) e riduce la fiducia. La soluzione? Middleware Edge.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

Perché Maison Code esegue test all’avanguardia

Ci rifiutiamo di compromettere le prestazioni dei dati. Il marketing vuole esperimenti. L’ingegneria vuole velocità. Edge Testing offre entrambi. Eseguiamo la logica sui server Cloudflare/Vercel (The Edge), a 5 ms di distanza dall’utente. L’HTML arriva pre-renderizzato. L’utente non vede mai l’interruttore. Questo è l’unico modo per testare su un sito di lusso.

1. L’Architettura

Spostiamo la logica sul CDN (Vercel Edge / Cloudflare Workers). La decisione avviene prima che venga generato l’HTML.

  1. Richiesta: l’utente preme ”/”.
  2. Edge: controlla il cookie experiment-id.
  3. Bordo: se manca, lancia i dadi (50/50). Imposta il cookie.
  4. Edge: riscrive la risposta (lato server).
  5. Browser: riceve l’HTML specifico solo per la variante B. CLS zero. Sfarfallio zero.

2. Implementazione in Next.js/Middleware

Utilizziamo il file middleware.ts per intercettare la richiesta.

“dattiloscritto”. // middleware.ts importa { NextResponse } da ‘next/server’; import { getBucket } da ‘@lib/ab-testing’;

middleware della funzione di esportazione (richiesta: Richiesta) { const COOKIE_NAME = ‘ab-hero-test’; let bucket = request.cookies.get(COOKIE_NAME)?.value;

// Se non c’è un bucket, assegnane uno se (!secchio) { secchio = Math.random() < 0,5 ? ‘controllo’: ‘variante’; }

// Riscrive l’URL internamente (invisibile all’utente) const url = request.nextUrl.clone(); if (bucket === ‘variante’) { url.percorso = ‘/varianti/b’; } altrimenti { url.percorso = ‘/varianti/a’; }

const risposta = NextResponse.rewrite(url);

// Imposta il cookie appiccicoso risposta.cookies.set(COOKIE_NAME, bucket); risposta di ritorno; }


## 3. Significatività statistica (la matematica)

Non eseguire un test solo per 2 giorni.
Hai bisogno di **potere statistico**.
Se hai 100 visitatori e 5 conversioni (5%) contro 7 conversioni (7%), questo è rumore.
Utilizza una calcolatrice bayesiana.
Solitamente richiediamo:
* **Campione minimo**: 1.000 visitatori per variante.
* **Durata**: 2 cicli aziendali completi (2 settimane).
**Il problema della sbirciatina**:
Non interrompere il test nel momento in cui appare verde. Questo è il "P-hacking".
Impegnati per la durata prima di iniziare.

## 4. L'impatto SEO (sicurezza Google)

Google odia i contenuti duplicati.
Se hai `/` e `/variant-b`, usa i tag `canonical`.
Punta entrambe le versioni valide all'URL canonico `/`.
Oppure, poiché stiamo eseguendo Edge Rewrites, l'URL rimane `/` per l'utente.
GoogleBot di solito vedrà il Controllo (a meno che non persista i cookie).
**Avviso**: non "occultare" (mostrare a Google una cosa e agli utenti un'altra).
Google controlla il JS renderizzato.
Il test sugli edge è più sicuro perché fornisce risposte server distinte.

## 5. Flag di funzionalità e test A/B

* **Flag funzionalità**: "Attiva il nuovo pagamento affinché il 10% degli utenti possa verificare la presenza di bug." (Sicurezza).
* **Test A/B**: "Mostra un pulsante rosso rispetto a un pulsante blu per testare la conversione." (Crescita).
Utilizziamo strumenti come **LaunchDarkly** o **Statsig** per gestirli entrambi.
Condividono la stessa logica sottostante (rendering condizionale), ma l'*intento* è diverso.
I flag di funzionalità sono per l'ingegneria. I test A/B riguardano il prodotto.

## 6. Analisi dello sfarfallio (costo UX)

Se utilizzi il test A/B lato client...
E il tuo sfarfallio è di 500 ms...
Perdi il 10% degli utenti prima ancora che vedano la variante.
I tuoi dati sono danneggiati.
Stai testando "Control vs (Variant + Delay)".
Non stai testando "Control vs Variant".
Il test sui fronti rimuove la variabile Ritardo.
È l'unico modo scientifico per testare.

## 7. Il gruppo di resistenza

Se esegui 10 esperimenti contemporaneamente... come fai a conoscere l'impatto totale?
Crea un **Gruppo di controllo globale**.
Il 5% degli utenti non vede mai *nessun* esperimento.
Confronta il gruppo "Tutti gli esperimenti" con il gruppo "Holdout" dopo 6 mesi.
Ciò dimostra il valore a lungo termine del tuo programma CRO.

## 9. Le metriche che contano (oltre la percentuale di clic)

Non limitarti a misurare i "clic". Questa è una metrica della vanità.
Misura le **Entrate per visitatore (RPV)**.
La variante A potrebbe avere meno clic, ma un AOV (valore medio dell'ordine) più elevato.
Se ottimizzi per i clic, potresti semplicemente creare "Clickbait".
Tracciamo:
1. **Tasso di conversione**: hanno acquistato?
2. **AOV**: Quanto hanno speso?
3. **RPV**: valore combinato.
4. **Fidelizzazione**: sono tornati?

## 10. Il test segmentato (personalizzazione)

Il test A/B su "Tutti gli utenti" è schietto.
Test su **Segmenti**.
* **Test A**: Mostra "Spedizione gratuita" ai VIP che ritornano.
* **Test B**: mostra "10% di sconto" ai nuovi visitatori.
Gruppi diversi si comportano diversamente.
Utilizza Edge Middleware per rilevare il segmento (tramite cookie o geografia) ed eseguire il test appropriato.
Il "taglia unica" è morto.

## 11. Test A/B/n (multivariato)

Perché testare solo A vs B?
Test A vs B vs C vs D.
**L'algoritmo Bandit**:
Invece di una divisione fissa 50/50...
L'algoritmo instrada dinamicamente il traffico verso la variante vincente *mentre il test è in esecuzione*.
Se la versione C vince, invia l'80% del traffico a C.
Ciò massimizza le entrate *durante* il test.
Questo è il **Machine Learning** all'Edge.

## 12. Conflitto di consenso sui cookie (GDPR)

"Possiamo verificare se rifiutano i cookie?"
**No.**
Se un utente rifiuta il tracciamento, non puoi assegnargli un ID persistente.
**Strategia**:
1. **Modalità rigorosa**: in caso di mancato consenso, mostra Controllo. Non tracciare.
2. **Modalità sessione**: utilizza un cookie solo di sessione (cancellato alla chiusura). Questo è legalmente grigio ma più sicuro.
3. **Modalità anonima**: bucket basato sull'ID richiesta (casuale). Nessuna storia persistente.
Per impostazione predefinita utilizziamo la Privacy. Se dicono di no, vedono il sito predefinito.
Rispetta prima l'utente, poi ottimizza le entrate.

## 13. Integrazione di Analytics (GA4 / Mixpanel)

The Edge decide la variante. Ma GA4 deve saperlo.
Inseriamo la decisione nell'oggetto `window`.
```javascript
finestra.ab_test = {
  sperimentale_id: 'eroe_test',
  variante: 'B'
};

Quindi, GTM (Google Tag Manager) lo preleva e lo invia come “Proprietà utente”. Ciò ti consente di suddividere i report GA4 in base alla variante. “Mostrami il tasso di fidelizzazione della variante B.” Senza questo collegamento, i tuoi dati sono ciechi.

14. La strategia del test dei prezzi (entrate pericolose)

Testare i prezzi è pericoloso. Se gli utenti lo scoprono, si arrabbiano. Il test dello “Sconto”: Test A: prezzo standard ($100). Test B: “Offerta a tempo limitato: $ 90”. Questo è sicuro. Il test “Premium”: Test A: prezzo standard ($100). Test B: confezione Premium inclusa ($120). Testare le proposte di valore, non solo i prezzi. Se testi il ​​prezzo grezzo ($100 contro $110) per lo stesso articolo, rischi un incubo di pubbliche relazioni.

15. Il test Mobile First (zona pollice)

La maggior parte dei test A/B falliscono sui dispositivi mobili perché sono progettati per desktop. La “Zona del pollice”: Su dispositivi mobili, la CTA deve essere raggiungibile con un pollice. Test A: pulsante permanente standard. Test B: “Pulsante di azione mobile” (FAB) in basso a destra. Spesso vediamo una conversione del +15% semplicemente spostando il pulsante di 50 pixel verso il basso. Metti alla prova l’ergonomia fisica, non solo i colori.

16. Conclusione

L’A/B Testing è il metodo scientifico applicato ai ricavi. Ma se la tua “scienza” interrompe l’esperienza dell’utente (sfarfallio), invalidi i risultati. Prova al limite. Mantieni la velocità. Rispetta la matematica. La crescita è un gioco di centimetri, non di chilometri.

17. L’ultimo avviso di sfarfallio

Se prendi una cosa da questo articolo: Non accettare Flicker. Lo sfarfallio non è solo “brutto”. È corruzione dei dati. Distorce il tuo test verso gli utenti con Internet veloce (che vedono meno sfarfallio). Pregiudica gli utenti mobili. Annulla tutta la tua ipotesi. Spostarsi al limite. Oppure non testare affatto.

Indovina cosa funziona?

Implementiamo pipeline di sperimentazione Edge prive di sfarfallio.

Imposta stack di crescita. Assumi i nostri architetti.