Protected Audience: guia de integração

A API Protected Audience, anteriormente conhecida como FLEDGE nas implementações do Android, geralmente envolve a integração entre apps de anunciantes, editores, vendedores e compradores. Este guia é destinado a parceiros que pretendem gerenciar públicos-alvo personalizados e realizar leilões, incluindo redes de adtech que agem como compradores e vendedores. Campanhas publicitárias diferentes podem ter metas diferentes, e nem todos os recursos da API Protected Audience são aplicados em todos os casos de uso. Este guia destaca as etapas necessárias para dar suporte a casos mais especializados sempre que possível.

Para preparar a implantação de produção em escala da Protected Audience, os parceiros podem simular os pontos de integração com outras partes. Para ajudar você com o planejamento de integração, este guia oferece uma visão abrangente de como integrá-lo aos seus apps Android. Ele pode explicar recursos que ainda não estão implementados na prévia para desenvolvedores atual do Sandbox de privacidade para Android. Nesses casos, são fornecidas orientações sobre o cronograma.

O fluxo de trabalho de integração da API Protected Audience consiste em quatro etapas principais geradas por diferentes tipos de parceiros de adtech:

  1. O comprador cria públicos-alvo personalizados.
  2. O processo de seleção de anúncios escolhe um anúncio vencedor.
    1. O app do vendedor inicia a seleção de anúncios.
    2. Os serviços de publicidade executam a filtragem da compra e o código de lance.
    3. Eles executam o código de decisão do lado do vendedor.
  3. O anúncio vencedor é renderizado no app do vendedor.
  4. Os relatórios de impressões de anúncio são disponibilizados tanto para o comprador quanto para o vendedor.

Essas etapas são ilustradas no diagrama abaixo:

Diagrama visual do fluxo de trabalho de seleção de anúncios.
O fluxo de trabalho de gerenciamento de público-alvo personalizado e seleção de anúncios da Protected Audience.

Terminologia

  • Anunciante: empresa que gera engajamento com os usuários pela compra de inventário de anúncios.
  • Editor: empresa que vende o inventário de anúncios disponível ao lado do conteúdo.
  • Comprador: empresa de adtech que facilita a compra de inventário de anúncios pelos anunciantes.
  • Vendedor: empresa de adtech que faz a intermediação dos editores na venda de inventário de anúncios.
  • Rede: empresa de adtech que atua como comprador e vendedor.
  • Pertencente e operado: empresa que atua como editor, vendedor e comprador.
  • Parceiros de integração: qualquer empresa com quem você precisa trabalhar para fazer a integração com a Protected Audience.

Pré-requisitos, engajamento do parceiro de integração e configuração

Nesta seção, apresentamos um conjunto de atividades iniciais para você entender como a Protected Audience funciona, como começar a integração dele e como interagir com seus parceiros de integração em uma implementação. Essas atividades podem acontecer em paralelo.

Diagrama mostrando o guia de lançamento de recursos da API Protected Audience.
Guia de lançamento de recursos da API Protected Audience.

Conheça a API Protected Audience

A primeira etapa é se familiarizar com os serviços e as APIs de público-alvo protegido.

  1. Comece lendo a proposta de design para conhecer a API Protected Audience e os recursos dela.
  2. Leia o guia para desenvolvedores para saber como incorporar o código e as chamadas de API necessárias para seus casos de uso e descobrir quais são os serviços de integração da Protected Audience.
  3. Envie feedback sobre o design e a implementação de APIs, serviços e documentação da API Protected Audience.
  4. Inscreva-se para receber atualizações e ficar por dentro dos recursos mais recentes do Sandbox de privacidade.

Configurar e testar apps de exemplo

Depois de conhecer os fundamentos da API Protected Audience descritos acima, configure e teste os apps de exemplo.

  1. Quando estiver tudo pronto para iniciar a integração, configure o ambiente de desenvolvimento com a prévia para desenvolvedores do Sandbox de privacidade mais recente.
  2. Configure os endpoints de servidor necessários. Use as simulações de exemplo (link em inglês) com sua solução de teste de API preferida para inicializar esse processo.
  3. Bifurque e execute o código do nosso app de exemplo (link em inglês) para se familiarizar com o gerenciamento de públicos-alvo personalizados, o fluxo de trabalho de seleção de anúncios e os relatórios de impressões.

