Audiences personnalisées
Il existe plusieurs façons pour les partenaires de créer des Audiences personnalisées. Veuillez noter que vous ne pouvez pas exclure les audiences personnalisées similaires (lookalike) du ciblage. De plus, vous ne pouvez pas cibler à la fois une audience personnalisée et une audience personnalisée similaire (lookalike) au sein du même élément de campagne publicitaire (groupe de publicités). Gestion des audiences Les audiences peuvent être gérées via des partenaires d’audience et des partenaires Ads API. Nous proposons une série d’endpoints dans l’API pour accéder aux audiences personnalisées et les gérer. Pour les informations relatives aux audiences personnalisées, nous proposons 2 endpoints :- GET accounts/:account_id/custom_audiences
- GET accounts/:account_id/custom_audiences/:custom_audience_id




- L’ID utilisateur transmis est correct et non mal formé.
- Les noms d’audience transmis sont corrects et correspondent aux mises à jour de membres précédentes.
- Veuillez confirmer la réponse aux commandes POST.
- Veuillez confirmer que le pixel ID Sync est correctement implémenté et, comme décrit par le processus ID Sync, qu’un nombre suffisant d’utilisateurs ont visité le site en question pour pouvoir faire la correspondance des utilisateurs. Les utilisateurs non mappés dans les mises à jour de membres ne seront pas traduits en utilisateurs ciblés.
- La taille minimale d’une audience est de 100 utilisateurs (après correspondance). Si une audience avec moins de 500 utilisateurs est mise en correspondance, elle ne sera pas disponible pour le ciblage dans l’interface utilisateur X Ads.
- Le traitement des fichiers d’audience prend généralement 4 à 6 heures, mais cela dépendra de la taille du fichier. Une fois le fichier traité, les audiences sont disponibles dans l’interface utilisateur X Ads.
- Taux de correspondance = utilisateurs X actifs sur 90 jours / nombre d’utilisateurs fournis
- Vous pouvez fournir un fichier d’audience de test et utiliser « keltonlynn » comme handle d’annonceur. Nous pourrons alors vérifier que le fichier est correctement ingéré et chargé dans l’interface X.
p_user_id) ?
- C’est l’identifiant utilisé par votre entreprise pour identifier de manière unique chacun de vos clients.
- Cela peut être une adresse e-mail, un device ID, un @handle X ou un ID.
- Elle sera fournie par un e-mail chiffré. Veuillez fournir votre clé PGP publique à mpp-inquiry@x.com et nous vous enverrons un e-mail de test pour vérifier que tout fonctionne. Une fois la vérification effectuée, nous vous enverrons la clé HMAC.
- X fournira un fichier de test (contenant des exemples d’adresses e-mail, de device IDs, etc.) et un fichier de hachage résultant, que vous pourrez utiliser pour vérifier vos résultats.
- Non, il n’y a pas de limite de taille pour le fichier de correspondance de données complet.
- Une fois le fichier reçu par X, il faudra environ 1 jour pour traiter le fichier.

