Skip to main content

Vue d’ensemble

Introduction

Les tests A/B permettent aux annonceurs de segmenter les utilisateurs qu’ils atteignent sur X afin de comprendre comment optimiser au mieux les performances de leurs campagnes et d’en tirer des enseignements pour orienter leurs stratégies marketing. Ces segments — appelés répartitions de groupes d’utilisateurs — sont aléatoires et mutuellement exclusifs. Grâce à cette randomisation, les facteurs qui influencent les résultats sont répartis de manière équitable. En d’autres termes, il n’existe aucune différence intrinsèque entre les groupes ni entre leurs comportements attendus. Pour cette raison, lorsqu’une seule variation est appliquée à un groupe d’utilisateurs et pas aux autres, l’écart de performance de la campagne peut être attribué à cette variation. Bien qu’il soit possible de tester de nombreuses variations en même temps, nous recommandons fortement de tester une seule variation à la fois. Cela permet d’isoler le facteur causal à l’origine de la différence observée de performance de campagne. Les variations sont définies au niveau de la campagne. Par exemple, si l’annonceur souhaite mesurer l’efficacité d’un nouveau créatif, il doit créer deux campagnes identiques dont la seule différence est le créatif. À l’avenir, nous prévoyons de prendre en charge les variations au niveau du line item.

Cas d’usage

Les tests A/B sont le plus souvent utilisés pour (1) des cas d’usage d’optimisation pour les clients orientés performance qui souhaitent comprendre ce qui fonctionne le mieux sur X afin d’optimiser leur investissement, et (2) des cas d’usage d’apprentissage pour les annonceurs de marque qui souhaitent utiliser les enseignements tirés de ces tests pour orienter leur stratégie marketing.  L’API prend en charge les tests A/B pour n’importe quelle variable de campagne, notamment :
  • Création publicitaire 
  • Ciblage 
  • Type d’enchère
  • Unité d’enchère

Tests A/B

Les tests A/B permettent aux annonceurs de segmenter les utilisateurs qu’ils atteignent sur X afin de comprendre comment optimiser au mieux les performances de leurs campagnes et d’obtenir des enseignements pour orienter leurs stratégies marketing. Ces segments — appelés fractionnements de groupes d’utilisateurs — sont aléatoires et mutuellement exclusifs. Grâce à la randomisation, les facteurs qui influencent les résultats sont répartis de manière égale. En d’autres termes, il n’existe aucune différence intrinsèque entre les groupes ni entre leurs comportements attendus. De ce fait, lorsqu’une seule variation est appliquée à un groupe d’utilisateurs et pas aux autres, l’écart de performance de la campagne peut être attribué à cette variation. Bien qu’il soit possible de tester de nombreuses variations simultanément, nous recommandons vivement de tester une seule variation à la fois. Cela permet d’isoler le facteur causal de la différence de performance de campagne observée. Les variations sont définies au niveau de la campagne ou au niveau du groupe de publicités. Le groupe de publicités est défini via le line item dans l’Ads API. À titre d’exemple de variation au niveau du groupe de publicités, si l’annonceur souhaite tester l’efficacité d’un nouveau visuel, il doit créer une campagne avec deux groupes de publicités identiques où la seule différence est le visuel.

Cas d’utilisation

Les tests A/B sont le plus souvent utilisés pour répondre (1) à des cas d’utilisation d’optimisation pour les clients axés sur la performance qui souhaitent comprendre ce qui fonctionne le mieux sur X afin d’optimiser leur investissement et (2) à des cas d’utilisation liés à l’apprentissage pour les annonceurs de marque qui souhaitent utiliser ces enseignements pour orienter leur stratégie marketing.  L’API prendra en charge les tests A/B pour toute variable de campagne, notamment :
  • Créatif
  • Ciblage
  • Type d’enchère
  • Unité d’enchère

Attributs

Les tests A/B sont représentés sous forme de structures imbriquées. Il existe des champs de niveau supérieur pour le test A/B lui‑même et un tableau d’objets de groupes d’utilisateurs, chacun avec un ensemble de champs qui le décrivent. De manière générale, chaque test A/B doit inclure les informations suivantes.
  • La durée du test, représentée par les champs start_time et end_time
  • Le niveau auquel la répartition aura lieu, représenté par le champ entity_type
  • Au moins deux (et au maximum 30) groupes d’utilisateurs, chacun représenté comme un objet dans le tableau user_groups
Chaque groupe d’utilisateurs doit inclure les informations suivantes.
  • Le pourcentage d’utilisateurs qui doivent être alloués au groupe d’utilisateurs donné, représenté par le champ size
  • Les ID de campagne/ID de line item qui doivent constituer le pool d’utilisateurs pour le groupe d’utilisateurs donné, représentés par le tableau entity_ids
En option, des valeurs de nom et de description peuvent être définies pour les tests A/B et pour les groupes d’utilisateurs. Des informations sur les règles de validation et d’autres contraintes sont disponibles ci‑dessous. D’autres métadonnées, comme l’ID ou l’horodatage de création, sont également incluses, mais sont automatiquement définies par X. Un exemple d’entité de test A/B au niveau de la campagne est présenté ci‑dessous.
Un exemple d’entité de test A/B au niveau de l’élément de campagne est présenté ci-dessous.

