Passa al contenuto principale

A/B testing lato server

Ultimo aggiornamento il 09 set 20263 min di lettura
Indice

In breve​

L'API di delivery lato server è rivolta ai team di sviluppo interni che vogliono integrare completamente l'A/B testing nella propria infrastruttura. Le varianti vengono assegnate lato server prima che la pagina venga renderizzata e consegnata - senza alcun JavaScript lato client. Questo elimina lo sfarfallio, dà al team di sviluppo il pieno controllo sull'implementazione e rende possibile il testing in architetture in cui uno snippet classico lato client non funziona: setup headless, applicazioni renderizzate lato server o app mobile native.

Come funziona​

Test A/B lato server

Crea un nuovo esperimento nella dashboard di Varify e seleziona Server Side Experiment da.

Troverai quindi l'esperimento nella dashboard e da lì potrai controllare la distribuzione del traffico e avviare l'esperimento. Lì troverai anche l'Experiment ID e i Variation IDs, necessari per l'integrazione.

L'integrazione avviene tramite due endpoint API, che il tuo team di sviluppo integra direttamente nella logica di backend esistente.

1. crea utente POST /ss/{teamId}/users​

La prima volta che un nuovo visitatore effettua una richiesta, viene creato un utente tramite questo endpoint. L'API fornisce uno userId (UUID), che il tuo sistema deve conservare - ad esempio in un cookie, una sessione o il tuo database. Questo ID identifica l'utente per tutte le richieste future.

Esempio di risposta:

{
  "userId": "a9533ef0-bbc4-47a1-90b8-2f2d3bba43a3"
}

Richiama la 2ª variante GET /ss/{teamId}/experiments/{experimentId}/variations/{userId}​

Con l'userId salvato, usa l'UUID salvato per interrogare la variante assegnata per un esperimento specifico. Se non è ancora stata assegnata alcuna variante, verrà assegnata automaticamente al primo richiamo. L'assegnazione è deterministica - lo stesso utente riceve sempre la stessa variante per lo stesso esperimento, indipendentemente da quante volte 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 variation contiene o l'ID della variazione assegnata (ad es. 48838) - puoi trovare questi ID nella dashboard di Varify - oppure null, se l'utente deve vedere la variante Originale. L'oggetto tracking con il contesto dell'esperimento viene restituito in entrambi i casi.

Il tuo backend usa quindi l'ID della variazione restituito per decidere quale versione della pagina o del contenuto viene renderizzata e consegnata. Per fare ciò, mappa ogni ID di variazione alla corrispondente variante di rendering nella logica del tuo backend - null significa sempre: mostra la versione originale.

La configurazione dell'esperimento stessa - gruppi target, distribuzione del traffico, avvio e interruzione - può comunque essere gestita comodamente nella dashboard di Varify.

3. Configura il tracciamento​

Per garantire che l'esperimento server possa essere analizzato nella dashboard, il blocco tracking della risposta di GET /ss/{teamId}/experiments/{experimentId}/variations/{userId} deve essere integrato lato client:

  • Il contenuto dell'oggetto tracking invariato come JSON in un tag type="application/json" data-varify-tracking> scritto nell'HTML renderizzato.
  • Varify attiva quindi automaticamente le funzioni di tracciamento—tenendo conto dello stato di consenso dell'utente. Questo vale anche quando varify.js lato client non è altrimenti coinvolto nel test; non è necessario un window.varify.setTracking(true) manuale per questo.
  • Se questo passaggio viene omesso, nella dashboard sarà visibile solo la configurazione dell'esperimento—nessun dato di valutazione, poiché la Delivery API stessa non dispone di un endpoint per la segnalazione degli eventi.

Esempio di markup:

Con l'userId salvato, usa l'UUID salvato per interrogare la variante assegnata per un esperimento specifico. Se non è ancora stata assegnata alcuna variante, verrà assegnata automaticamente al primo richiamo. L'assegnazione è deterministica - lo stesso utente riceve sempre la stessa variante per lo stesso esperimento, indipendentemente da quante volte viene chiamato l'endpoint.

Esempio di risposta (all'utente è stata assegnata una variante):

<script type="application/json" data-varify-tracking>
{
  "experiment": {
    "id": 32596,
    "name": "Homepage CTA Test"
  },
  "variation": {
    "id": 48838,
    "name": "variation-1"
  }
}
</script>

Se variation.id e variation.name sono null (versione originale), il blocco viene comunque renderizzato—Varify lo tratta quindi come una riproduzione dell'originale.

Documentazione per sviluppatori​

Il riferimento completo dell'API (OpenAPI 3.1) con tutti gli endpoint, i parametri e i codici di errore per il tuo team di sviluppo: https://app.varify.io/ss/docs

Su questa pagina