Engajamento do parceiro de integração

Agende conversas com seus parceiros de integração para falar sobre como testar e implementar a Protected Audience no Android, incluindo a forma dos indicadores transmitidos entre as partes. Para os compradores, as conversas precisam incluir estratégias para criar e participar de públicos-alvo personalizados, além de explicações sobre como esses públicos são definidos. Colabore com seus parceiros para definir cronogramas de integração, desde o teste inicial até a implementação, e decidir por quais áreas cada parte é responsável no design.

Configuração Beta (disponível no quarto trimestre)

Registre sua organização no Sandbox de privacidade do Android. A inscrição é necessária para garantir que os desenvolvedores de adtech operem de acordo com as políticas do Sandbox de privacidade e permite que eles definam a identidade em vários SDKs e domínios.

Considerações sobre arquitetura

Para compradores e vendedores, a Protected Audience apresenta a capacidade de executar leilões de anúncios no dispositivo. Você e seus parceiros de integração precisam fazer várias considerações importantes nos designs:

Os públicos-alvo e os anúncios de remarketing são armazenados no dispositivo

Em vez de armazenar anúncios em servidores, como acontece hoje, as informações de público-alvo e os anúncios de remarketing são armazenados no dispositivo. Os anúncios contextuais que não dependem de dados no dispositivo para segmentação continuam nos servidores. As plataformas de adtech precisam se expandir para considerar a demanda de anúncios distribuída entre servidores e dispositivos.

Os processos de lances e leilões são realizados no dispositivo

Além de veicular leilões em servidores, as plataformas de adtech agora têm a oportunidade de definir o preço e classificar a demanda de anúncios armazenada no dispositivo.

Assim como já ocorre, é normal as adtechs veicularem leilões para anúncios contextuais. Depois de concluir o leilão, um vendedor pode optar por realizar um leilão no dispositivo para avaliar a demanda de remarketing armazenada no dispositivo. Considerando que esses processos agora são executados no dispositivo, é importante se lembrar dos limites existentes para garantir que o leilão seja realizado de ponta a ponta, conforme projetado pelos diferentes parceiros de integração, em vários casos de uso de remarketing.

Estratégia de dados

As plataformas de adtech precisam considerar os tipos de dados usados em leilões. Atualmente, essas informações são coletadas de várias fontes e centralizadas em um servidor. Os leilões da Protected Audience oferecem caminhos diferentes para transmitir esses dados. Por exemplo, os indicadores em tempo real, como orçamento restante, vêm de um serviço de chave-valor na forma de indicadores de confiança, enquanto os indicadores de contexto, como hora do dia, são enviados pelos vendedores durante um leilão. Esses indicadores são explicados em mais detalhes nas seções específicas deste guia.

Criar sua solução

Existem várias fases importantes para realizar um leilão com o público-alvo personalizado. Os compradores precisam criar o público-alvo, fornecer dados de lances, segmentar anúncios para públicos-alvo e configurar lances. O vendedor precisa configurar e acionar o leilão, classificar os anúncios candidatos e selecionar um vencedor. Algumas fases exigem colaboração entre as duas partes para garantir que o leilão seja veiculado corretamente. As seções a seguir descrevem cada etapa em detalhes e destacam qual parte é responsável pela implementação.

Compradores: como criar um público-alvo

Os compradores normalmente gerenciam públicos-alvo personalizados. Como os públicos-alvo personalizados são gerenciados no dispositivo, a API responsável por isso é projetada para ser invocada no dispositivo.

Se você tiver seu próprio SDK no app dos anunciantes, implemente esse código diretamente via joinCustomAudience().

Caso você não tenha seu próprio código de SDK nos dispositivos, considere se unir a um parceiro de integração existente que também seja um provedor de SDK. Identifique e trabalhe com esse parceiro para escrever um contrato e um fluxo para definir e gerenciar públicos-alvo personalizados. Este guia usa o termo "comprador" independente da abordagem usada. Alguns exemplos de abordagens incluem:

  • Se você for o comprador, peça ao anunciante para definir o público-alvo. Um SDK do parceiro de integração no dispositivo pode enviar eventos de apps ao comprador. Quando os critérios predefinidos forem atendidos, o comprador vai enviar uma mensagem ao SDK para participar do público-alvo personalizado no cliente em nome do comprador.
  • O SDK pode ser proprietário direto do público-alvo. Os anunciantes trabalham com um provedor de SDK para definir o público-alvo. O SDK monitora os eventos do app, faz o registro no público-alvo no momento adequado e informa ao comprador que um usuário foi adicionado ao público.

