Report di debug per Protected Audience

I report di debug di Protected Audience consentono agli sviluppatori di ad tech di dichiarare che gli URL remoti ricevono una richiesta GET dai dispositivi in caso di vincita o perdita di un'asta. Ciò consente i seguenti casi d'uso:

  • Ricevi report sui risultati dell'asta vinti e persi.
  • Capire perché le aste vengono perse. Ad esempio: scopri se si tratta di un problema dell'implementazione di script di offerte o punteggi oppure di un problema di logica principale.
  • Rilevare i problemi relativi all'aggiornamento della logica JavaScript

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

Il piano a lungo termine prevede di consentire alla piattaforma di generare report sui risultati delle aste con il servizio di aggregazione privata. Ciò garantisce che i report successivi non possano essere utilizzati per unire i segmenti di pubblico personalizzati dei singoli utenti all'app del publisher. I report a livello di evento sono temporanei, finché non viene rilasciato un framework di report adeguato.

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

Utilizzo

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

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

Il seguente esempio segnala una perdita dell'asta dell'annuncio con l'offerta vincente e una variabile interna. Questi dati possono 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 al termine dell'asta.

I venditori possono facoltativamente restituire un rejectReason dalla 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 il metodo not-available.

Variabili URL

Le variabili che possono essere aggiunte all'URL di debug corrispondono alle rispettive controparti in Chrome (anche se ${topLevelWinningBid} e ${topLevelMadeWinningBid} non sono disponibili in quanto non esiste il concetto di aste dei componenti su Android).

Nome variabile Descrizione
winningBid Il valore dell'offerta vincente.
madeWinningBid Un valore booleano che indica se l'acquirente di questo segmento di pubblico personalizzato ha effettuato l'offerta vincente tramite questo segmento di pubblico personalizzato o un altro segmento di pubblico personalizzato con lo stesso acquirente.
highestScoringOtherBid Il valore dell'offerta che è stata valutata come seconda più alta dallo script scoreAd del venditore. Tieni presente che questo valore potrebbe non essere la seconda offerta più alta, poiché punteggi e offerte possono essere indipendenti.
madeHighestScoringOtherBid Un valore booleano che indica se l'acquirente di questo segmento di pubblico personalizzato ha fatto l'offerta ${highestScoringOtherBid} da questo segmento di pubblico personalizzato o da un altro segmento di pubblico personalizzato con lo stesso acquirente.
rejectReason Una stringa facoltativamente impostata da un venditore che spiega il motivo del rifiuto di un'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, inclusi il dominio, un prefisso https:// e i dati dell'asta sostituiti.
  • Nelle release future, i ping di debug verranno inviati solo quando si è connessi a una rete Wi-Fi.

Comportamento sul dispositivo

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

Le seguenti proprietà di sistema controllano la frequenza e la dimensione del batch, che possono essere regolate su 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 il completamento di un'asta.

Non esistono garanzie sulla completezza dei report di debug. Se il dispositivo si riavvia o il processo adservices si arresta in modo anomalo prima che vengano inviate le chiamate al server, questi eventi vengono ignorati.

Ogni tecnologia pubblicitaria ha un limite massimo di 75 URL di debug registrati per asta. Gli URL registrati dopo il raggiungimento di questo limite vengono ignorati automaticamente.

Infine, se l'utente ha disattivato AdId, vengono inviati i report di debug. Questa funzionalità non è implementata nell'Anteprima per sviluppatori 9, ma verrà implementata nelle versioni future.

Comportamento del server ad tech

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

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