Test A/B lato server
Indice dei contenuti
Breve e dolce
L'API di consegna lato server è destinata ai team di sviluppo interni che desiderano integrare completamente i test A/B nella propria infrastruttura. Le varianti vengono assegnate sul lato server prima che la pagina venga renderizzata e consegnata, senza alcun JavaScript lato client. In questo modo si elimina il flickering, si dà al team di sviluppo il pieno controllo sull'implementazione e si rendono possibili i test in architetture in cui un classico snippet lato client non funziona: configurazioni Headless, applicazioni renderizzate lato server o applicazioni mobili native.
Come funziona
Creare un nuovo esperimento nella dashboard Varify e selezionare Esperimento lato server da.
L'esperimento si trova nella dashboard e da lì si può controllare la distribuzione del traffico e avviare l'esperimento. Lì si troverà anche l'opzione ID esperimento e il ID della variante, che servono per l'integrazione.
L'integrazione avviene tramite due endpoint API, che il team di sviluppo integra direttamente nella logica di backend esistente.
1. creare un utente POST /ss/{teamId}/utenti
La prima volta che un nuovo visitatore effettua una richiesta, viene creato un utente tramite questo endpoint. L'API fornisce un ID utente (UUID), che il sistema deve conservare, ad esempio in un cookie, in una sessione o nel database. Questo ID identifica l'utente per tutte le richieste future.
Esempio di risposta:
{
"userId": "a9533ef0-bbc4-47a1-90b8-2f2d3bba43a3"
}
Richiamare la seconda variante GET /ss/{teamId}/experiments/{experimentId}/variations/{userId}
Con il salvataggio ID utente Utilizzare l'UUID salvato per interrogare la variante assegnata per un esperimento specifico. Se non è ancora stata assegnata una variante, questa verrà assegnata automaticamente alla prima chiamata. L'assegnazione è deterministica: lo stesso utente riceve sempre la stessa variante per lo stesso esperimento, indipendentemente dalla frequenza con cui viene chiamato l'endpoint.
Esempio di risposta (all'utente è stata assegnata una variante):
{
"variation": 48838,
"tracking": {
"experiment": {
"id": 32596,
"name": "Homepage CTA Test"
},
"variation": {
"id": 48838,
"name": "variation-1"
}
}
}
Esempio di risposta (l'utente riceve gli originali):
{
"variation": null,
"tracking": {
"experiment": {
"id": 32596,
"name": "Homepage CTA Test"
},
"variation": {
"id": null,
"name": null
}
}
}
Il campo variazione contiene l'elemento ID della variazione assegnata (es. 48838) - è possibile trovare questi ID nella dashboard Varify - oppure zero, se l'utente ha l'opzione Variante originale dovrebbe vedere. Il tracciamento-L'oggetto con il contesto dell'esperimento viene restituito in entrambi i casi.
Il backend utilizza quindi l'ID di variazione restituito per decidere quale versione della pagina o del contenuto viene resa e consegnata. Per fare ciò, mappare ogni ID di variazione alla variante di rendering corrispondente nella logica del backend. zero significa sempre: mostra la versione originale.
La configurazione dell'esperimento stesso - gruppi target, distribuzione del traffico, avvio e arresto - può essere gestita comodamente nella dashboard di Varify.
Documentazione per gli sviluppatori
Il riferimento completo all'API (OpenAPI 3.1) con tutti gli endpoint, i parametri e i codici di errore per il vostro team di sviluppo: https://app.varify.io/ss/docs