Protótipo da campanha de remarketing: criar um público-alvo personalizado

Um público-alvo personalizado é um agrupamento de usuários com interesses semelhantes que podem receber anúncios personalizados. Os compradores podem ajudar os anunciantes a criar públicos-alvo personalizados nos apps com base na atividade do usuário.

Para o público-alvo personalizado, a Protected Audience define um contêiner que é mapeado para um engajamento do usuário específico e personalizado, conforme definido pelo anunciante. Isso inclui um conjunto de anúncios candidatos que podem ser mostrados a esse público-alvo e um conjunto de dados e lógica de lances personalizados que podem ser usados durante um leilão para filtrar e determinar o preço dos anúncios.

Configuração e protótipo

Considerações sobre design

Os compradores podem oferecer suporte a vários casos de uso configurando públicos-alvo personalizados. Isso inclui a definição da lógica de lances para o tipo de anúncio ou campanha com que esse público-alvo é segmentado, a definição da lista de anúncios candidatos e considerações semelhantes. Esta seção inclui considerações de design para preencher e usar alguns campos-chave em um público-alvo personalizado.

URL da lógica de lances

Como os leilões são realizados no dispositivo, os compradores precisam implantar um endpoint que retorne a lógica de lances como JavaScript. Nosso guia para desenvolvedores descreve as assinaturas de método necessárias. A lógica de lances tem acesso a determinados indicadores sobre o usuário durante o leilão, conforme descrito nas próximas seções. A lógica de lances e a configuração dos indicadores do usuário são explicadas mais adiante neste artigo.

Indicadores de lances do usuário

Os compradores podem usar UserBiddingSignals para transmitir informações que o anunciante ou o próprio comprador tem sobre o usuário em leilões futuros no dispositivo. Isso pode incluir informações como:

  • Outros públicos-alvo aos quais o usuário foi adicionado.
  • Insights que o anunciante tem sobre o usuário.

Como esses indicadores estão disponíveis durante o leilão, os compradores podem realizar operações de lances personalizados durante o leilão, incluindo:

  • Aumentar ou diminuir o lance com base nos indicadores relevantes.
  • Filtrar anúncios específicos do leilão.

Dados confiáveis de lances

Como parte da implementação da API Protected Audience, os compradores podem acessar informações em tempo real durante o leilão a partir de um serviço de chave-valor. Como mecanismo temporário, o comprador e o vendedor podem buscar esses indicadores de lance em qualquer serviço, incluindo aqueles que eles mesmos operam. O exemplo mais comum é procurar o orçamento restante para anúncios. Durante o desenvolvimento, é possível simular esse serviço e usá-lo como base. Leia as instruções de configuração no diretório FledgeServerSpec (link em inglês) do nosso repositório de apps de exemplo no GitHub.

O campo TrustedBiddingData é composto por um URL e um conjunto de chaves. Ao criar o tipo de estrutura de chave a ser usada:

  • Uma abordagem simples é incluir uma chave com mapeamento individual para o público-alvo que está sendo criado. O serviço de chave-valor poderá conter todas as informações relevantes associadas ao público-alvo.
  • O orçamento e o status do anúncio são fatores importantes a serem considerados em tempo real.
  • Considere o valor de lance máximo ou outros indicadores que podem ser usados para definir o preço de um anúncio em um leilão. É possível incluir essas informações com o anúncio em uma lista AdData, mas o armazenamento em um serviço de chave-valor facilita a atualização conforme necessário.

Lista AdData

Ao criar uma campanha de remarketing, os anunciantes geralmente consideram tipos diferentes de anúncios para serem mostrados a um usuário em um público-alvo, por exemplo, anunciar descontos diferentes com base no engajamento anterior de um usuário com o app. Um público-alvo personalizado inclui uma lista AdData que contém anúncios candidatos.

