Saltar al contenido principal

A/B testing en el servidor

Última actualización el 09 sept 20263 min de lectura
Índice de contenidos

En resumen​

La API de entrega del lado del servidor está dirigida a equipos de desarrollo internos que quieren integrar completamente el A/B testing en su propia infraestructura. Las variantes se asignan en el servidor antes de que la página se renderice y entregue, sin ningún JavaScript del lado del cliente. Esto elimina el parpadeo, otorga al equipo de desarrollo control total sobre la implementación y hace posible el testing en arquitecturas donde un snippet clásico del lado del cliente no funciona: configuraciones headless, aplicaciones renderizadas en el servidor o apps móviles nativas.

Cómo funciona​

A/B Testing del lado del servidor

Crea un nuevo experimento en el dashboard de Varify y selecciona Server Side Experiment.

A continuación encontrarás el experimento en el dashboard y desde allí podrás controlar la distribución del tráfico e iniciar el experimento. Allí también encontrarás el Experiment ID y los Variation IDs, que necesitas para la integración.

La integración se realiza a través de dos endpoints de API, que tu equipo de desarrollo integra directamente en la lógica de backend existente.

1. crear usuario POST /ss/{teamId}/users​

La primera vez que un nuevo visitante hace una solicitud, se crea un usuario a través de este endpoint. La API proporciona un userId (UUID), que tu sistema debe persistir - por ejemplo en una cookie, una sesión o tu base de datos. Este ID identifica al usuario para todas las solicitudes futuras.

Ejemplo de respuesta:

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

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

Con el userId guardado, usa el UUID guardado para consultar la variante asignada para un experimento específico. Si aún no se ha asignado ninguna variante, se asignará automáticamente la primera vez que se llame. La asignación es determinista: el mismo usuario siempre recibe la misma variante para el mismo experimento, independientemente de cuántas veces se llame al endpoint.

Ejemplo de respuesta (se ha asignado una variante al usuario):

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

Ejemplo de respuesta (el usuario recibe los originales):​

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

El campo variation contiene el ID de la variante asignada (p. ej. 48838) - puedes encontrar estos IDs en el dashboard de Varify - o null, si el usuario debe ver la variante Original. El objeto tracking con el contexto del experimento se devuelve en ambos casos.

Tu backend utiliza entonces el ID de variante devuelto para decidir qué versión de la página o contenido se renderiza y entrega. Para ello, mapea cada ID de variante a la variante de renderizado correspondiente en tu lógica de backend - null siempre significa: mostrar la versión original.

La configuración del experimento en sí - grupos objetivo, distribución de tráfico, inicio y fin - se puede seguir gestionando cómodamente en el dashboard de Varify.

3. Configurar el tracking​

Para asegurar que el experimento de servidor pueda analizarse en el dashboard, el bloque tracking de la respuesta de GET /ss/{teamId}/experiments/{experimentId}/variations/{userId} debe integrarse en el lado del cliente:

  • El contenido del objeto tracking sin modificar como JSON en una etiqueta type="application/json" data-varify-tracking> -escríbela en el HTML renderizado.
  • Varify entonces activa automáticamente las funciones de tracking, teniendo en cuenta el estado de consentimiento del usuario. Esto también aplica cuando varify.js no participa en el test del lado del cliente en absoluto; un window.varify.setTracking(true) manual no es necesario para eso.
  • Si se omite este paso, solo la configuración del experimento será visible en el dashboard - sin datos de evaluación, ya que la Delivery API en sí no tiene un endpoint para reportar eventos.

Ejemplo de marcado:

Con el userId guardado, usa el UUID guardado para consultar la variante asignada para un experimento específico. Si aún no se ha asignado ninguna variante, se asignará automáticamente la primera vez que se llame. La asignación es determinista: el mismo usuario siempre recibe la misma variante para el mismo experimento, independientemente de cuántas veces se llame al endpoint.

Ejemplo de respuesta (se ha asignado una variante al usuario):

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

Si variation.id y variation.name son null (versión original), el bloque se sigue renderizando - Varify lo trata entonces como una reproducción del original.

Documentación para desarrolladores​

La referencia completa de la API (OpenAPI 3.1) con todos los endpoints, parámetros y códigos de error para tu equipo de desarrollo: https://app.varify.io/ss/docs

En esta página