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:
- O comprador cria públicos-alvo personalizados.
- O processo de seleção de anúncios escolhe um anúncio vencedor.
- O app do vendedor inicia a seleção de anúncios.
- Os serviços de publicidade executam a filtragem da compra e o código de lance.
- Eles executam o código de decisão do lado do vendedor.
- O anúncio vencedor é renderizado no app do vendedor.
- 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:
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.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/android/fledge-rollout-plan.png?authuser=7&hl=pt-br)
Conheça a API Protected Audience
A primeira etapa é se familiarizar com os serviços e as APIs de público-alvo protegido.
- Comece lendo a proposta de design para conhecer a API Protected Audience e os recursos dela.
- 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.
- Envie feedback sobre o design e a implementação de APIs, serviços e documentação da API Protected Audience.
- 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.
- 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.
- 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.
- 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
- Use a API de público-alvo personalizado para criar e armazenar um público-alvo no dispositivo. Mais tarde, esse público-alvo poderá ser usado em um leilão
- Consulte o guia para desenvolvedores para detalhes sobre o uso e a implementação da API.
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 chamadajoinCustomAudience
e espera uma resposta que tenha uma listaAdData
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
dejoinCustomAudience
. 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 configuraractivation_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.
- Sempre que o usuário abrir o app, o comprador poderá chamar
- 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 configuraractivation_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:
- Os vendedores definem uma estratégia de mediação.
- Os vendedores configuram o leilão e iniciam a seleção de anúncios.
- 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.
- 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
- Um vendedor pode configurar e iniciar um leilão configurando um objeto
AdSelectionConfig
e usando a APIAdSelection
. Acione o leilão invocandoselectAds()
. - Consulte o guia para desenvolvedores para detalhes sobre o uso e a implementação da API.
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âmetrobiddingLogicUrl
definido na criação de umCustomAudience
. É 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âmetroscoringLogicUrl
definido na criação doAdSelectionConfig
. É 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âmetrobiddingLogicUrl
ouscoringLogicUrl
, 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.
Recomendados para você
- Observação: o texto do link aparece quando o JavaScript está desativado.
- Guia do desenvolvedor Android para a API Protected Audience
- Suporte para a segmentação por público-alvo personalizado usando a API Protected Audience
- Limite de frequência da API Protected Audience