Report di debug per Protected Audience

I report di debug di Protected Audience consentono agli sviluppatori di tecnologia pubblicitaria di dichiarare URL remote per ricevere una richiesta GET dai dispositivi quando un'asta viene vinta o persa. In questo modo, vengono abilitati i seguenti casi d'uso:

  • Ricevere report sui risultati delle aste vinti e persi.
  • Scopri perché le aste vengono perse. Ad esempio, capire se si tratta di un problema con l'implementazione di uno script di offerta o di punteggio o di un problema di logica di base.
  • Rilevare i problemi quando la logica JavaScript viene aggiornata

I report di debug a livello di evento sono disponibili per i test in Privacy Sandbox Developer Preview 9. I report di debug sono supportati su tutti i dispositivi su cui è disponibile AdId.

Il piano a lungo termine è consentire alla piattaforma di registrare i risultati delle aste con il servizio di aggregazione privata. In questo modo, i report post-fatti non possono essere utilizzati per unire i segmenti di pubblico personalizzati dei singoli utenti all' app del publisher. I report a livello di evento sono temporanei, fino al rilascio di un framework per i report adeguato.

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

Utilizzo

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

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

L'esempio seguente riporta una perdita nell'asta di annunci con l'offerta vincente e una variabile interna. Questi dati possono essere utilizzati per eseguire attività di 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.

Facoltativamente, i venditori possono restituire un 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 del rifiuto, viene inviato not-available.

Variabili URL

Le variabili che possono essere aggiunte all'URL di debug corrispondono alle loro controparti in Chrome (anche se ${topLevelWinningBid} e ${topLevelMadeWinningBid} non sono disponibili perché non esiste il concetto di aste di 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 fatto l'offerta vincente per questo segmento di pubblico personalizzato o per un altro segmento di pubblico personalizzato con lo stesso acquirente.
highestScoringOtherBid Il valore dell'offerta che ha ricevuto il secondo punteggio più alto dallo script scoreAd del venditore. Tieni presente che questo potrebbe non essere il secondo valore di offerta più alto, 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 effettuato l'offerta ${highestScoringOtherBid} tramite questo segmento di pubblico personalizzato o un altro segmento di pubblico personalizzato con lo stesso acquirente.
rejectReason Una stringa facoltativa impostata da un venditore che spiega il motivo del rifiuto di un'offerta. Può essere uno 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 vengono inviati solo quando è attiva la connessione 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 generati in batch.

Le seguenti proprietà di sistema controllano la frequenza e le dimensioni dei batch, che possono essere aggiustate a valori inferiori 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 dal completamento di un'asta.

Non sono previste 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 del limite vengono eliminati silenziosamente.

Infine, se l'utente ha disattivato AdId, vengono inviati i report di debug. Questa funzionalità non è implementata in Developer Preview 9, ma lo sarà nelle versioni future.

Comportamento del server di tecnologia pubblicitaria

I server di tecnologia pubblicitaria 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 di asta pubblicitaria.
  • Ogni richiesta non ha un corpo. Tutti i dati sono nei parametri di query.
  • I payload di risposta di grandi dimensioni possono influire negativamente sulle prestazioni e sull'utilizzo dei dati e vengono ignorati.