Report di debug per Protected Audience

I report di debug di Protected Audience consentono agli sviluppatori di ad tech di dichiarare URL per ricevere una richiesta GET dai dispositivi in caso di vincita o perdita di un'asta. Questo consente i seguenti casi d'uso:

  • Ricevi report sui risultati delle aste vinti e perse.
  • Scopri perché le aste vengono perse. Ad esempio: capire se si tratta di un problema con l'implementazione di uno script per le offerte o il punteggio oppure con un problema di logica fondamentale.
  • Scoprire i problemi quando viene aggiornata la logica JavaScript

I report di debug a livello di evento sono disponibili per i test in Privacy Sandbox Anteprima per gli sviluppatori 9. I report di debug sono supportati su tutti i dispositivi su cui è presente l'ID pubblicità disponibili.

Il piano a lungo termine è consentire alla piattaforma di generare report sui risultati delle aste con Servizio di aggregazione privata. In questo modo, viene garantito che il report "dopo i fatti" non possono essere utilizzati per unire i segmenti di pubblico personalizzati di singoli utenti alla dell'app del publisher. I report a livello di evento sono temporanei, fino a quando non vengono generati report adeguati viene rilasciato.

Scopri di più sui report di debug nella prova dell'origine FLEDGE originale di Chrome proposta.

Utilizzo

I report di debug vengono implementati utilizzando le seguenti API JavaScript, entrambe che accettano un argomento stringa URL:

  • forDebuggingOnly.reportAdAuctionWin(String url)
  • forDebuggingOnly.reportAdAuctionLoss(String url)

L'esempio seguente riporta una perdita dell'asta dell'annuncio con l'offerta vincente e un variabile interna. Questi dati possono quindi essere utilizzati per il debug.

let someDebuggableVariable = 123;
const url = "https://example.com/reportLoss?winningBid=${winningBid}&someDebuggableVariable=" + someDebuggableVariable;
forDebuggingOnly.reportAdAuctionLoss(url);

Il modello ${winningBid} viene sostituito con il valore reale dopo il tag l'asta.

I venditori possono facoltativamente restituire un valore rejectReason dalla loro funzione 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 un venditore non imposta un motivo di rifiuto, viene inviato not-available .

Variabili URL

Le variabili che possono essere aggiunte all'URL di debug corrispondono al rispettivo in Chrome (sebbene ${topLevelWinningBid} e ${topLevelMadeWinningBid} non sono disponibili perché non esiste un concetto di componente aste su Android).

Nome variabile Descrizione
winningBid Il valore dell'offerta vincente.
madeWinningBid Un valore booleano che indica se l'acquirente di questo modello pubblico ha fatto l'offerta vincente da questo segmento di pubblico personalizzato o da un altro segmento di pubblico personalizzato con lo stesso acquirente.
highestScoringOtherBid Il valore dell'offerta classificata come seconda più alta dal scoreAd del venditore. Tieni presente che potrebbe non essere la seconda offerta più alta. poiché i punteggi e le offerte possono essere indipendenti.
madeHighestScoringOtherBid Un valore booleano che indica se l'acquirente di questo segmento di pubblico personalizzato ha fatto l'offerta di ${highestScoringOtherBid}, con questo pubblico personalizzato o un altro segmento di pubblico personalizzato con lo stesso acquirente.
rejectReason Una stringa impostata facoltativamente da un venditore che spiega perché ha rifiutato una offerta. Può essere uno qualsiasi dei seguenti valori:

  • not-available
  • invalid-bid
  • bid-below-auction-floor
  • pending-approval-by-exchange
  • disapproved-by-exchange
  • blocked-by-publisher
  • language-exclusions
  • category-exclusions

Vincoli

  • L'host dell'URL deve corrispondere al dominio Privacy Sandbox registrato.
  • L'URL non deve superare i 4096 caratteri incluso il dominio, un https:// e i dati dell'asta sostituiti.
  • Nelle versioni future, i ping di debug verranno inviati solo se è attiva la connessione alla rete Wi-Fi.

Comportamento sul dispositivo

In un ambiente mobile, la protezione della memoria e dell'utilizzo della rete è una priorità fondamentale. Di conseguenza, i report di debug vengono eseguiti in batch.

Le seguenti proprietà di sistema controllano la tariffa e la dimensione del batch, che possono essere regolati a valori più bassi per lo sviluppo:

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

La latenza prevista di un report di debug è compresa tra 15 e 60 minuti dopo un'asta viene completata.

Non ci sono garanzie reali sulla completezza dei report di debug. Se il dispositivo o il processo dei servizi pubblicitari si arresta in modo anomalo prima dell'invio delle chiamate al server, questi eventi vengono eliminati.

Ogni tecnologia pubblicitaria ha un limite massimo di 75 URL di debug registrati per asta. URL registrati una volta raggiunto tale limite vengono eliminati automaticamente.

Infine, se l'utente ha disattivato AdId, vengono inviati i report di debug. Questo non è implementato nell'Anteprima per gli sviluppatori 9, ma verrà implementato in futuro e versioni successive.

Comportamento del server ad tech

I server ad tech devono avere i seguenti comportamenti per i report di debug:

  • Il dispositivo invia richieste GET al server specificato con forDebuggingOnly.* API.
  • Ogni richiesta rappresenta un singolo report di debug a livello di evento: una singola asta dell'annuncio una vincita o la perdita dell'asta.
  • Ogni richiesta non ha un corpo. Tutti i dati si trovano nei parametri di query.
  • I payload di risposta di grandi dimensioni possono influire negativamente sulle prestazioni e sull'utilizzo dei dati. vengono ignorati.