p_user_id) et les ID X (tw_id). Cette opération sera effectuée régulièrement tous les 2 à 3 mois pour garantir une mise à jour correcte. Une fois la correspondance terminée, X communiquera à l’entreprise, par e‑mail, un taux de correspondance de référence issu de ce fichier.
Le format de ce fichier doit être :
Convention de nommage : FullDataMatch.[CompanyName].txt
Algorithme de hachage : HMAC_SHA-256
Format :
Colonne 1 : valeur hachée HMAC des identifiants courants
Colonne 2 : ID utilisateur partenaire (unique par utilisateur, non unique dans le fichier)
Délimiteur de colonnes (CSV) : des virgules seront utilisées pour séparer l’identifiant utilisateur courant haché de l’ID partenaire
Valeurs séparées par des sauts de ligne
- Ex. : si l’enregistrement utilisateur A a l’ID utilisateur partenaire 1 et les identifiants courants 1, 2 et 3 :
*Voir la section Instructions de hachage ci‑dessous pour les identifiants utilisateur courants
2. Listes de segments personnalisés
L’entreprise fournira des listes d’utilisateurs sous forme de
p_user_id pour créer des audiences personnalisées pour les clients, en vue d’un ciblage sur X.
- Valeurs séparées par des sauts de ligne
p_user_id-
- (Identique à ce qui est fourni dans la section 1. Correspondance de données complète ci‑dessus. Si la valeur fournie dans la correspondance de données complète est hachée, l’entreprise fournira la même valeur hachée dans le fichier d’audience. Si la valeur fournie n’est pas hachée, l’entreprise fournira la valeur non hachée.)
- Valeurs séparées par des retours à la ligne
- Identifiant utilisateur courant haché (c.-à-d. adresse e-mail)
- Suivre les conventions de nommage de fichiers décrites ci-dessous
- Suivre les instructions de hachage pour les adresses e-mail ci-dessous (voir la section Instructions de hachage)
- audiencename : le nom de l’audience personnalisée. Ce champ est le nom qui sera affiché lors de la sélection de l’audience dans l’interface de configuration des campagnes ads.x.com, par exemple brand_loyalty_card_holders.
- partnername : nom de la société fournissant les données pour le compte de l’annonceur, par exemple company_name.
- handle : compte X (@handle) qui aura accès aux audiences personnalisées, par exemple @pepsi, @dietpepsi.
- operation : new, add, remove, removeall, replace (détails ci‑dessous)
- timestamp : horodatage Unix (epoch) standard en secondes, utilisé pour garantir que chaque fichier d’audience téléversé est unique
- filetype : le fichier doit être au format *.txt
- Ceci peut être utilisé pour une liste exhaustive d’utilisateurs qui se sont désinscrits de l’Annonceur.
- X ne prendra en compte que la dernière liste fournie dans ce fichier et l’appliquera à toutes les audiences existantes et futures pour les utilisateurs X correspondants au moment où ce fichier a été fourni et traité.
@It92I6Ev2B.Com
Après normalisation : testemail_organisational_baseball+884@it92i6ev2b.com
Valeur hachée : 74d9584eded0ad1e5572a1c1849f3716751d371d6117a6155dad5363f4b4fbec
Remarque : le nombre exact de caractères, aussi bien pour le HMAC encodé que pour la clé, peut varier en fonction de l’entrée et de l’encodage ; le nombre de caractères précis peut donc différer.
Nous appliquerons les mêmes exigences en matière de hachage des identifiants d’appareil à l’aide de l’algorithme de hachage SHA-256 et d’un sel commun que nous mettons à disposition de nos partenaires de données. Nous supprimons les espaces comme nous le faisons pour les adresses e-mail, mais il n’y a aucune normalisation en minuscules pour les IDFA/identifiants Android et le format exact de l’IDFA/de l’identifiant Android doit être utilisé.
Voici un exemple de format brut des identifiants d’appareil pour iOS et Android, avant hachage :
IDFA iOS : DD99CFF7-6186-4602-9DF2-ED3FD0B2D431
ID Android : b5bf2122961b3595
IDFA iOS haché : 134fb8cd95c7fd42e2793f469a447198ca5f990968db2dbadad70e723ed9750b
ID Android haché : 130dddff1939f229476f50bc8adab8fcb7e3525b0e9604fe8effc15e68cee4a4
Les ID X continueront d’être hachés, car le regroupement des données – par exemple une Liste de clients composée de @handles – reste privé pour l’annonceur, même s’il ne s’agit pas de données personnelles (PII). Nous appliquerons les mêmes exigences de hachage des ID X à l’aide de l’algorithme de hachage SHA-256 et d’un sel (« salt ») commun que nous fournissons aux partenaires de données. Les espaces doivent être supprimés à la fois de l’ID X et du @username, mais les User IDs ne nécessitent pas de normalisation. Les @usernames doivent être convertis en minuscules pour la normalisation. Le symbole @ ne doit pas être inclus dans le username.
Le format brut de l’ID sera :
- User ID : 27674040
- @username : testusername
p_id doivent passer par un processus de synchronisation d’ID afin de générer une correspondance entre les identifiants utilisateur de l’annonceur ou du partenaire et les identifiants utilisateur X. Cela permet aux annonceurs de cibler directement leurs propres segments d’utilisateurs sur X. Les partenaires doivent également attribuer au paramètre user_identifier_type la valeur TALIST_PARTNER_USER_ID ou TAWEB_PARTNER_USER_ID lorsqu’ils envoient leurs mises à jour d’appartenance.
- Web uniquement : cela peut se faire en plaçant un pixel sur le site de l’annonceur, comme indiqué ci‑dessous.
- Liste : cela peut se faire en utilisant l’une des méthodes décrites sur la page CRM.
En utilisant un exemple d’id partenaire égal à 111 et un exemple de
p_user_id égal à abc, le pixel généré serait le suivant :
Envoi des mises à jour d’appartenance
Comme indiqué dans la documentation de notre endpoint, lorsque vous transmettez des utilisateurs via l’endpoint POST custom_audience_memberships, vous devez transmettre un customer ID (ID client) pour activer la correspondance basée sur les cookies. Les partenaires qui envoient des données avec un
p_id doivent définir user_identifier_type sur TALIST_PARTNER_USER_ID ou TAWEB_PARTNER_USER_ID.
Toutes les autres étapes resteront identiques à celles répertoriées dans le Guide d’intégration de l’API Real-Time Audience.
Ce document décrit le format des données utilisateur des [Custom Audience]/x-ads-api/audiences.
Normalisation des données
Identifiants d’appareil :
- IDFA - en minuscules avec des tirets ; ex. :
4b61639e-47cc-4056-a16a-c8217e029462 - AdID - le format d’origine sur l’appareil est requis, non mis en majuscules, avec des tirets ; ex. :
2f5f5391-3e45-4d02-b645-4575a08f86e - Android id - le format d’origine sur l’appareil est requis, non mis en majuscules, sans tirets ni espaces ; ex. :
af3802a465767e36
- en minuscules, supprimer les espaces de début et de fin ; ex. :
support@x.com
- sans @, en minuscules, et suppression des espaces de début et de fin ; ex. :
jack
- Entier standard ; ex. :
143567
SHA256, sans sel. De plus, le hachage final produit doit être en minuscules. Par exemple : 49e0be2aeccfb51a8dee4c945c8a70a9ac500cf6f5cb08112575f74db9b1470d et non 49E0BE2AECCFB51A8DEE4C945C8A70A9AC500CF6F5CB08112575F74DB9B1470D