Utilisation

Les sous-sections ci-dessous décrivent la création et la mise à jour des tests A/B. Les opérations de lecture et de suppression fonctionnent de la même manière que pour tous les autres endpoints de l’API Ads.

Création

Créez un test A/B à l’aide du endpoint POST accounts/:account_id/ab_tests. Le endpoint accepte uniquement des corps de requête POST au format JSON. Le paramètre Content-Type doit être défini sur application/json. Une fois que l’annonceur a configuré au moins deux campagnes, un test A/B peut être créé. Comme indiqué ci-dessus, les tests A/B doivent inclure : la durée du test, le niveau de répartition et au moins deux groupes d’utilisateurs. Chaque groupe d’utilisateurs doit déclarer le pourcentage d’utilisateurs qui doit lui être attribué, ainsi que les ID de campagne qui doivent constituer son pool d’utilisateurs. Chacun de ces éléments est décrit plus en détail ci‑dessous. Durée du test :
  • Les valeurs start_time et end_time doivent
    • Être dans le futur (par rapport au moment où le test A/B est créé)
    • Chevaucher les dates de diffusion de la campagne/du line item
  • Le test doit durer au moins un jour pour les campagnes qui ne sont pas basées sur une application et au moins cinq jours pour les campagnes basées sur une application
Niveau de répartition :
  • La valeur entity_type peut être définie sur CAMPAIGN ou LINE_ITEM
Groupes d’utilisateurs :
  • Chaque groupe d’utilisateurs est représenté par un objet dans le tableau user_groups
    • Un minimum de deux groupes d’utilisateurs est requis
    • Un maximum de 30 groupes d’utilisateurs est autorisé
  • La taille de chaque groupe d’utilisateurs est définie à l’aide d’une représentation sous forme de chaîne d’une valeur numérique comprise entre 1.00 et 99.00
    • Remarque : Les valeurs de taille entre les objets doivent avoir une somme égale à 100.00
  • Les ID de campagne doivent être spécifiés dans le tableau entity_ids de chaque groupe d’utilisateurs
Vous pouvez éventuellement définir le nom et la description du test A/B ou d’un ou de plusieurs groupes d’utilisateurs. La requête suivante crée un test A/B au niveau de la campagne qui dure quatre jours et comporte deux groupes d’utilisateurs avec 50 % des utilisateurs dans chaque groupe. Le premier groupe d’utilisateurs est basé sur les campagnes f2qcw et f2tht ; le second groupe d’utilisateurs est basé sur les campagnes f2rqi et f2tws. La requête ajoute également des noms et des descriptions à certaines parties de l’entité. 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”}’
Pour les tests A/B au niveau de l’élément de campagne La principale différence entre les tests A/B au niveau de la campagne et au niveau de l’élément de campagne est le entity_type. Nous devons le définir sur ‘entity_type’ = ‘LINE_ITEM’ pour les tests A/B au niveau de l’élément de campagne. Cela s’applique à toutes les actions ci‑dessous sur un test A/B déjà créé.  Exigences :
  1. Tous les éléments de campagne de la campagne de test A/B doivent être inclus dans le test de répartition.
  2. Seule une répartition égale est autorisée au niveau de l’élément de campagne.
  3. Le nombre d’éléments de campagne de groupes d’utilisateurs autorisés dans 1 test de répartition doit être inférieur ou égal à 5. 
  4. Un seul élément de campagne par groupe d’utilisateurs.

Mise à jour

Mettez à jour un test A/B à l’aide de l’endpoint PUT accounts/:account_id/ab_tests/:ab_test_id. Cet endpoint requiert l’envoi d’un bloc JSON dans la requête. L’en-tête Content-Type doit être défini sur application/json. Comme pour les autres endpoints de mise à jour, l’endpoint PUT accounts/:account_id/ab_tests/:ab_test_id exige que l’ID du test A/B soit référencé dans l’URL. En règle générale, les tests A/B ne peuvent être mis à jour que lorsque leur statut est SCHEDULED. Il existe une exception : il est possible de mettre à jour le end_time du test A/B lorsqu’il est LIVE. Cet endpoint accepte du JSON partiel avec des IDs d’objets. Les principes suivants s’appliquent :
  • Pour ajouter ou supprimer des objets ou des éléments, transmettez l’intégralité du tableau (et de ses sous-structures) ; il s’agit d’une opération de remplacement
  • Sinon, modifiez (ajoutez, changez, supprimez) les champs existants en faisant référence aux noms de clés ou aux IDs
    • Pour supprimer un champ, définissez sa valeur sur null
    • Les champs qui ne sont pas transmis ne sont pas modifiés
