Links rápidos
- Referência completa da API — Todos os endpoints e objetos de Audience
- Guias — CRM, Web, Mobile, ID Sync, uploads de User Data, FAQ
Custom Audiences
Visão geral
Existem várias formas de os parceiros criarem Custom Audiences. Observe que você não pode excluir custom audiences lookalike da segmentação. Além disso, não é possível segmentar uma custom audience e um lookalike da mesma custom audience no mesmo line item (ad group). Gerenciamento de audiências Audiências podem ser gerenciadas por parceiros de audiência e parceiros da Ads API. Oferecemos uma série de endpoints na API para acessar e manter custom audiences. Para informações sobre custom audiences, oferecemos 2 endpoints:- GET accounts/:account_id/custom_audiences
- GET accounts/:account_id/custom_audiences/:custom_audience_id




FAQ de audiências
P: Enviamos uma grande quantidade de dados, por que o tamanho da audiência aparece como TOO_SMALL? R: No momento, os dados são adicionados à audiência em tempo real, mas o job que processa os dados para fornecer o tamanho da audiência só rodará após um período. O tamanho correto da audiência deve ser exibido na UI depois de algumas horas. P: Terminamos de enviar os dados da audiência e esperamos 24 horas ou mais, mas ainda não conseguimos segmentar a audiência - o que devemos fazer? R: Por favor, confirme o seguinte:- O user ID que está sendo passado está correto e não malformado.
- Os nomes das audiências passados estão corretos e correspondem a atualizações anteriores de membros.
- Confirme a resposta dos comandos POST.
- Confirme se o pixel de ID Sync está implementado corretamente e, conforme descrito no processo de ID Sync, que usuários suficientes visitaram o site em questão para mapeá-los. Usuários não mapeados nas atualizações de membros não serão convertidos em usuários segmentáveis.
- O tamanho mínimo para uma audiência é de 100 usuários (após correspondência). Se uma audiência com menos de 500 usuários for correspondida, ela não estará disponível para segmentação na UI do X Ads.
- Normalmente leva de 4 a 6 horas para processar os arquivos, mas depende do tamanho do arquivo. Depois de processado, as audiências ficam disponíveis na UI do X Ads.
- Taxa de correspondência = usuários ativos do X nos últimos 90 dias / número de usuários fornecidos
- Você pode fornecer um arquivo de teste e usar “keltonlynn” como o handle do anunciante. Podemos então verificar se o arquivo é adequadamente ingerido e carregado na UI do X.
p_user_id)?
- É o identificador utilizado por sua empresa para identificar de forma única cada um dos seus clientes.
- Pode ser um endereço de e-mail, device ID, @handle do X ou ID.
- Ela será fornecida por e-mail criptografado. Forneça sua chave pública PGP para mpp-inquiry@x.com e enviaremos um e-mail de teste para verificar se tudo está funcionando. Uma vez verificado, enviaremos a chave HMAC.
- O X fornecerá um arquivo de teste (contendo endereços de e-mail de amostra, device IDs, etc.) e um arquivo de hash resultante contra o qual você pode verificar seus resultados.
- Não, não há limite de tamanho para o arquivo de full data match.
- Uma vez que o arquivo é recebido pelo X, levará aproximadamente 1 dia para processar o arquivo.
CRM