A quantidade de informações a serem incluídas para cada anúncio fica a critério dos compradores. Alguns itens a serem considerados:

  • A lista AdData pode ser atualizada de duas maneiras:
    • Quando um app tem uma atividade visível em primeiro plano, ele pode iniciar a lista ao associar um usuário a um público-alvo personalizado.
    • Durante uma atualização diária, a busca pode ser iniciada em segundo plano. O dispositivo envia uma solicitação para o daily_update_url incluído na chamada joinCustomAudience e espera uma resposta que tenha uma lista AdData atualizada.
  • Outras informações sobre anúncios podem ser solicitadas durante o leilão. Antes do leilão, o dispositivo envia uma solicitação ao serviço de chave-valor do comprador que foi fornecido no campo trustedBiddingData de joinCustomAudience. O serviço de chave-valor é um novo serviço que faz parte da implementação da Protected Audience dos compradores. Confira mais detalhes sobre esse serviço neste documento.
  • Com a inclusão de um ID de criativo para seu anúncio você pode executar algumas ações em criativos específicos. Por exemplo, os anunciantes podem pausar criativos específicos e você quer extrair esses IDs do serviço de chave-valor em tempo real e fazer a correspondência com anúncios na lista AdData.

AdData precisa incluir um render_url. O URL de renderização do anúncio de remarketing vencedor é usado para renderizar o anúncio. Confira algumas considerações:

  • O URL de renderização tem um limite de k-anonimato; portanto, evite incluir parâmetros estreitos. Mais informações sobre esse limite de k-anonimato serão publicadas no futuro.
  • Esse URL precisa conter todas as informações necessárias para renderizar o anúncio. Por exemplo, se você quiser mostrar produtos específicos, incorpore os IDs dos produtos como parâmetros no URL.

Durante a prototipagem, o único campo obrigatório é renderUri, que aponta para os recursos de renderização do anúncio. O campo de metadados em AdData pode ser ignorado durante a criação da solução. Ao mover a solução para produção, considere quais metadados são relevantes para você, porque eles podem ser usados durante a geração de lances para ajustar o preço do lance.

Tempo de ativação e validade

É possível usar os campos de tempo de ativação e de validade para oferecer suporte a casos de uso em que um público-alvo personalizado só esteja qualificado para leilões em um período predefinido. Esteja ciente de que existem algumas limitações para a duração do tempo de ativação e para o delta entre o tempo de ativação e de validade. Como exemplos de casos de uso, temos:

  • Usuário prescrito (por exemplo, um usuário que não interagiu com o app do anunciante nos últimos sete dias)
    • Sempre que o usuário abrir o app, o comprador poderá chamar joinCustomAudience e configurar activation_time para ser um carimbo de data/hora de sete dias no futuro.
    • O público-alvo estará qualificado para lances se tiverem passado sete dias desde a última vez que o usuário abriu o app.
  • Público-alvo sazonal (um público-alvo válido somente durante um período específico em um futuro próximo)
    • Um comprador pode começar a definir públicos-alvo personalizados com antecedência que só podem estar qualificados para lances durante um período predeterminado no futuro (próximo).
    • Por exemplo, se um anunciante tiver uma campanha de fim de verão nos Estados Unidos em 2022, o comprador poderá chamar joinCustomAudience e configurar activation_time para ser sábado, 20 de agosto de 2022. Se a campanha for veiculada por apenas uma semana, o comprador poderá definir a data de validade como 27 de agosto de 2022. Depois disso, o público-alvo personalizado será filtrado pela plataforma durante a seleção do anúncio e, por fim, o lixo coletado.

Compradores e vendedores: seleção de anúncios

A seleção de anúncios requer colaboração entre compradores e vendedores. Isso pode ser considerado como um processo de quatro etapas:

  1. Os vendedores definem uma estratégia de mediação.
  2. Os vendedores configuram o leilão e iniciam a seleção de anúncios.
  3. Os compradores são convidados a participar do leilão pela configuração definida pelo vendedor. A lógica de lances do comprador é executada para selecionar um anúncio candidato e um lance.
  4. A lógica de decisão dos vendedores é executada para marcar os candidatos e selecionar um anúncio vencedor.

Para facilitar o desenvolvimento, é possível simular respostas de serviço para compradores e vendedores, o que inclui lógica de lances e pontuação, permitindo que você se concentre no desenvolvimento do que é relevante para seu caso de uso. Consulte o diretório FledgeServerSpec (link em inglês) no GitHub para instruções sobre como configurar endpoints simulados ou o guia para desenvolvedores para instruções sobre como substituir a busca remota em JavaScript.

