Configurare la sperimentazione e i test A/B utilizzando i flag delle funzionalità

Le allocazioni dei flag funzionalità di App Lifecycle Manager ti aiutano a testare l'applicazione dividendo le percentuali di traffico. In questo modo, alcuni utenti vedono una variante dell'applicazione, mentre altri ne vedono una diversa, il che ti aiuta a determinare quali varianti o funzionalità hanno più successo (questo processo viene spesso chiamato test A/B). Le allocazioni dei flag funzionalità ti aiutano a definire come suddividere il traffico e a integrare le varianti allocate con la tua applicazione.

Questa guida mostra come definire le varianti, configurare la suddivisione del traffico e integrare le varianti con l'applicazione.

Per semplificare il monitoraggio e l'analisi, devi assegnare ID stringa descrittivi alle varianti (ad es. "sperimentale" e "di base") e utilizzare questi nomi direttamente nel codice e nelle pipeline di analisi.

Prerequisiti

Prima di iniziare, assicurati di avere:

  1. Hai completato la guida rapida Esegui il deployment dei flag funzionalità o la guida rapida Utilizza i flag funzionalità (autonoma).
  2. Un ambiente Google Cloud CLI configurato per gestire le risorse App Lifecycle Manager.

Configura l'allocazione di un flag funzionalità

Per configurare un flag funzionalità sperimentale:

  1. Definisci l'attributo randomizzato (ad es. userID) che verrà utilizzato per il bucketing persistente per garantire un'esperienza coerente per ogni utente.

      gcloud beta app-lifecycle-manager flags attributes create "user-id-attr" \
      --key="userID" \
      --attribute-value-type="STRING" \
      --location=global

  2. Utilizza una distribuzione per definire la suddivisione (ad esempio 50/50), facendo riferimento agli ID delle varianti descrittive.

    # Create a flag with explicitly named variants for the experiment and a 50/50 allocation referencing the custom IDs
gcloud beta app-lifecycle-manager flags create "search-algo-test" \
  --key="search-algo-test" \
  --flag-value-type=BOOL \
  --location="global" \
  --unit-kind="demo-test-unitkind" \
  --variants='[
      {
      "id": "experimental",
      "booleanValue": true
      },
      {
      "id": "baseline",
      "booleanValue": false
      }
  ]'\
  --evaluation-spec='{
      "allocations": [{
          "id": "search-split-50-50",
          "randomizedOn": "userID",
          "slots": [
          {"variant": "baseline", "weight": 50},
          {"variant": "experimental", "weight": 50}
          ]
      }],
      "defaultTarget": "search-split-50-50",
      "attributes": ["projects/PROJECT_ID/locations/global/flagAttributes/user-id-attr"]
  }'

  3. Nel servizio di backend, inizializza l'SDK OpenFeature e inserisci userID nel contesto di valutazione. Utilizza il metodo BooleanValueDetails (o equivalente per la tua lingua) per recuperare variantID (stringa) nella tua applicazione. In questo modo puoi cambiare la logica di backend in base al nome descrittivo anziché solo a un valore booleano.

    // 1. Prepare evaluation context
evalCtx := map[string]any{"userID": currentUser.ID}

// 2. Fetch evaluation details to get the variant name
details, err := client.BooleanValueDetails(ctx, "search-algo-test", false, evalCtx)

// 3. Execute logic based on the Variant ID (string name)
if details.Variant == "experimental" {
    results = search.ExperimentalV2(query)
} else {
    results = search.BaselineV1(query)
}

  4. Utilizza nomi di varianti descrittivi in modo che la verifica e l'analisi generino automaticamente la documentazione. Per controllare le valutazioni, registra la stringa details.Variant insieme alle metriche sul rendimento:

     startTime := time.Now()
 // ... perform search ...
 duration := time.Since(startTime)

 // Audit: Log the descriptive variant name ("experimental" or "baseline")
 logger.Info("Search performed",
    "variant", details.Variant,
    "latency_ms", duration.Milliseconds(),
 )

    Confrontando le metriche del gruppo "Sperimentale" con quelle del gruppo "Di base", puoi analizzare manualmente se il nuovo algoritmo migliora l'efficienza del backend o la pertinenza della ricerca prima di procedere con un'implementazione completa.

Passaggi successivi