Requisitos de correspondência de Partner ID
Se a empresa usa seu próprio sistema padrão de IDs para rastrear usuários (ou seja, não identificadores comuns como endereços de e-mail, device ids, X user ID, etc.), este é o processo recomendado. 1. Full Data match Inicialmente, a empresa fornecerá uma lista abrangente de todos os registros de usuários que incluem um identificador comum único ao X em um único arquivo para realizar uma correspondência completa e produzir um mapeamento armazenado pelo X de Partner IDs (p_user_id) para X IDs (tw_id). Isso será feito regularmente a cada 2-3 meses para garantir manutenção adequada. Uma vez concluída a correspondência, o X compartilhará uma taxa de correspondência inicial deste arquivo com a empresa por e-mail.
O formato deste arquivo deve ser:
Convenção de nome: FullDataMatch.[CompanyName].txt
Algoritmo de hashing: HMAC_SHA-256
Formato:
Coluna 1: Valor HMAC com hash dos identificadores comuns
Coluna 2: Partner User ID (único por usuário, não único no arquivo)
Delimitador de coluna (CSV): Vírgulas serão usadas para delimitar o identificador comum do Partner ID
Valores separados por linha
- Ex: Se o registro de usuário A tem Partner User ID 1 e identificadores comuns 1, 2 e 3:
*Consulte a seção de Diretrizes de Hashing para identificadores comuns abaixo.
2. Custom Segment Lists
A empresa fornecerá listas de usuários na forma de
p_user_id para criar custom audiences para segmentação no X.
- Valores separados por linha
p_user_id- (O mesmo fornecido em 1. Full Data Match acima. Se o valor fornecido no full data match for hash, a empresa fornecerá o mesmo valor com hash no arquivo de audiência. Se o valor fornecido não for hash, a empresa fornecerá o valor não hasheado.)
Requisitos de correspondência padrão
Se a empresa não usa um ID padrão para mapear identificadores de usuário, este é o processo recomendado. Custom Segment Lists A empresa fornecerá listas de identificadores comuns de usuário com hash diretamente ao X em nome dos clientes para criar custom audiences. O formato deste arquivo deve ser:- Valores separados por linha
- Identificador comum de usuário com hash (ou seja, endereço de e-mail)
- Seguir as convenções de nomeação de arquivos descritas abaixo
- Seguir as diretrizes de hashing para endereços de e-mail abaixo (em Diretrizes de Hashing)
Nomeação e operações da Custom Segment List
A operação de um arquivo será determinada pelo nome do arquivo com as seguintes operações disponíveis e convenção geral de nomeação: audiencename_partnername.handle.operation.filetype- audiencename: O nome da Custom Audience. Este campo é o nome que será exibido ao selecionar a audiência na UI de configuração de campanhas em ads.x.com, por exemplo, brand_loyalty_card_holders.
- partnername: Nome da empresa que fornece os dados em nome do anunciante, por exemplo, company_name.
- handle: Conta do X (@handle) que terá acesso às Custom Audiences, por exemplo, @pepsi, @dietpepsi
- operation: new, add, remove, removeall, replace (detalhes abaixo)
- : Tempo epoch Unix padrão em segundos, usado para garantir que cada arquivo de audiência enviado seja único
- filetype: o arquivo deve estar no formato *.txt
Criando e atualizando audiências
Criar uma nova audiência com um único arquivo, por exemplo, loyalty_card_holders_partnername.pepsi.new.txt Add - Adicionar as correspondências de uma lista a uma audiência existente, por exemplo, loyalty_card_holders_partnername.pepsi.add.txt Remove - Remover as correspondências de uma lista de uma audiência existente, ex.: loyalty_card_holders_partnername.pepsi.remove.txt Remove All - Remover as correspondências produzidas de uma lista cumulativa atualizada regularmente de todas as audiências desse cliente (ou seja, a lista de Opt Out do cliente). Ex.: partnername.pepsi.removeall.txt- Isso pode ser usado para uma lista abrangente de usuários que optaram por sair do Anunciante.
- O X respeitará apenas a última lista fornecida neste arquivo, e a respeitará em todas as audiências existentes e futuras para X users correspondidos no momento em que este arquivo foi fornecido e processado.
Diretrizes de Hashing
O X compartilhará com segurança uma chave de produção codificada em base64 via PGP para gerar o hash dos identificadores comuns de usuário (ou seja, endereços de e-mail). A empresa fará a decodificação base64 da chave para produzir uma chave de 32 bytes a ser usada para realizar o hashing. Exemplo de chave codificada em base64: BrQvOg+dACBUmKjRiNxZgJLh6zydjS0ZOv80FelTNzM= Exemplo de chave decodificada de Base64: /:� TшY Normalização: A empresa fará uma normalização básica nos identificadores comuns antes do hashing (exceto em Device IDs, veja a seção Normalização de Device ID).Normalização de e-mail
Ou seja, remover espaços à esquerda e à direita e transformar o endereço de e-mail em minúsculas. Ex.: E-mail bruto: testemail_Organisational_baseball+884@It92I6Ev2B.Com
Após normalização: testemail_organisational_baseball+884@it92i6ev2b.com
Valor com hash: 74d9584eded0ad1e5572a1c1849f3716751d371d6117a6155dad5363f4b4fbec
Observação: O número específico de caracteres tanto do hmac codificado quanto da chave pode variar de acordo com a entrada e a codificação.
Normalização de Device ID
Teremos os mesmos requisitos para o hashing de device IDs usando um algoritmo SHA-256 e um salt comum que fornecemos aos parceiros de dados. Removemos espaços como fazemos com endereços de e-mail, mas não há normalização para minúsculas em IDFAs/Android IDs e o formato exato do IDFA/Android ID deve ser usado. Aqui está um exemplo do formato bruto de Device IDs para iOS e Android, pré-hashing: iOS IDFA: DD99CFF7-6186-4602-9DF2-ED3FD0B2D431 Android ID: b5bf2122961b3595 Hashed iOS IDFA: 134fb8cd95c7fd42e2793f469a447198ca5f990968db2dbadad70e723ed9750b Hashed Android ID: 130dddff1939f229476f50bc8adab8fcb7e3525b0e9604fe8effc15e68cee4a4Normalização de X User ID
Os X IDs ainda serão hash porque o agrupamento de dados - ou seja, lista de @handles dos clientes - é privado ao anunciante, mesmo que não seja PII. Teremos os mesmos requisitos para hashing de X IDs usando o algoritmo SHA-256 e um salt comum que fornecemos aos parceiros de dados. Espaços devem ser removidos tanto do X ID quanto do@username, mas User IDs não requerem normalização. @usernames devem ser transformados em minúsculas para normalização. E o símbolo @ não deve ser incluído como parte do username.
O formato bruto do ID será:
- User ID: 27674040
- @username: testusername
Integração de ID Sync
Parceiros que enviam dados com ump_id devem passar por um processo de ID Sync para gerar um mapeamento dos user ids do anunciante ou parceiro para os X user ids. Isso permite que os anunciantes segmentem diretamente seus próprios segmentos de usuários no X. Os parceiros também devem definir o valor do parâmetro user_identifier_type como TALIST_PARTNER_USER_ID ou TAWEB_PARTNER_USER_ID ao enviar suas atualizações de membros.
- Apenas Web: Pode ser feito colocando um pixel no site do anunciante, conforme descrito abaixo.
- Lista: Pode ser feito usando qualquer um dos métodos descritos na página CRM.
URL do Pixel
Parâmetros do Pixel
Pixel de ID Sync:
Usando um exemplo de partner id 111 e um exemplo dep_user_id abc, o pixel construído seria:
Envio de atualizações de membros
Conforme especificado em nossa documentação de endpoints, ao passar usuários pelo endpoint POST custom_audience_memberships, você deve passar um customer ID para permitir uma correspondência baseada em cookie. Parceiros que enviam dados com um
p_id devem definir o user_identifier_type como TALIST_PARTNER_USER_ID ou TAWEB_PARTNER_USER_ID.
Todas as outras etapas permanecem iguais às listadas no Guia de Integração da Real-Time Audience API
Custom Audiences User Data
Este documento descreve o formato dos dados de usuário para Custom Audience. Normalização de dados Device IDs:- IDFA - em minúsculas com traços; ex:
4b61639e-47cc-4056-a16a-c8217e029462 - AdID - formato original do dispositivo é obrigatório, sem maiúsculas com traços; ex:
2f5f5391-3e45-4d02-b645-4575a08f86e - Android id - formato original do dispositivo é obrigatório, sem maiúsculas sem traços ou espaços; ex:
af3802a465767e36
- minúsculas, remover espaços à esquerda e à direita; ex:
support@x.com
- sem @, em minúsculas e com espaços à esquerda e direita removidos; ex:
jack
- Inteiro padrão; ex:
143567
SHA256, sem salt. Além disso, o hash de saída final deve estar em minúsculas. Ex: 49e0be2aeccfb51a8dee4c945c8a70a9ac500cf6f5cb08112575f74db9b1470d e não 49E0BE2AECCFB51A8DEE4C945C8A70A9AC500CF6F5CB08112575F74DB9B1470D
Custom Audiences: Web