Vendedores: definir a estratégia de mediação

O objetivo da API Protected Audience é oferecer suporte à mediação em hierarquia. Essa área está em desenvolvimento, e mais informações serão fornecidas quando disponíveis. Por enquanto, consulte a proposta de design para mediação em hierarquia na Protected Audience.

Vendedores: configurar o leilão

Os vendedores são responsáveis por configurar o leilão, fornecendo informações para o processo de seleção de anúncios. Eles podem disponibilizar informações apenas para todas ou algumas partes. Isso pode incluir informações que você tem ou outras informações em nome dos compradores.

Configuração e protótipo

Considerações sobre design

Esta seção inclui considerações de design para preencher e usar campos-chave em uma configuração de seleção de anúncios.

  • O ambiente de execução particular inclui apenas anúncios de público-alvo personalizados no dispositivo. Emitir uma solicitação de anúncio contextual antes permite considerar a demanda extra.

  • Antes de iniciar o fluxo de trabalho de seleção de anúncios, execute uma solicitação de anúncio para coletar informações dos compradores. Em seguida, use essas informações para configurar a seleção de anúncios.

  • Como muitos compradores podem ter criado públicos-alvo personalizados no dispositivo, os vendedores precisam usar o campo compradores de público-alvo personalizado para indicar os compradores específicos que serão incluídos no processo. Essa lista pode ser criada de várias maneiras. Alguns exemplos:

    • Uma lista estática de compradores que o vendedor sempre quer incluir no processo.
    • Uma lista de compradores indicando que querem participar da resposta do anúncio. Essa opção é útil caso o vendedor trabalhe com trocas de anúncios e talvez não tenha conhecimento total de todos os compradores.

  • O vendedor pode transmitir informações para o processo de várias maneiras:

    • O campo de indicadores de seleção de anúncios está disponível para todos os compradores e vendedores que participam do leilão no tempo de execução particular. Use-o para fornecer informações sobre a oportunidade de publicidade, como tamanho e formato do anúncio.
    • O campo de indicadores do comprador é encaminhado a um comprador específico para ser usado no processo de lances. Essas informações são fornecidas pelo comprador e você, como vendedor, precisa considerar como acessar essas informações no dispositivo para uso durante a seleção do anúncio.
    • O campo de indicadores do vendedor é a última maneira do vendedor transmitir informações para o processo. Você, como vendedor, usa esses indicadores ao classificar e filtrar anúncios, como ativar uma confirmação de brand safety.

Compradores: lances para um espaço do anúncio

Configuração e protótipo

  • Um comprador pode adicionar a lógica de lances à função JavaScript generateBid() veiculada do parâmetro biddingLogicUrl definido na criação de um CustomAudience. É possível configurar um serviço de simulação usando a especificação fornecida (link em inglês) ou implementar esse endpoint em um servidor real.
  • Consulte o guia para desenvolvedores para detalhes sobre o uso e a implementação da API.

Considerações sobre design

  • A lógica de lances é executada no dispositivo, e alguns indicadores usados no leilão são consultados em tempo real. Consulte as restrições na lista de limitações.
  • Em alguns casos de uso de anúncios, é importante trabalhar com o vendedor para garantir que você tenha vários candidatos de anúncio e lances a serem considerados no dispositivo.

Lógica de lances de design

A lógica de lances dos compradores precisa ser implementada via JavaScript e executada no dispositivo. O guia para desenvolvedores tem informações sobre a assinatura necessária e detalhes sobre os vários parâmetros transmitidos durante o leilão. A lógica de lances no dispositivo tem acesso a mais informações, transmitidas como parâmetros para a função generateBid().

Fornecer dados de lances

Indicadores de lances em tempo real com serviços de chave-valor

Como comprador, você pode buscar indicadores em tempo real durante um leilão de um serviço de chave-valor de sua propriedade. Você pode encontrar uma implementação inicial desse serviço no repositório público do Sandbox de privacidade (link em inglês) ou criar seu próprio serviço. O URL desse serviço é especificado como trustedBiddingUrl em um público-alvo personalizado, e a plataforma tenta buscar os dados e os disponibilizar para a função generateBid com o trusted_bidding_signals parameter. É necessário estabelecer sua própria estrutura de chave.

Indicadores de contexto e do usuário

