Os relatórios de depuração do público-alvo protegido permitem que os desenvolvedores de adtechs declarem URLs remotos para receber uma solicitação GET de dispositivos quando um leilão é ganho ou perdido. Isso permite os seguintes casos de uso:
- Receber relatórios sobre os resultados de leilões ganhos e perdidos.
- Entender por que os leilões são perdidos. Por exemplo: entender se é um problema com uma implementação de script de lances ou pontuações ou um problema lógico principal.
- Descobrir problemas quando a lógica do JavaScript é atualizada.
Os relatórios de depuração no nível do evento estão disponíveis para teste na prévia para desenvolvedores 9 do Sandbox de privacidade. Os relatórios de depuração têm suporte em todos os dispositivos em que o ID de publicidade está disponível.
O plano de longo prazo é permitir que a plataforma informe os resultados do leilão com o serviço de agregação privada. Isso garante que o relatório após o fato não possa ser usado para unir os públicos-alvo personalizados de usuários individuais ao app do editor. Os relatórios de eventos são temporários até que um framework de relatórios adequado seja liberado.
Saiba mais sobre relatórios de depuração na proposta original de teste de origem do FLEDGE do Chrome.
Uso
Os relatórios de depuração são implementados usando as seguintes APIs JavaScript, ambas com um argumento de string de URL:
forDebuggingOnly.reportAdAuctionWin(String url)forDebuggingOnly.reportAdAuctionLoss(String url)
O exemplo a seguir informa uma perda no leilão de anúncios com o lance vencedor e uma variável interna. Esses dados podem ser usados para depuração.
let someDebuggableVariable = 123;
const url = "https://example.com/reportLoss?winningBid=${winningBid}&someDebuggableVariable=" + someDebuggableVariable;
forDebuggingOnly.reportAdAuctionLoss(url);
O modelo ${winningBid} é substituído pelo valor real após a
conclusão do leilão.
Os vendedores podem retornar um rejectReason da função scoreAds:
function scoreAd(ad, bid, auction_config, seller_signals,
trusted_scoring_signals, contextual_signal,
custom_audience_signal) {
let score = ...
return {
'status': 0,
'score': score,
'rejectReason': 'blocked-by-publisher'
}
}
Se um vendedor não definir um motivo para a rejeição, not-available será
enviado.
Variáveis de URL
As variáveis que podem ser adicionadas ao URL de depuraçãocorrespondem aos
dispositivos correspondentes no Chrome (embora ${topLevelWinningBid} e
${topLevelMadeWinningBid} não estejam disponíveis porque não há um conceito
de leilões de componentes no Android).
| Nome da variável | Descrição |
winningBid |
O valor do lance vencedor. |
madeWinningBid |
Um valor booleano que representa se o comprador desse público-alvo personalizado deu o lance vencedor, seja por esse público-alvo ou por outro com o mesmo comprador. |
highestScoringOtherBid |
O valor do lance que foi classificado como o segundo mais alto pelo script scoreAd do vendedor. Esse pode não ser o segundo maior valor de lance, já que pontuações e lances podem ser independentes. |
madeHighestScoringOtherBid |
Um valor booleano que representa se o comprador desse público-alvo personalizado
deu o lance de ${highestScoringOtherBid}, seja por ele ou por outro público-alvo
personalizado com o mesmo comprador. |
rejectReason |
Uma string opcionalmente definida por um vendedor explicando por que rejeitou um
lance. Pode ser qualquer um destes valores:
|
Restrições
- O host de URL precisa corresponder ao domínio registrado no Sandbox de privacidade.
- O URL não deve exceder 4.096 caracteres, incluindo o domínio, um
https://prefixo e dados de leilão substituídos. - Em versões futuras, os pings de depuração só são enviados quando o dispositivo está conectado ao Wi-Fi.
Comportamento no dispositivo
Em um ambiente móvel, proteger a memória e o uso da rede é prioridade. Assim, os relatórios de depuração acontecem em lotes.
As seguintes propriedades do sistema controlam a taxa e o tamanho do lote, que podem ser ajustados para valores menores para desenvolvimento:
fledge_event_level_debug_reporting_batching_ratefledge_event_level_debug_reporting_batch_size
A latência esperada de um relatório de depuração é de 15 a 60 minutos após a conclusão de um leilão.
Não há garantias quanto à integridade dos relatórios de depuração. Se o dispositivo for reinicializado ou se o processo de serviços de anúncios falhar antes do envio das chamadas ao servidor, esses eventos serão descartados.
Cada adtech tem um limite máximo de 75 URLs de depuração registrados por leilão. Os URLs registrados após esse limite são descartados silenciosamente.
Por fim, se o usuário desativou o ID de publicidade, os relatórios de depuração serão enviados. Isso não foi implementado na prévia para desenvolvedores 9, mas será implementado em versões futuras.
Comportamento do servidor de adtechs
Os servidores de adtechs precisam ter os seguintes comportamentos para relatórios de depuração:
- O dispositivo envia solicitações GET para o servidor especificado com as
APIs
forDebuggingOnly.*. - Cada solicitação representa um único relatório de depuração no nível do evento: um único leilão de anúncios vencedor ou uma perda de leilões.
- As solicitações não tem corpo. Todos os dados estão nos parâmetros de consulta.
- Grandes payloads de resposta podem afetar negativamente o desempenho e o uso de dados e são ignorados.