Pular para o conteúdo principal

Teste A/B server-side

Última atualização em 09 de set. de 20263 min de leitura
Índice

Resumo​

A API de entrega server-side destina-se a equipas de desenvolvimento internas que querem integrar totalmente o teste A/B na sua própria infraestrutura. As variantes são atribuídas no lado do servidor antes da página ser renderizada e entregue - sem qualquer JavaScript client-side. Isto elimina o flickering, dá à equipa de desenvolvimento controlo total sobre a implementação e torna possível testar em arquiteturas onde um snippet client-side clássico não funciona: setups headless, aplicações renderizadas no lado do servidor ou apps móveis nativas.

Como funciona​

Teste A/B Server Side

Cria uma nova experiência no dashboard da Varify e seleciona Server Side Experiment.

De seguida, encontrarás a experiência no dashboard e, a partir daí, podes controlar a distribuição de tráfego e iniciar a experiência. Aí também encontrarás o Experiment ID e os Variation IDs, que precisas para a integração.

A integração funciona através de dois endpoints de API, que a tua equipa de desenvolvimento integra diretamente na lógica de backend existente.

1. criar utilizador POST /ss/{teamId}/users​

Na primeira vez que um novo visitante faz um pedido, é criado um utilizador através deste endpoint. A API fornece um userId (UUID), que o teu sistema deve persistir - por exemplo, num cookie, numa sessão ou na tua base de dados. Este ID identifica o utilizador para todos os pedidos futuros.

Exemplo de resposta:

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

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

Com o userId guardado, usa o UUID guardado para consultar a variante atribuída para uma experiência específica. Se ainda não tiver sido atribuída nenhuma variante, ela será atribuída automaticamente na primeira chamada. A atribuição é determinística - o mesmo utilizador recebe sempre a mesma variante para a mesma experiência, independentemente de quantas vezes o endpoint é chamado.

Exemplo de resposta (o utilizador recebeu uma variante atribuída):

{
  "variation": 48838,
  "tracking": {
    "experiment": {
      "id": 32596,
      "name": "Homepage CTA Test"
    },
    "variation": {
      "id": 48838,
      "name": "variation-1"
    }
  }
}

Exemplo de resposta (o utilizador recebe os originais):​

{
  "variation": null,
  "tracking": {
    "experiment": {
      "id": 32596,
      "name": "Homepage CTA Test"
    },
    "variation": {
      "id": null,
      "name": null
    }
  }
}

O campo variation contém ou o ID da variação atribuída (por exemplo, 48838) - podes encontrar estes IDs no dashboard da Varify - ou null, se o utilizador deve ver a Original variant. O objeto tracking com o contexto da experiência é devolvido em ambos os casos.

O teu backend usa então o ID de variação devolvido para decidir qual versão da página ou conteúdo é renderizada e entregue. Para isso, mapeia cada ID de variação para a variante de renderização correspondente na tua lógica de backend - null significa sempre: mostrar a versão original.

A configuração da experiência em si - grupos-alvo, distribuição de tráfego, início e fim - continua a poder ser gerida de forma conveniente no dashboard da Varify.

3. Configurar o tracking​

Para garantir que a experiência server-side pode ser analisada no dashboard, o bloco tracking da resposta de GET /ss/{teamId}/experiments/{experimentId}/variations/{userId} deve ser integrado no lado do cliente:

  • O conteúdo do objeto tracking sem alterações como JSON numa tag type="application/json" data-varify-tracking> escrita no HTML renderizado.
  • A Varify aciona então automaticamente as funções de tracking—tendo em conta o estado de consentimento do utilizador. Isto também se aplica quando o varify.js do lado do cliente não está de todo envolvido no teste; não é necessário um window.varify.setTracking(true) manual para isso.
  • Se este passo for omitido, apenas a configuração da experiência será visível no dashboard—sem dados de avaliação, uma vez que a Delivery API em si não tem um endpoint para reportar eventos.

Exemplo de markup:

Com o userId guardado, usa o UUID guardado para consultar a variante atribuída para uma experiência específica. Se ainda não tiver sido atribuída nenhuma variante, ela será atribuída automaticamente na primeira chamada. A atribuição é determinística - o mesmo utilizador recebe sempre a mesma variante para a mesma experiência, independentemente de quantas vezes o endpoint é chamado.

Exemplo de resposta (o utilizador recebeu uma variante atribuída):

<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 forem null (versão original), o bloco continua a ser renderizado—a Varify trata isso então como uma reprodução do original.

Documentação para programadores​

A referência completa da API (OpenAPI 3.1) com todos os endpoints, parâmetros e códigos de erro para a tua equipa de desenvolvimento: https://app.varify.io/ss/docs

Nesta página