A função generateBid tem acesso a outros indicadores de usuário ao executar o leilão no dispositivo. Esses indicadores são transmitidos com os campos contextual_signals e per_buyer_signals. Esses campos são todos os objetos JSON cujo formato precisa ser definido por compradores e vendedores.

O campo contextual_signals inclui informações que podem ser relevantes sobre o usuário. O objeto que contém esses sinais é criado pelo própria Protected Audience e transmitido para sua lógica de lances. No momento, ele é transmitido como um objeto vazio. Se você acredita que um indicador de contexto sobre o usuário pode ser relevante para seu caso de uso, envie seu feedback para consideração.

O campo per_buyer_signals é disponibilizado para sua lógica de lances. Um vendedor define esses valores ao criar a configuração do leilão. Os compradores e vendedores precisam colaborar para garantir que esses dados estejam no dispositivo e sejam transmitidos à lógica de lances. Alguns exemplos de usos desse campo incluem:

  • Filtragem para brand safety. O vendedor pode dar aos compradores algumas informações de classificação sobre o app que está solicitando um anúncio, e o comprador pode usar essas informações para filtrar determinados anúncios.
  • Enviar uma incorporação para um modelo de ML que considera informações contextuais.

Vendedores: classificar e selecionar o anúncio vencedor

Configuração e protótipo

  • Um vendedor pode adicionar a lógica de pontuação à função JavaScript scoreAd() veiculada do parâmetro scoringLogicUrl definido na criação do AdSelectionConfig. É possível configurar um serviço de simulação usando a especificação fornecida (link em inglês) ou implementar esse endpoint em um servidor real.
  • Consulte o guia para desenvolvedores para detalhes sobre o uso e a implementação da API.

Lógica de pontuação do design

Os vendedores implementam a lógica de pontuação no JavaScript, que é executada no dispositivo. O guia para desenvolvedores tem informações sobre a assinatura necessária e detalhes sobre os vários parâmetros transmitidos durante o leilão. Além disso, a lógica de pontuação no dispositivo tem acesso a mais informações transmitidas como parâmetros para a função scoreAd.

Fornecer os dados de pontuação

Indicadores de pontuação em tempo real com serviços de chave-valor

Como vendedor, você pode buscar indicadores em tempo real durante um leilão de um serviço de chave-valor de sua propriedade. Você pode encontrar uma implementação inicial desse serviço no repositório público do Sandbox de privacidade (link em inglês). O URL desse serviço é especificado como o trustedScoringUri na configuração do leilão, e a plataforma tenta buscar os dados e os disponibilizar para a função scoreAd usando o parâmetro trusted_scoring_signals. Você precisa estabelecer sua própria estrutura de chave.

Indicadores de contexto e do usuário

A função scoreAd tem acesso a outros indicadores de usuário ao executar o leilão no dispositivo. Esses indicadores são transmitidos para a função de pontuação pelo campo contextual_signal. Esse campo armazena objetos JSON cujo formato é definido pelos compradores e vendedores.

O campo contextual_signal inclui informações contextuais que podem ser relevantes sobre o usuário. O objeto que contém esses sinais é criado pelo própria Protected Audience e transmitido para sua lógica de lances. No momento, ele é transmitido como um objeto vazio. Se você acredita que um indicador sobre o usuário pode ser relevante para seu caso de uso, envie seu feedback para consideração.

Vendedores: renderizar um anúncio

Os vendedores precisam renderizar o anúncio vencedor. Consulte a proposta de design para mais detalhes sobre como os anúncios vencedores são renderizados. Essa área ainda está em desenvolvimento.

Relatar resultados de impressão

Configuração e protótipo

  • Compradores e vendedores podem adicionar a lógica de relatórios à função JavaScript reportWin() veiculada do parâmetro biddingLogicUrl ou scoringLogicUrl, respectivamente. É possível configurar um serviço de simulação usando a especificação fornecida (link em inglês) ou implementar esse endpoint em um servidor real.
  • Consulte o guia para desenvolvedores para detalhes sobre o uso e a implementação da API.

Considerações sobre design

Os compradores e vendedores precisam implementar uma função reportWin no código JavaScript retornado dos endpoints configurados. Esse método permite que você envie dados de volta aos seus servidores.

O Sandbox de privacidade também oferece uma API Attribution Reporting para gerenciar relatórios agregados e no nível do evento. Para mais detalhes, leia o guia de integração.