Configurar experimentos e testes A/B usando flags de recursos

As alocações flag de recurso do App Lifecycle Manager ajudam a testar o aplicativo dividindo as porcentagens de tráfego. Isso permite que alguns usuários vejam uma variante do aplicativo, enquanto outros veem uma variante diferente, ajudando você a determinar quais variantes ou recursos são mais bem-sucedidos. Esse processo é geralmente chamado de teste A/B. As alocações de flags de recursos ajudam a definir como dividir o tráfego e integrar as variantes alocadas ao aplicativo.

Neste guia, mostramos como definir variantes, configurar a divisão de tráfego e integrar variantes ao aplicativo.

Para simplificar o acompanhamento e a análise, atribua IDs de string descritivos às suas variantes (por exemplo, "experimental" e "baseline") e use esses nomes diretamente no seu código e nos pipelines de análise.

Pré-requisitos

Antes de começar, verifique se você atende a estes requisitos:

  1. Concluiu o guia de início rápido sobre como implantar flags de recurso ou usar flags de recurso (guia de início rápido independente).
  2. Um ambiente da Google Cloud CLI configurado para gerenciar recursos do App Lifecycle Manager.

Configurar uma alocação de flag de recurso

Para configurar uma flag de recurso experimental:

  1. Defina o atributo aleatório (por exemplo, userID) que será usado para o agrupamento fixo, garantindo uma experiência consistente para cada usuário.

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

  2. Use uma alocação para definir a divisão (50/50, por exemplo), referenciando seus IDs de variante descritivos.

    # 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. No serviço de back-end, inicialize o SDK do OpenFeature e injete o userID no contexto de avaliação. Use o método BooleanValueDetails (ou equivalente no seu idioma) para recuperar o variantID (string) no seu aplicativo. Isso permite alternar a lógica de back-end com base no nome descritivo, em vez de apenas um 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. Use nomes de variantes descritivos para que sua auditoria e análise gerem documentação automaticamente. Para auditar avaliações, registre a string details.Variant junto com as métricas de performance:

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

    Ao comparar as métricas do grupo "Experimental" com o grupo "De base", é possível analisar manualmente se o novo algoritmo melhora a eficiência do back-end ou a relevância da pesquisa antes de prosseguir com um lançamento completo.

A seguir