Skip to main content

Descripción general

Introducción

Las pruebas A/B permiten a los anunciantes segmentar a los usuarios a los que alcanzan en X para entender cómo optimizar mejor el rendimiento de las campañas y obtener conclusiones que sirvan para orientar sus estrategias de marketing. Estos segmentos —denominados divisiones de grupos de usuarios— se asignan de forma aleatoria y son mutuamente excluyentes. Con la aleatorización, los factores que influyen en los resultados se distribuyen de manera uniforme. En otras palabras, no hay diferencias inherentes entre los grupos ni en sus comportamientos esperados. Debido a esto, cuando se aplica una única variación a un grupo de usuarios y no a los demás, la diferencia en el rendimiento de la campaña se puede atribuir a esa variación. Si bien es posible probar muchas variaciones a la vez, recomendamos encarecidamente probar una sola variación por vez. Esto aísla el factor causal de la diferencia observada en el rendimiento de la campaña. Las variaciones se establecen a nivel de campaña. Por ejemplo, si el anunciante quiere probar la eficacia de un nuevo creativo, debe crear dos campañas idénticas donde la única diferencia sea ese creativo. En el futuro, planeamos admitir variaciones a nivel de línea de pedido.

Casos de uso

Las pruebas A/B se utilizan con mayor frecuencia para respaldar (1) casos de uso de optimización para clientes orientados al rendimiento que quieren comprender qué funciona mejor en X a fin de optimizar su inversión y (2) casos de uso de aprendizaje para anunciantes de marca que quieren utilizar esos aprendizajes para orientar su estrategia de marketing.  La API admitirá pruebas A/B para cualquier variable de campaña, incluidos:
  • Creatividad 
  • Segmentación 
  • Tipo de puja
  • Unidad de puja

Pruebas A/B

Las pruebas A/B permiten a los anunciantes segmentar a los usuarios a los que llegan en X para que puedan entender cómo optimizar mejor el rendimiento de las campañas y extraer conclusiones que orienten sus estrategias de marketing. Estos segmentos —denominados divisiones de grupos de usuarios— se asignan de forma aleatoria y son mutuamente excluyentes. Con la aleatorización, los factores que influyen en los resultados se distribuyen por igual. En otras palabras, no existen diferencias inherentes entre los grupos ni en sus comportamientos esperados. Debido a esto, cuando se aplica una única variación a un grupo de usuarios y no a los demás, la diferencia en el rendimiento de la campaña puede atribuirse a esa variación. Si bien es posible probar muchas variaciones a la vez, recomendamos encarecidamente probar una sola variación cada vez. Esto aísla el factor causal de la diferencia observada en el rendimiento de la campaña. Las variaciones se configuran a nivel de campaña o de grupo de anuncios. El grupo de anuncios se configura a través de line item en Ads API. Como ejemplo de una variación a nivel de grupo de anuncios, si el anunciante quiere probar la eficacia de una nueva creatividad, debe crear una campaña con 2 grupos de anuncios idénticos donde la única diferencia sea la creatividad.

Casos de uso

Las pruebas A/B se usan con mayor frecuencia para respaldar (1) casos de uso de optimización para clientes orientados al rendimiento que quieren entender qué funciona mejor en X a fin de optimizar su inversión y (2) casos de uso de aprendizaje para anunciantes de marca que quieren aprovechar esos aprendizajes para definir su estrategia de marketing.  La API permitirá realizar pruebas A/B para cualquier variable de campaña, incluidas:
  • Creatividades
  • Segmentación
  • Tipo de puja
  • Unidad de puja

Atributos

Las pruebas A/B se representan como estructuras anidadas. Hay campos de nivel superior para la propia prueba A/B y un array de objetos de grupos de usuarios, cada uno con un conjunto de campos que lo describen. A alto nivel, toda prueba A/B debe incluir la siguiente información.
  • La duración de la prueba, representada por los campos start_time y end_time
  • El nivel en el que se producirá la división, representado por el campo entity_type
  • Al menos dos (y como máximo 30) grupos de usuarios, cada uno representado como un objeto en el array user_groups
Cada grupo de usuarios debe incluir la siguiente información.
  • El porcentaje de usuarios que se debe asignar al grupo de usuarios dado, representado por el campo size
  • Los ids de campañas / ids de elementos de línea que deben conformar el conjunto de usuarios para el grupo de usuarios dado, representados por el array entity_ids
Opcionalmente, se pueden establecer valores de nombre y descripción para las pruebas A/B y para los grupos de usuarios. La información sobre las reglas de validación y otras restricciones se encuentra a continuación. Otros metadatos, como el id o la marca de tiempo de creación, también se incluyen, pero se establecen automáticamente por X. A continuación se muestra un ejemplo de entidad de prueba A/B a nivel de campaña.
A continuación se muestra un ejemplo de entidad de prueba A/B a nivel de line item.

Uso

Las siguientes subsecciones describen cómo crear y actualizar pruebas A/B. Las operaciones de lectura y eliminación funcionan igual que en todos los demás endpoints de la API de anuncios.