p_user_ids) para segmentar em nome de um anunciante. Isto é feito através de um processo de ID Sync que constrói um mapeamento entre os p_user_ids e o X user ID. Este mapeamento é então usado para produzir listas de X User IDs que podem ser usados para segmentação. Essas custom audiences serão disponibilizadas para o @handle específico do anunciante especificado pelo rótulo na configuração de campanha Custom Audiences Web em ads.x.com.
O X fornecerá o pixel seguro que pode ser colocado em tags e sites de parceiros para fazer a correspondência dos IDs (p_user_ids) com os X user IDs. Uma vez concluído o processo de ID Sync, os arquivos de segmentação serão criados pelo parceiro e serão disponibilizados ao X por meio de um endpoint HTTPS. Esses arquivos são ingeridos regularmente pelo X e depois disponibilizados na UI do X.
Pixel seguro do X
O pixel seguro do X terá a seguinte aparência:
https://analytics.x.com/i/adsct?p\_user\_id=xyz&p_id=123
p_user_id - xyz representa o partner user ID fornecido pelo Parceiro
p_id - 123 representa o ID único do Parceiro (fornecido pelo X)
Endpoint HTTPS do Parceiro e arquivo de usuários para segmentação
O parceiro precisará fornecer ao X um endpoint HTTPS e credenciais (usuário/senha) que podem ser usados para ingerir o arquivo de segmentação regularmente. Um exemplo de endpoint HTTPS será:
- Partner Targeting User File
- Targeting Conversion File
- 199.16.156.0/22
- 199.59.148.0/22
Observações:
Toda vez que recebemos um novo Partner Targeting File, esperamos que esta seja a lista completa de usuários que o Parceiro recomenda que segmentemos, não incremental, a menos que seja acordado o contrário. Combinaremos com cada parceiro a frequência de entrega deste Partner Targeting File. Se não recebermos um Partner Targeting File conforme esperado, usaremos a versão anterior com algum tempo pré-definido de expiração.
Integração da Audience API
Visão geral
A Audience API foi lançada como parte da v4 da Ads API e traz várias melhorias em relação aos endpoints legados de audiências. Este novo endpoint é sustentado por um novo backend de processamento de audiências e traz várias melhorias em termos de estabilidade, robustez e confiabilidade. O objetivo deste guia é destacar as diferenças entre a Audience API e os processos legados de upload e gerenciamento de audiências. A documentação de referência pode ser encontrada na página de referência da Audience API. Nota: Todos os dados de usuário de Audience devem ser hashed com SHA-256 antes do upload. Mais detalhes, junto com os tipos de identificadores de usuário aceitos e a normalização de dados, podem ser encontrados na página de user data. Alterações na funcionalidade de Audience As seguintes alterações em Custom Audiences foram introduzidas a partir da v4 e quaisquer endpoints depreciados não estarão mais disponíveis quando a v3 da Ads API for descontinuada:- Depreciado TON Upload:
- 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
- Depreciado Real Time Audiences:
- POST custom_audience_memberships
- Custom Audience:
- O parâmetro
list_typeserá removido da requisição e resposta em todos os endpoints de Custom Audience. Este parâmetro era usado anteriormente para identificar o tipo de identificador de usuário da Audience (ou seja, e-mail, X User ID, etc.), no entanto, as Audiences agora têm a capacidade de aceitar múltiplos identificadores de usuário para a mesma Audience, tornando esse valor irrelevante.
- O parâmetro
- Geral:
- A janela de lookback da Audience foi atualizada para corresponder a usuários ativos nos últimos 90 dias (de 30 dias)
- O número mínimo de usuários correspondidos necessários para que uma audiência seja segmentável foi reduzido para 100 usuários (de 500 usuários)
Pré-requisitos
- Acesso à Ads API
- Para acesso ao endpoint Audience, você precisará ser adicionado a uma allowlist. Preencha este formulário e aceite o novo X Ads Products and Services Agreement se aceitou inicialmente antes de 2018-08-01
Nota Quaisquer audiências sendo atualizadas ou opted-out via o caminho TON Upload devem ter uma lista correspondente enviada pelo endpoint TON Upload e associada a uma Audience usando o endpoint custom_audience_changes.
Rate Limiting
O endpoint da Audience API tem um rate limit de 1500/1min por conta. Não há limites no número de usuários que podem ser enviados em um único payload. As únicas restrições no payload são:
- Número total de operações: 2500 operações
- Tamanho máximo do payload: 5.000.000 bytes
Criar uma nova Custom Audience
Crie uma nova “shell” de Custom Audience usando o endpoint POST custom_audience e recupere oid correspondente da Custom Audience. Esta etapa é necessária se você estiver criando uma Audience do zero. Se estiver atualizando uma Audience existente, pule para a próxima seção
Adicionar usuários a uma Audience
Use o endpoint POST accounts/:account_id/custom_audiences/:custom_audience_id/users com oid da Custom Audience e um payload de exemplo assim:
POST https://ads-api.x.com/11/accounts/18ce54d4x5t/custom_audiences/1nmth/users
operation_type Update. A nova interface de Audience permite passar múltiplas chaves de usuário para um único usuário. Cada objeto no array de objetos JSON corresponde a um único usuário. Usando o payload de exemplo acima, a requisição adicionará dois usuários a uma Audience, um com email e handle e outro com email e twitter_id.
Remover usuários de uma Audience
Semelhante ao processo descrito para adicionar usuários, usuários podem ser removidos de uma audiência assim: POST https://ads-api.x.com/11/accounts/18ce54d4x5t/custom_audiences/1nmth/usersoperation_type deve ser definido como Delete e os usuários serão correspondidos em quaisquer chaves presentes ao adicionar usuários à audiência. Por exemplo, se um usuário foi adicionado a uma audiência usando email e twitter_id, então o mesmo usuário pode ser removido usando qualquer uma dessas chaves, ou seja, email ou twitter_id, ou ambas.
Além disso, é possível adicionar e remover usuários de uma Audience na mesma requisição. O endpoint suporta múltiplos operation_type por requisição.
Opt-Out de usuários
Com a depreciação do endpoint global opt-out, os parceiros são obrigados aDelete quaisquer usuários que optaram por sair de qualquer Audience. Existem algumas formas de fazer isso:
- Manter o controle de quais usuários fazem parte de quais Audiences e remover esses usuários individualmente de cada Audience.
- Remover o usuário de todas as Audiences associadas a uma conta Ads.
- Recomendamos fortemente chamar este endpoint em batches quase em tempo real para evitar picos nas filas que demoram mais para processar e, em geral, causar carga desnecessária no nosso sistema. Isso também garante que os usuários estejam disponíveis para segmentação de campanha mais cedo.
- Uma chamada de API bem-sucedida retornará um
success_countetotal_countcorrespondendo ao número de objetosuserrecebidos na requisição. - Este endpoint é atômico por natureza, ou seja, a requisição inteira é bem-sucedida ou, no caso de qualquer erro, a requisição inteira falha. Em caso de resposta de erro, os consumidores da API devem corrigir o erro e tentar novamente a requisição com o payload completo.
- Em caso de falha, os parceiros devem usar uma abordagem de exponential backoff com retries. Por exemplo, tentar novamente imediatamente na primeira falha, tentar após 1 minuto após a segunda falha e após 5 minutos após a terceira falha consecutiva, e assim por diante