Configura la experimentación y las pruebas A/B con marcas de funciones

Las asignaciones de marcas de funciones de App Lifecycle Manager te ayudan a probar tu aplicación dividiendo los porcentajes de tráfico. Esto permite que algunos de tus usuarios vean una variante de tu aplicación, mientras que otros ven una diferente, lo que te ayuda a determinar qué variantes o funciones son más exitosas (este proceso suele denominarse pruebas A/B). Las asignaciones de marcas de funciones te ayudan a definir cómo dividir tu tráfico y a integrar las variantes asignadas con tu aplicación.

En esta guía, se muestra cómo definir variantes, configurar la división del tráfico y cómo integrar variantes con tu aplicación.

Para simplificar el seguimiento y el análisis, debes asignar IDs de cadenas descriptivas a tus variantes (p.ej., "experimental" y "baseline") y usar estos nombres directamente en tu código y en las canalizaciones de análisis.

Requisitos previos

Antes de comenzar, asegúrate de contar con los siguientes aspectos:

  1. Completaste la guía de inicio rápido Implementar marcas de funciones o Usar marcas de funciones (guía de inicio rápido independiente).
  2. Un entorno de Google Cloud CLI configurado para administrar recursos de App Lifecycle Manager.

Configura una asignación de marcas de funciones

Para configurar una marca de función experimental, haz lo siguiente:

  1. Define el atributo aleatorio (p.ej., userID) que se usará para el almacenamiento en buckets persistente para garantizar una experiencia coherente para cada usuario.

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

  2. Usa una asignación para definir la división (50/50, por ejemplo) y haz referencia a tus IDs de variantes descriptivas.

    # 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. En tu servicio de backend, inicializa el SDK de OpenFeature y, luego, inserta el userID en el contexto de evaluación. Usa el método BooleanValueDetails (o su equivalente para tu idioma) para recuperar el variantID (cadena) en tu aplicación. Esto te permite cambiar la lógica de backend según el nombre descriptivo en lugar de solo un valor 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. Usa nombres de variantes descriptivas para que tu auditoría y análisis generen documentación automáticamente. Para auditar las evaluaciones, registra la cadena details.Variant junto con tus métricas de rendimiento:

     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(),
 )

    Si comparas las métricas del grupo "Experimental" con las del grupo "Baseline", puedes analizar de forma manual si el algoritmo nuevo mejora la eficiencia del backend o la relevancia de la búsqueda antes de continuar con un lanzamiento completo.

¿Qué sigue?

  • Obtén información para solucionar problemas.