Par exemple, pour ajouter un troisième groupe d’utilisateurs au test A/B précédemment créé, nous devrions envoyer le tableau user_groups contenant les deux objets de groupes d’utilisateurs existants ainsi que le nouveau que nous souhaitons ajouter. Considérez cela comme une recréation du tableau user_groups ; transmettez les données comme si vous étiez en train de le créer de cette manière dès le départ (ne transmettez pas les IDs des objets de groupes d’utilisateurs). Le tableau user_groups dans la requête de mise à jour pourrait se présenter comme suit.
Remarquez que les valeurs de size des différents objets totalisent toujours 100,00. Si nous ne les avions pas mises à jour pour les deux premiers objets — précédemment définis à 50,00 chacun — la requête aurait échoué. Si, en revanche, nous voulions simplement ajouter une description au premier groupe d’utilisateurs, le tableau user_groups dans la requête de mise à jour serait représenté comme suit.
Nous faisons référence à l’objet de groupe d’utilisateurs par son id et incluons uniquement le champ que nous souhaitons modifier.

Exemples de requêtes

Cette section fournit des exemples supplémentaires de requêtes de mise à jour. Supposons qu’elles soient appelées séquentiellement. Les blocs JSON sont formatés pour une meilleure lisibilité. Les réponses sont omises. Pour effectuer les modifications suivantes, la requête serait la suivante. (Il s’agit du même exemple que celui utilisé précédemment.)
  1. Ajoute un troisième groupe d’utilisateurs sans nom ni description
  2. Modifie le pourcentage d’utilisateurs dans chaque groupe d’utilisateurs
twurl -X PUT -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests/hr7l0” -d ’
Pour effectuer les modifications suivantes, la requête serait la suivante.
  1. Supprime la description du test A/B
  2. Ajoute une description au premier groupe d’utilisateurs
  3. Ajoute un ID d’entité (f2syz) au deuxième groupe d’utilisateurs
twurl -X PUT -H ads-api.x.com “/8/accounts/18ce54d4x5t/ab_tests/hr7l0” -d ’
La troisième modification exige que nous transmettions les deux id d’entité existants ainsi que le nouvel id. Notez qu’aucun changement n’a été apporté au troisième groupe d’utilisateurs. Pour effectuer les modifications suivantes, la requête serait la suivante :
  1. Supprime le deuxième groupe d’utilisateurs
  2. Modifie le pourcentage d’utilisateurs dans chaque groupe d’utilisateurs

Référence de l’API

Tests A/B

GET accounts/:account_id/ab_tests

Récupérer les détails de certains ou de l’ensemble des tests A/B.
URL de la ressource
https://ads-api.x.com/12/accounts/:account_id/ab_tests
Paramètres
Exemple de requête
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests
Exemple de réponse

POST accounts/:account_id/ab_tests

Créer un test A/B. Tous les paramètres sont envoyés dans le corps de la requête et l’en-tête Content-Type doit être défini sur application/json.
URL de la ressource
https://ads-api.x.com/12/accounts/:account_id/ab_tests
Paramètres

Groupes d’utilisateurs

Exemple de requête

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"}'

Exemple de réponse

PUT accounts/:account_id/ab_tests/:ab_test_id

Met à jour le test A/B spécifié. Tous les paramètres sont envoyés dans le corps de la requête et un Content-Type de application/json est requis. Cet endpoint prend en charge le JSON partiel avec des id d’objet. Les principes suivants s’appliquent :
  • Pour ajouter ou supprimer des objets ou des éléments, transmettez l’intégralité du tableau (et ses sous-structures) ; il s’agit d’une opération de remplacement
    • Considérez cela comme le fait de recréer le tableau
  • Sinon, modifiez (changez, ajoutez, supprimez) les champs existants en faisant référence aux noms de clés ou aux id
    • Pour supprimer un champ, affectez-lui la valeur null
    • Les champs qui ne sont pas transmis ne sont pas modifiés
De manière générale, les tests A/B ne peuvent être mis à jour que lorsque le status est SCHEDULED. Il existe une exception : il est possible de mettre à jour le champ end_time du test A/B lorsqu’il est LIVE.
URL de la ressource
https://ads-api.x.com/12/accounts/18ce54d4x5t/:ab_test_id
Paramètres

Groupes d’utilisateurs

Exemple de requête
Cette requête effectue les modifications suivantes :
  1. Supprime la description du test A/B
  2. Modifie l’heure de fin
  3. Ajoute une description au premier groupe d’utilisateurs
  4. Modifie la proportion d’utilisateurs dans chaque groupe d’utilisateurs
  5. Ajoute un ID d’entité (f2syz) au deuxième groupe d’utilisateurs
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"]}]}'
Exemple de réponse

DELETE accounts/:account_id/ab_tests/:ab_test_id

Supprimer le test A/B spécifié. Remarque : la suppression d’un test A/B est irréversible et toute nouvelle tentative de supprimer la ressource renverra un code d’état HTTP 404.
URL de ressource
https://ads-api.x.com/12/accounts/:account_id/ab_tests/:ab_test_id
Paramètres
Exemple de requête
DELETE https://ads-api.x.com/12/accounts/18ce54d4x5t/ab_tests/hr7l0

Exemple de réponse