Panoramica

I test A/B o le tecniche di implementazione canary consentono agli sviluppatori di sperimentare due o più varianti di una pagina Web. Le varianti vengono mostrate in modo casuale agli utenti e in seguito si ricorre all'analisi statistica per determinare quale variante offre prestazioni migliori per un determinato obiettivo aziendale. Ad esempio, una variante dell'interfaccia utente della pagina di un prodotto può essere testata con l'obiettivo di aumentare le vendite dei prodotti.

Decisioni architetturali

Puoi implementare i test A/B in diversi modi in base ai tuoi requisiti tecnici e aziendali. Una delle principali decisioni tecniche è dove eseguire la logica di selezione delle varianti: lato client, lato edge server (a livello CDN) o lato server di origine.

Selezione delle varianti lato server di origine. In questo approccio, la selezione A/B viene eseguita direttamente sul server di origine che ospita l'applicazione web. Sebbene questo approccio sia indipendente dalla CDN, è incompatibile con la memorizzazione nella cache CDN o con l'hosting di file statici. È un'opzione per le applicazioni web renderizzate sul lato server che sono completamente dinamiche.

Selezione della variante lato Edge server. In questo approccio, prendi la decisione sulla selezione delle varianti a livello CDN. Questo approccio richiede modifiche minime o nulle all'applicazione ed è compatibile con la memorizzazione nella cache CDN. In CloudFront, puoi implementare la logica di test A/B utilizzando le funzioni edge. Una funzione Edge può utilizzare gli attributi della richiesta (country, cookie, ecc.), oltre all'API di test A/B esterna per selezionare una delle varianti e fare in modo che CloudFront la serva dalla cache.

Selezione della variante lato client. In questo approccio, il front-end invia prima una richiesta a un API di test A/B per decidere quale variante fornire, quindi in base alla risposta, scarica la variante, quindi esegui il rendering nel browser. In questo approccio, il test A/B è indipendente dalla CDN, tuttavia è strettamente collegato all'applicazione e introduce una latenza aggiuntiva dovuta a passaggi aggiuntivi sul lato client. Nota anche che non è sempre un'opzione, come per i test A/B di siti generati staticamente (SSG). Per implementare i test A/B lato client, puoi usare CloudWatch Evidently. Quest'ultimo fornisce l'SDK del client e l'interfaccia utente per controllare gli esperimenti di test A/B. Per un tutorial pratico su CloudWatch Evidently, prendi in considerazione questo workshop.

Concentriamoci sui test A/B lato server edge. Per progettare l'implementazione migliore per la tua azienda, considera le domande aggiuntive:

  • Hai bisogno di persistenza(ad esempio lo stesso utente riceverà sempre la stessa variante)? La persistenza viene solitamente implementata utilizzando i cookie.
  • Quali dimensioni vengono utilizzate per selezionare una variante per un utente? paese, ID utente, ecc.
  • Con quale frequenza esegui i test A/B? L'uso intensivo dei test A/B, con molti esperimenti eseguiti in parallelo da diversi team, richiede un'implementazione più sofisticata rispetto ai test A/B occasionali più semplici.

Per saperne di più su alcune delle implementazioni dei test A/B lato edge utilizzando le funzioni edge di CloudFront, prendi in considerazione questo workshop pratico. Nella sezione seguente, condivideremo due implementazioni comuni di test A/B utilizzando CloudFront, tratte dal suddetto workshop.

Casi d'uso comuni che utilizzano i test A/B sul lato server edge

Test A/B occasionali

Per esigenze occasionali di test A/B, come il miglioramento trimestrale del design di un sito web istituzionale, prendi in considerazione una soluzione basata su Funzioni CloudFront per tutta la durata dell'esperimento. La soluzione si basa su due funzioni configurate in base al comportamento della cache che corrisponde alla pagina per la quale si desidera eseguire il test A/B:

  • Una funzione di richiesta del visualizzatore, che esamina il valore del cookie di esperimento delle richieste in arrivo e in base a ciò riscrive l'URL della variante di pagina selezionata. Se il cookie non è presente, la funzione seleziona la variante utilizzando la logica personalizzata, ad esempio il 60% per la variante A e il 40% per la variante B, solo per le richieste provenienti dalla Francia.
  • Una funzione di risposta dello spettatore, che imposta il cookie sul client in base alla variante selezionata, se il cookie non era già presente. Il cookie di esperimento viene utilizzato per assicurarsi che un singolo utente riceva sempre la stessa variante della pagina per evitare di interrompere la sua esperienza web.

La modifica della logica di selezione della variante, ad esempio per aumentare la percentuale della variante B, richiede un aggiornamento del codice della funzione dell’evento del visualizzatore, che generalmente richiede pochi secondi per essere completata. Quando hai finito l'esperimento di test A/B, puoi rimuovere le funzioni edge per risparmiare sui costi.

Test A/B frequenti

Se pratichi continuamente test A/B sul tuo sito web, con esperimenti condotti quotidianamente, puoi comunque utilizzare la precedente soluzione basata su CloudFront Function. Tuttavia, si consiglia di disaccoppiare i parametri di selezione delle varianti (ad esempio, i pesi delle varianti) dal codice funzione. È possibile utilizzare un KeyValueStore di CloudFront per memorizzare tali parametri, al di fuori del codice funzione. Il KeyValueStore è ideale come lettura globale (ogni PoP) a bassa latenza,
datastore di valori chiave su larga scala (milioni di richieste al secondo).

Tieni presente che il tuo caso d'uso deve rispettare le quote KeyValueStore, come la dimensione massima (5 MB) o il limite di velocità di modifica di poche chiamate API al secondo.

Case study CapitalOne: test A/B con Funzioni CloudFront e KeyValueStore

Test A/B avanzati

Prendi in considerazione una soluzione basata su Lambda@Edge se una soluzione basata su CloudFront Function non soddisfa le tue esigenze di test A/B, ad esempio se le quote di KeyValueStore sono limitanti per il tuo caso d'uso. Questo può essere il caso se gestisci un sito di e-commerce di grandi dimensioni, con molti team che eseguono esperimenti simultanei su diverse parti del sito Web ad alta velocità.  In questo scenario, utilizza Lambda@Edge anziché CloudFront Function, con un'origine dati esterna (ad esempio, tabelle globali DynamoDB) per archiviare i parametri di test A/B. Gli strumenti di gestione delle funzionalità come LaunchDarkly forniscono integrazioni con DynamoDB per mantenere i parametri di test A/B persistenti.

Risorse

Questa pagina è stata utile?

 Feedback