Creación

Crea una prueba A/B usando el endpoint POST accounts/:account_id/ab_tests. El endpoint solo acepta cuerpos POST en JSON. El Content-Type debe establecerse en application/json. Una vez que el anunciante haya configurado dos o más campañas, se puede crear una prueba A/B. Como se indicó arriba, las pruebas A/B deben incluir: duración de la prueba, nivel de división y al menos dos grupos de usuarios. Cada grupo de usuarios debe declarar el porcentaje de usuarios que se le debe asignar, así como los IDs de campaña que deben conformar su conjunto de usuarios. Cada uno de estos aspectos se describe con más detalle a continuación. Duración de la prueba:
  • Los valores start_time y end_time deben
    • Estar en el futuro (en relación con el momento en que se crea la prueba A/B)
    • Superponerse con las fechas de ejecución de la campaña/line item
  • La prueba debe durar al menos un día para campañas que no están basadas en App y al menos cinco días para campañas basadas en App
Nivel de división:
  • El entity_type se puede establecer en CAMPAIGN o LINE_ITEM
Grupos de usuarios:
  • Cada grupo de usuarios se representa como un objeto en el array user_groups
    • Se requieren al menos dos grupos de usuarios
    • Se permiten como máximo 30 grupos de usuarios
  • El tamaño de cada grupo de usuarios se establece usando una representación como cadena de un valor numérico entre 1.00 y 99.00
    • Nota: Los valores de tamaño de todos los objetos deben sumar 100.00
  • Los IDs de campaña deben especificarse en el array entity_ids de cada grupo de usuarios
Opcionalmente, establece el nombre y la descripción de la prueba A/B o de uno o más grupos de usuarios. La siguiente solicitud crea una prueba A/B a nivel de campaña que dura cuatro días y tiene dos grupos de usuarios con un 50% de usuarios en cada grupo. El primer grupo de usuarios se basa en las campañas f2qcw y f2tht; el segundo grupo de usuarios se basa en las campañas f2rqi y f2tws. La solicitud también agrega nombres y descripciones a algunas partes de la entidad. twurl -X POST -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests” -d ’{“end_time”: “2020-12-05T01:00:00Z”, “entity_type” : “CAMPAIGN”, “start_time”: “2020-12-01T01:00:00Z”, “user_groups”: [{“entity_ids”: [“f2qcw”, “f2tht”], “size”: “50.00”, “name”: “first group”},{“entity_ids”: [“f2rqi”, “f2tws”], “size”: “50.00”, “name”: “second group”, “description”: “second AB test group”}], “name”: “first AB test”, “description”: “documentation example”}’
Para pruebas A/B a nivel de line item La principal diferencia entre las pruebas A/B a nivel de campaña y a nivel de line item es el valor de entity_type. Debemos configurarlo como ‘entity_type’ = ‘LINE_ITEM’ para las pruebas A/B a nivel de line item. Esto se aplica a todas las acciones sobre una prueba A/B ya creada que se indican a continuación.  Requisitos:
  1. Todos los line items de la campaña de pruebas A/B deben incluirse en el split test.
  2. Solo se permite una división equitativa a nivel de line item.
  3. El número de line items de grupos de usuarios permitidos en 1 split test debe ser menor o igual a 5. 
  4. Solo 1 line item por grupo de usuarios.

Actualización

Actualiza una prueba A/B usando el endpoint PUT accounts/:account_id/ab_tests/:ab_test_id. El endpoint requiere que se envíe un blob JSON en la solicitud. El Content-Type debe establecerse en application/json. Al igual que otros endpoints de actualización, el endpoint PUT accounts/:account_id/ab_tests/:ab_test_id requiere que el id de la prueba A/B se incluya en la URL. En general, las pruebas A/B solo se pueden actualizar mientras el estado es SCHEDULED. Hay una excepción: es posible actualizar el end_time de la prueba A/B mientras está LIVE. Este endpoint admite JSON parcial con id de objetos. Se aplican los siguientes principios:
  • Para agregar o eliminar objetos o elementos, pasa el array completo (y sus subestructuras); esta es una operación de reemplazo
  • De lo contrario, modifica (cambia, agrega, elimina) los campos existentes haciendo referencia a nombres de clave o id
    • Para eliminar un campo, establece su valor en null
    • Los campos que no se pasan no se modifican
Por ejemplo, agregar un tercer grupo de usuarios a la prueba A/B creada anteriormente requeriría que enviáramos el array user_groups con los dos objetos de grupo de usuarios existentes, así como con el nuevo que queremos agregar. Piensa en esto como recrear el array user_groups; pasa los datos como si lo estuvieras creando de esta manera desde el principio (no envíes id de objetos de grupos de usuarios). El array user_groups en la solicitud de actualización podría representarse de la siguiente manera.
Observa que los valores de size de los objetos aún suman 100.00. Si no los hubiéramos actualizado para los dos primeros objetos —antes establecidos en 50.00 cada uno—, la solicitud habría fallado. Si, en cambio, solo quisiéramos agregar una descripción al primer grupo de usuarios, el array user_groups en la solicitud de actualización tendría el siguiente aspecto.
Hacemos referencia al objeto de grupo de usuarios por su id y solo incluimos el campo que queremos modificar.

