← Tutti gli articoli

Tutorial

Forzare una variante specifica di A/B test o feature flag per il QA

16 maggio 2026 · di JustZix Team

Gli A/B test e i feature flag sono ottimi per i team di prodotto e una sofferenza per il QA. Vieni assegnato a un bucket una volta, in modo casuale, e poi non puoi piu vedere l'altra variante. Questo articolo mostra come prendere il controllo: trovare il valore che il sito usa per assegnarti il bucket, sovrascriverlo prima che la pagina lo legga e bloccare una variante per pattern di URL con una regola JustZix.

Come i siti ti assegnano i bucket

Quasi ogni strumento di sperimentazione lato client — Optimizely, GrowthBook, LaunchDarkly, Statsig, Split, soluzioni interne — funziona allo stesso modo. Alla tua prima visita lancia un dado, scrive il risultato da qualche parte in modo persistente e legge sempre lo stesso posto a ogni visita successiva, cosi la tua esperienza resta stabile. Quel "da qualche parte in modo persistente" e quasi sempre una di tre cose:

• Un cookie (per esempio ab_variant=B o un ID utente anonimo che, tramite hash, finisce in un bucket).
• Una chiave di localStorage (comune con gli SDK di GrowthBook e Statsig).
• Una decisione lato server incorporata nell'HTML o restituita da una chiamata API.

Le prime due puoi sovrascriverle direttamente. La terza e piu difficile — ne parliamo sotto.

Trovare la chiave di bucketing

Apri i DevTools e vai alla scheda Application. Sotto Storage hai Cookies e Local Storage affiancati. Ricarica la pagina e cerca qualcosa che sembri un esperimento: chiavi che contengono ab, exp, variant, flag, bucket, test, feature, o un nome di vendor come optimizely o growthbook.

Se non compare nulla di evidente, la decisione arriva dalla rete. Apri la scheda Network, filtra su Fetch/XHR, ricarica e cerca una richiesta a qualcosa come /api/flags, /decide o config.json. Il JSON della risposta ti dice i nomi delle varianti e — cosa cruciale — sotto quale chiave l'SDK le memorizza.

Sovrascrivere localStorage prima che gli script lo leggano

Il tempismo e tutto. L'SDK di sperimentazione legge la sua chiave presto, spesso prima di DOMContentLoaded. La tua regola JS di JustZix deve girare prima di quella lettura. Imposta la regola perche giri a document_start e scrivi subito il valore:

// Pin the GrowthBook-style variant before the SDK initialises
const KEY = 'gb_anonymous_id';      // the bucketing key you found
const FORCED = 'qa-pinned-variant-b';

// Overwrite whatever value the SDK would have rolled
localStorage.setItem(KEY, FORCED);

// Some SDKs cache a whole decision object — pin that too
localStorage.setItem('growthbook_features', JSON.stringify({
  'new-checkout': { defaultValue: true },
  'pricing-table-v2': { defaultValue: 'variant-b' }
}));

Per l'approccio dell'ID anonimo scegli un ID stabile e non casuale: la maggior parte degli SDK ne calcola l'hash per ottenere un bucket, quindi la stessa stringa finisce sempre nella stessa variante. Prova qualche ID una volta, annota quale ti da la variante B e riusalo per sempre.

Sovrascrivere un cookie

I cookie sono piu semplici — non c'e un SDK di mezzo, solo una stringa. Scrivilo a document_start cosi gli script della pagina vedono il tuo valore:

// Force the experiment cookie for this domain
function setCookie(name, value) {
  document.cookie =
    name + '=' + value + '; path=/; max-age=31536000; SameSite=Lax';
}

setCookie('ab_variant', 'B');
setCookie('feature_new_nav', 'on');

Se il cookie e HttpOnly non puoi toccarlo affatto da JavaScript — quello e un flag lato server, trattato di seguito. Puoi confermarlo nella scheda Application: i cookie HttpOnly mostrano una spunta in quella colonna.

Gestire i flag lato server

Quando la variante e decisa sul server, l'HTML che ricevi e gia la variante. Non c'e alcun valore lato client da capovolgere. Hai due opzioni oneste:

• Invia un suggerimento che il server rispetta. Molte configurazioni leggono un cookie di override non HttpOnly come x-force-variant o un parametro di query ?ab_force=B proprio perche il QA possa testare i rami. Chiedi al tuo team — questi override di solito esistono e sono solo non documentati.
• Re-imposta lo stile della variante che hai. Se non riesci a ottenere il markup reale della variante B, a volte puoi approssimare la differenza visibile con una regola CSS per gli screenshot — ma quello e un mock, non un test reale. Usalo solo per la revisione di design, mai per il QA funzionale.

Un override tramite parametro di query e la via piu pulita. Se il tuo sito supporta ?ff_override=new-checkout:true non ti serve nemmeno JavaScript — basta un segnalibro sull'URL.

Bloccare una variante per pattern di URL

Il vero vantaggio di JustZix e lo scoping. Non vuoi che ogni sito sia assegnato allo stesso bucket — vuoi che questo ambiente di staging sia bloccato sulla variante B e quello lasciato in pace. Crea una regola con un pattern di URL ristretto:

URL pattern:  https://staging.example.com/*
JS (document_start):
  localStorage.setItem('exp_checkout', 'variant-b');
  document.cookie = 'ab_force=B; path=/';

Crea una regola per variante — "Pin checkout A", "Pin checkout B", "Pin control" — e attivale dalla barra delle azioni. Un giro di QA su tutti e tre i rami diventa tre clic invece di tre finestre in incognito e molta fortuna.

Verificare che la variante sia davvero attiva

Non fidarti del fatto che l'override abbia funzionato solo perche la pagina sembra diversa. Confermalo. La maggior parte degli SDK espone l'assegnazione attiva da qualche parte — registrala dalla Output Console:

// Read back what the SDK decided, after it initialised
window.addEventListener('load', () => {
  // GrowthBook example
  if (window.growthbook) {
    console.log('Active features:', window.growthbook.getFeatures());
  }
  // Generic: dump every storage key for the audit trail
  console.log('Forced storage:', { ...localStorage });
});

Abbina questo alla finestra Output Console cosi l'assegnazione e visibile nella scheda mentre clicchi attraverso il flusso. Se l'SDK riporta la variante che hai forzato, il tuo test e reale. Se riporta qualcos'altro, la tua regola e girata troppo tardi — spostala a document_start.

Insidie comuni

• Girare troppo tardi. Una regola a document_idle perde la corsa. L'SDK ha gia letto la sua chiave. Usa sempre document_start per gli override di bucketing.
• Dimenticare la meta lato server. Hai bloccato la variante lato client ma il server renderizza ancora il control. Cerca un cookie o un parametro di override.
• Inquinare le analytics. Le sessioni forzate distorcono i risultati degli esperimenti. Usa un ambiente di staging, o chiedi al team dati di escludere il traffico QA.
• Cache obsolete. Alcuni SDK mettono in cache la decisione per ore. Pulisci prima la chiave di storage rilevante, poi imposta il tuo valore forzato.

Vedi anche

• Simula le risposte API intercettando fetch — falsifica l'endpoint dei flag invece della chiave di storage.
• Regole basate sul tempo — programma quale variante e bloccata per giorno o per ora.
• Casi d'uso di JustZix — altri flussi di lavoro di QA e debugging.

Smetti di affidarti a finestre in incognito e tiri di dado fortunati. Installa JustZix, costruisci una regola per variante ed esercita ogni ramo di ogni esperimento a richiesta.