p_user_ids) à cibler pour le compte d’un annonceur. Cela se fait via un processus de synchronisation d’ID (ID Sync) qui établit une correspondance entre les p_user_ids et l’ID utilisateur X. Cette correspondance est ensuite utilisée pour produire des listes d’ID utilisateur X pouvant être utilisées pour le ciblage. Ces audiences personnalisées seront mises à disposition sur le @handle spécifique de l’annonceur, indiqué par le libellé lors de la configuration de campagne Custom Audiences Web sur ads.x.com.
X fournira le pixel sécurisé qui pourra être intégré dans les balises et sur les sites des partenaires afin de faire correspondre les ID (p_user_ids) aux ID utilisateur X. Une fois le processus de synchronisation d’ID terminé, les fichiers de ciblage seront créés par le partenaire et mis à disposition de X via un endpoint HTTPS. Ces fichiers de ciblage sont régulièrement ingérés par X, puis rendus disponibles dans l’interface X.
Pixel sécurisé X
Le pixel sécurisé X se présentera comme suit :
https://analytics.x.com/i/adsct?p_user_id=xyz&p_id=123
p_user_id - xyz représente l’ID utilisateur du partenaire
p_id - 123 représente l’ID unique du partenaire (fourni par X)
Endpoint HTTPS du partenaire & fichier d’utilisateurs pour le ciblage
Le partenaire devra fournir à X un endpoint HTTPS et des identifiants (nom d’utilisateur/mot de passe) pouvant être utilisés pour ingérer régulièrement le fichier de ciblage. Un exemple d’endpoint HTTPS se présentera comme suit :
- Partner Targeting User File
- Targeting Conversion File
- 199.16.156.0/22
- 199.59.148.0/22
Remarques :
Chaque fois que nous recevons un nouveau Partner Targeting File, nous nous attendons à ce qu’il s’agisse de la liste complète des utilisateurs que le partenaire nous recommande de cibler, et non d’une liste incrémentale, sauf accord contraire. Nous conviendrons avec chaque partenaire de la fréquence de livraison de ce Partner Targeting File. Si nous ne recevons pas de Partner Targeting File comme prévu, nous utiliserons la version précédente avec un délai d’expiration prédéfini.
L’Audience API a été lancée dans le cadre de la v4 de l’Ads API et apporte plusieurs améliororations par rapport aux anciens endpoints Audiences. Ce nouveau endpoint s’appuie sur un nouveau backend de traitement des Audiences et fournit plusieurs améliorations en termes de stabilité, de robustesse et de fiabilité. L’objectif de ce guide est de mettre en évidence les différences entre l’Audience API et les anciens processus de téléversement et de gestion d’Audience.
La documentation de référence est disponible sur la page de référence de l’Audience API.
Remarque : toutes les données utilisateur d’Audience doivent être hachées en SHA-256 avant le téléversement. Davantage de détails, ainsi que les types d’identifiants utilisateur acceptés et la normalisation des données, sont disponibles sur la page user data.
Modifications de la fonctionnalité Audience
Les changements suivants apportés aux Audiences personnalisées ont été introduits à partir de la v4 et tous les endpoints obsolètes ne seront plus disponibles une fois que la v3 de l’Ads API aura été retirée :
- Obsolète : téléversement TON :
- GET accounts/:account_id/custom_audience_changes
- GET accounts/:account_id/custom_audience_changes/:custom_audience_change_id
- POST accounts/:account_id/custom_audience_changes
- PUT accounts/:account_id/custom_audiences/global_opt_out
- Obsolète : Real Time Audiences :
- POST custom_audience_memberships
- Audience personnalisée :
- Le paramètre
list_typesera supprimé de la requête et de la réponse sur tous les endpoints Custom Audience. Ce paramètre était auparavant utilisé pour identifier le type d’identifiant utilisateur de l’Audience (c.-à-d. email, X User ID, etc.). Cependant, les Audiences peuvent désormais accepter plusieurs identifiants utilisateur pour une même Audience, ce qui rend cette valeur non pertinente.
- Le paramètre
- Général :
- La période de rétrospection (lookback window) de l’Audience a été mise à jour pour faire correspondre les utilisateurs actifs au cours des 90 derniers jours (au lieu de 30 jours).
- Le nombre minimum d’utilisateurs correspondants requis pour qu’une Audience soit ciblable a été réduit à 100 utilisateurs (au lieu de 500 utilisateurs).
Prérequis
- Accès à l’Ads API
- Pour accéder au endpoint Audience, vous devrez être ajouté à une allowlist. Veuillez remplir ce formulaire et accepter le nouvel X Ads Products and Services Agreement si vous aviez initialement accepté une version antérieure au 1er août 2018.
Remarque : toutes les Audiences mises à jour ou pour lesquelles un opt-out est effectué via le flux de téléversement TON doivent disposer d’une liste correspondante téléversée via le endpoint TON Upload et associée à une Audience à l’aide du endpoint custom_audience_changes.
Limitation de débit
Le endpoint Audience API a une limite de débit de 1500/1 min par compte. Il n’y a aucune limite quant au nombre d’utilisateurs pouvant être envoyés dans une seule charge utile (payload). Les seules contraintes sur la charge utile sont :
- Nombre total d’opérations : 2500 opérations
- Taille maximale de la charge utile : 5 000 000 octets
id de l’Audience personnalisée correspondante. Cette étape est requise si vous créez une Audience à partir de zéro. Si vous mettez à jour une Audience existante, passez à la section suivante.
Utilisez l’endpoint POST accounts/:account_id/custom_audiences/:custom_audience_id/users avec l’id de la Custom Audience et un exemple de payload comme suit :
POST https://ads-api.x.com/11/accounts/18ce54d4x5t/custom_audiences/1nmth/users
Update pour le champ operation_type. La nouvelle interface Audience permet d’envoyer plusieurs clés d’utilisateur pour un même utilisateur. Chaque objet dans le tableau d’objets JSON correspond à un seul utilisateur. En utilisant l’exemple de payload ci‑dessus, la requête ajoutera deux utilisateurs à une Audience, l’un avec un email et un handle, et l’autre avec un email et un twitter_id.
De manière similaire au processus décrit pour l’ajout d’utilisateurs, des utilisateurs peuvent être supprimés d’une audience de la manière suivante :
POST https://ads-api.x.com/11/accounts/18ce54d4x5t/custom_audiences/1nmth/users
operation_type doit être défini sur la valeur Delete et les utilisateurs seront mis en correspondance sur n’importe laquelle des clés qui étaient présentes lors de leur ajout à l’audience. Par exemple, si un utilisateur a été ajouté à une audience à l’aide d’un email et d’un twitter_id, alors ce même utilisateur peut être supprimé en utilisant l’une quelconque de ces clés, c’est‑à‑dire email ou twitter_id, ou les deux.
Il est également possible d’ajouter et de supprimer des utilisateurs d’une audience dans la même requête. Le point de terminaison prend en charge plusieurs valeurs de operation_type par requête.
Avec l’abandon de l’endpoint global d’opt-out, les partenaires doivent Delete tous les utilisateurs qui ont choisi l’opt-out d’une Audience. Il existe plusieurs façons d’y parvenir :
- Suivre quels utilisateurs font partie de quelles Audiences et retirer ces utilisateurs individuellement de chaque Audience.
- Retirer l’utilisateur de toutes les Audiences associées à un compte Ads.
- Nous recommandons fortement d’appeler cet endpoint avec des lots traités en quasi temps réel afin d’éviter des pics dans les files d’attente, qui prennent plus de temps à être traités et génèrent en général une charge inutile sur notre système. Cela garantit également que les utilisateurs sont disponibles plus rapidement pour le ciblage des campagnes.
- Un appel d’API réussi renverra un
success_countet untotal_countcorrespondant au nombre d’objetsuserreçus dans la requête. - Cet endpoint est atomique par nature, c’est-à-dire que soit l’intégralité de la requête réussit, soit, en cas de
errors, l’intégralité de la requête échoue. En cas de réponse d’erreur, il est recommandé aux consommateurs de l’API de corriger l’erreur et de réessayer la requête avec l’intégralité du payload. - En cas d’échec, il est recommandé aux partenaires d’utiliser une approche de backoff exponentiel avec des tentatives de nouvelle exécution. Par exemple, réessayez immédiatement après le premier échec, réessayez après 1 minute après le deuxième échec et réessayez après 5 minutes après le troisième échec consécutif, et ainsi de suite.
end_time - start_time) de 7 jours est autorisée.
Veuillez noter que les résultats sont limités à une seule zone géographique (pays).
Resource URL
https://ads-api.x.com/12/insights/keywords/search
Parameters
Example Request
https://ads-api.x.com/5/accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions
Paramètres
Exemple de requête
GET https://ads-api.x.com/5/accounts/18ce54d4x5t/tailored_audiences/1nmth/permissions
Exemple de réponse
is_owner dans la réponse renvoyée pour une audience donnée.
Remarque : les audiences ne peuvent être partagées qu’entre des comptes publicitaires appartenant à la même entreprise ou si le compte publicitaire qui possède l’audience dispose de la fonctionnalité de compte SHARE_AUDIENCE_OUTSIDE_BUSINESS.
URL de la ressource
https://ads-api.x.com/5/accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions
Paramètres
Exemple de requête
POST https://ads-api.x.com/5/accounts/18ce54d4x5t/tailored_audiences/2906h/permissions?granted_account_id=18ce54aymz3&permission_level=READ_ONLY
Exemple de réponse
DELETE accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions/:tailored_audience_permission_id
is_owner dans la réponse pour une audience donnée.
Une fois révoquée, nous garantissons que le compte bénéficiaire (granted_account_id) ne pourra plus cibler l’audience dans de futures campagnes. Les campagnes existantes continueront de s’exécuter avec les audiences partagées ; les campagnes ne s’arrêtent pas et l’audience n’est pas supprimée de la campagne. Il n’est pas possible de dupliquer cette campagne après la révocation de l’autorisation de partage d’audience.
URL de la ressource
https://ads-api.x.com/5/accounts/:account_id/tailored_audiences/:tailored_audience_id/permissions/:tailored_audience_permission_id
Paramètres
Exemple de requête
DELETE https://ads-api.x.com/5/accounts/18ce54d4x5t/tailored_audiences/1nmth/permissions/ri
Exemple de réponse
custom_audience_id donné.
Exemple de requête
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h/targeted
Exemple de réponse
custom_audience_id donné. L’endpoint accepte également plusieurs types d’identifiants utilisateur pour un même utilisateur.
Toutes les données fournies dans le champ users de la requête, sauf partner_user_id, doivent être hachées à l’aide de SHA256 et normalisées.
Requêtes en lot
- La taille maximale actuelle d’un lot est de
2500pour cet endpoint. La taille du lot est déterminée par le nombre d’opérations (Update/Delete) par requête. Par exemple, plus de 2500 objets d’opération ({"operation_type": "Update/Delete", [..] }) dans un même tableau entraînent une erreur. - La taille maximale du corps POST de la requête que cet endpoint peut accepter est de
5,000,000octets. - Les limites de taux pour cet endpoint sont de 1500 par fenêtre de 1 minute.
- Tous les paramètres sont envoyés dans le corps de la requête et un
Content-Typedeapplication/jsonest requis. - Les requêtes en lot échouent ou réussissent toutes ensemble en tant que groupe et toutes les réponses de l’API, qu’il s’agisse d’erreurs ou de succès, préservent l’ordre des éléments de la requête initiale.
success_count et un total_count. Ces valeurs doivent toujours être égales, et elles correspondent au nombre d’enregistrements dans la requête qui ont été traités par le backend. Une situation où le nombre d’enregistrements envoyés dans le corps de la requête n’est pas égal à success_count et total_count doit être traitée comme une erreur nécessitant une nouvelle tentative.
Erreurs en lot
- Les erreurs au niveau de la requête (par ex. taille maximale du lot dépassée) sont indiquées dans la réponse sous l’objet
errors. - Les erreurs au niveau des éléments (par ex. paramètres obligatoires manquants) sont indiquées dans la réponse sous l’objet
operation_errors. - L’index de l’erreur dans
operation_errorscorrespond à l’index de l’élément d’entrée, avec le message d’erreur correspondant.
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/users
Compte tenu de l’approche multi-clés pour l’objet
users, chaque élément de cet objet est documenté ci‑dessous :
POST https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/1nmth/users
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/permissions
Paramètres
Exemple de requête
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/1nmth/permissions
Exemple de réponse
is_owner dans la réponse pour une audience donnée.
Remarque : les audiences ne peuvent être partagées qu’entre des comptes publicitaires appartenant à la même entreprise ou si le compte publicitaire qui détient l’audience dispose de la fonctionnalité de compte SHARE_AUDIENCE_OUTSIDE_BUSINESS.
Resource URL
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/permissions
Parameters
Example Request
DELETE accounts/:account_id/custom_audiences/:custom_audience_id/permissions/:custom_audience_permission_id
is_owner dans la réponse pour une audience donnée.
Une fois révoquée, nous garantissons que le compte à qui l’accès a été accordé (granted_account_id) ne pourra plus cibler l’audience dans de futures campagnes. Les campagnes existantes continueront à s’exécuter avec les audiences partagées ; les campagnes ne s’arrêtent pas et l’audience n’est pas supprimée de la campagne. Il n’est pas possible de copier cette campagne après la révocation de l’autorisation de partage d’audience.
URL de la ressource
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id/permissions/:custom_audience_permission_id
Paramètres
Exemple de requête
DELETE https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/1nmth/permissions/ri
Exemple de réponse
https://ads-api.x.com/12/accounts/:account_id/custom_audiences
Parameters
Example Request
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences?custom_audience_ids=1nmth
Example Response
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id
Paramètres
Exemple de requête
GET https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h
Exemple de réponse
https://ads-api.x.com/12/accounts/:account_id/custom_audiences
Paramètres
Exemple de requête
POST https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences?name=developers
Exemple de réponse
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id
Parameters
Example Request
PUT https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h?name=developers_changed
Example Response
- La taille maximale actuelle d’un lot est de 10.
- Tous les paramètres sont envoyés dans le corps de la requête et un
Content-Typedeapplication/jsonest requis. - Les requêtes par lot échouent ou réussissent ensemble en tant que groupe et toutes les réponses de l’API, en cas d’erreur comme de succès, préservent l’ordre des éléments de la requête initiale.
- Les erreurs au niveau de la requête (par ex. taille maximale de lot dépassée) apparaissent dans la réponse sous l’objet
errors. - Les erreurs au niveau des éléments (par ex. paramètre obligatoire manquant) apparaissent dans la réponse sous l’objet
operation_errors.
- Les Flexible Audiences sont immuables une fois créées.
- Les Custom Audiences sont transmises sous forme d’arborescence avec des combinaisons de logique booléenne pour créer des Flexible Audiences.
- Un maximum de 10 nœuds feuille de Custom Audiences peut être utilisé pour créer une Flexible Audience.
https://ads-api.x.com/12/batch/accounts/:account_id/custom_audiences
Paramètres
Example Request
POST https://ads-api.x.com/12/batch/accounts/18ce54d4x5t/custom_audiences
https://ads-api.x.com/12/accounts/:account_id/custom_audiences/:custom_audience_id
Paramètres
Exemple de requête
DELETE https://ads-api.x.com/12/accounts/18ce54d4x5t/custom_audiences/2906h
Exemple de réponse
account_id ne peut avoir qu’au maximum une liste Do Not Reach
URL de la ressource
https://ads-api.x.com/12/accounts/:account_id/do_not_reach_lists
Paramètres
Exemple de requête
GET https://ads-api.x.com/12/accounts/18ce54bgxky/do_not_reach_lists
Exemple de réponse
account_id ne peut avoir au maximum qu’une seule Liste Ne Pas Contacter
URL de ressource
https://ads-api.x.com/12/accounts/:account_id/do_not_reach_lists
Paramètres
Exemple de requête
POST https://ads-api.x.com/12/accounts/18ce54bgxky/do_not_reach_lists?description=A list of users to exclude
Exemple de réponse
do_not_reach_list_id donné. Cet endpoint n’accepte que les e-mails comme type d’identifiant utilisateur valide.
Toutes les données fournies dans le champ emails de la requête doivent être hachées en utilisant SHA256 et normalisées.
Remarques
- Un
account_idne peut être associé au maximum qu’à une seule Do Not Reach List - Les utilisateurs ajoutés à cette liste doivent avoir un horodatage
expires_atdéfini à moins de 13 mois à compter de l’horodatage actuel - L’API Do Not Reach List n’accepte pas d’horodatage
effective_atet utilise par défaut l’horodatage actuel - La Do Not Reach List ne supprime pas les utilisateurs d’une ou de toutes les audiences personnalisées du compte, mais agit comme un ciblage d’exclusion pour toutes les campagnes diffusées pour le compte
- La taille maximale actuelle d’un lot est de
2500pour cet endpoint. La taille du lot est déterminée par le nombre d’opérations (Update/Delete) par requête. Par exemple, plus de 2500 objets d’opération ({"operation_type": "Update/Delete", [..] }) dans un seul tableau entraînent une erreur. - La taille maximale du corps de requête POST que cet endpoint peut accepter est de
5,000,000octets. - Les limites de taux pour cet endpoint sont de 1500 par fenêtre de 1 minute.
- Tous les paramètres sont envoyés dans le corps de la requête et un
Content-Typedeapplication/jsonest requis. - Les requêtes par lots échouent ou réussissent ensemble en tant que groupe et toutes les réponses de l’API, pour les erreurs comme pour les succès, préservent l’ordre des éléments de la requête initiale.
success_count et un total_count. Ces valeurs doivent toujours être égales, et elles correspondent au nombre d’enregistrements dans la requête qui ont été traités par le backend. Une situation où le nombre d’enregistrements envoyés dans le corps de la requête n’est pas égal à success_count et total_count doit être traitée comme une condition d’erreur nécessitant une nouvelle tentative.
Erreurs par lots
- Les erreurs au niveau de la requête (par ex. taille de lot maximale dépassée) sont indiquées dans la réponse dans l’objet
errors. - Les erreurs au niveau des éléments (par ex. paramètres obligatoires manquants) sont indiquées dans la réponse dans l’objet
operation_errors. - L’index de l’erreur dans
operation_errorsfait référence à l’index de l’élément en entrée, avec le message d’erreur correspondant
https://ads-api.x.com/12/batch/accounts/:account_id/do_not_reach_lists/:do_not_reach_list_id/users
Paramètres
Compte tenu de l’approche multi-clés pour l’objet
users, chaque élément de cet objet est documenté ci-dessous :
Exemple de requête
https://ads-api.x.com/12/accounts/:account_id/do_not_reach_lists/:do_not_reach_list_id
Paramètres
Aucun
Exemple de requête
DELETE https://ads-api.x.com/12/accounts/18ce54bgxky/do_not_reach_lists/4ofrp
Exemple de réponse