Ejemplos de solicitudes

Esta sección proporciona ejemplos adicionales de solicitudes de actualización. Considéralas como si se ejecutaran de forma secuencial. Los bloques JSON están formateados para facilitar la lectura. Las respuestas se omiten. Para aplicar las siguientes modificaciones, la solicitud se representaría de la siguiente manera. (Es el mismo ejemplo utilizado anteriormente).
  1. Agrega un tercer grupo de usuarios sin nombre ni descripción
  2. Cambia el porcentaje de usuarios en cada grupo de usuarios
twurl -X PUT -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests/hr7l0” -d ’
Para realizar las siguientes modificaciones, la solicitud sería la siguiente:
  1. Elimina la descripción de la prueba A/B
  2. Agrega una descripción al primer grupo de usuarios
  3. Agrega un id de entidad (f2syz) al segundo grupo de usuarios
twurl -X PUT -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests/hr7l0” -d ’
La tercera modificación requiere que incluyamos las dos ID de entidad existentes junto con la nueva. Observa que no se hicieron cambios en el tercer grupo de usuarios. Para realizar las siguientes modificaciones, la solicitud se representaría de la siguiente manera:
  1. Elimina el segundo grupo de usuarios
  2. Cambia el porcentaje de usuarios en cada grupo de usuarios

Referencia de la API

Pruebas A/B

GET accounts/:account_id/ab_tests

Recupera los detalles de algunas o todas las pruebas A/B.
URL del recurso
https://ads-api.x.com/12/accounts/:account_id/ab_tests
Parameters
Ejemplo de solicitud
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests
Respuesta de ejemplo

POST accounts/:account_id/ab_tests

Crea una nueva prueba A/B. Todos los parámetros se envían en el cuerpo de la solicitud y es obligatorio usar un Content-Type de application/json.
URL del recurso
https://ads-api.x.com/12/accounts/:account_id/ab_tests
Parámetros

Grupos de usuarios

Ejemplo de solicitud

POST https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests -d '{"end_time": "2022-05-30T01:00:00Z", "entity_type" : "CAMPAIGN", "start_time": "2022-05-25T01:00:00Z", "user_groups": [{"entity_ids": ["f2qcw", "f2tht"], "size": "50.00", "name": "first group"},{"entity_ids": ["f2rqi", "f2tws"], "size": "50.00", "name": "second group", "description": "second AB test group"}], "name": "first AB test", "description": "documentation example"}'

Ejemplo de respuesta

PUT accounts/:account_id/ab_tests/:ab_test_id

Actualiza la prueba A/B especificada. Todos los parámetros se envían en el cuerpo de la solicitud y es obligatorio que el Content-Type sea application/json. Este endpoint admite JSON parcial con id de objeto. Se aplican los siguientes principios:
  • Para agregar o eliminar objetos o elementos, envía el array completo (y sus subestructuras); esta es una operación de reemplazo
    • Piensa en esto como volver a crear el array
  • En caso contrario, modifica (cambia, agrega, elimina) los campos existentes haciendo referencia a los nombres de las claves o a los id
    • Para eliminar un campo, establece su valor en null
    • Los campos que no se envían no se modifican
En general, las pruebas A/B solo se pueden actualizar mientras el status es SCHEDULED. Hay una excepción: es posible actualizar el end_time de la prueba A/B mientras está LIVE.
URL del recurso
https://ads-api.x.com/12/accounts/18ce54d4x5t/:ab_test_id
Parámetros

Grupos de usuarios

Ejemplo de solicitud
Esta solicitud realiza las siguientes modificaciones:
  1. Elimina la descripción de la prueba A/B
  2. Cambia la hora de finalización
  3. Agrega una descripción al primer grupo de usuarios
  4. Cambia el porcentaje de usuarios en cada grupo de usuarios
  5. Agrega un ID de entidad (f2syz) al segundo grupo de usuarios
PUT https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests/hr7l0 -d '{"description": null, "end_time": "2022-06-01T01:00:00Z", "user_groups": [{"id": "p1bcx", "description": "first AB test group", "size": "60.00"},{"id": "p1bcy", "size": "40.00", "entity_ids": ["f2rqi", "f2tws", "f2syz"]}]}'
Ejemplo de respuesta

DELETE accounts/:account_id/ab_tests/:ab_test_id

Elimina la prueba A/B especificada. Nota: Eliminar una prueba A/B no se puede deshacer y los intentos posteriores de eliminar el recurso devolverán un código de estado HTTP 404.
URL del recurso
https://ads-api.x.com/12/accounts/:account_id/ab_tests/:ab_test_id
Parámetros
Ejemplo de solicitud
DELETE https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests/hr7l0

Respuesta de ejemplo