Report di debug per Protected Audience

I report di debug di Protected Audience consentono agli sviluppatori di tecnologia pubblicitaria di dichiarare URL remoti per ricevere una richiesta GET dai dispositivi quando un'asta viene vinta o persa. Ciò consente i seguenti casi d'uso:

  • Ricevi report sui risultati delle aste vinte e perse.
  • Capire 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 oppure di un problema di logica di base.
  • Rileva 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. La generazione di report di debug è supportata 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 dell'asta con il servizio Private Aggregation. In questo modo, il reporting successivo non può essere utilizzato per unire i segmenti di pubblico personalizzati dei singoli utenti all'app dell'editore. Il reporting a livello di evento è temporaneo, fino al rilascio di un framework di reporting adeguato.

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

Utilizzo

La segnalazione di debug viene implementata 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 una variabile interna. Questi dati possono poi 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 not-available.

Variabili URL

Le variabili che possono essere aggiunte all'URL di debug corrispondono alle 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, tramite questo segmento di pubblico personalizzato o un altro segmento di pubblico personalizzato con lo stesso acquirente.
highestScoringOtherBid Il valore dell'offerta che è stata classificata come seconda più alta 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 potrebbero essere indipendenti.
madeHighestScoringOtherBid Un valore booleano che indica se l'acquirente di questo segmento di pubblico personalizzato ha fatto l'offerta ${highestScoringOtherBid}, tramite questo segmento di pubblico personalizzato o un altro segmento di pubblico personalizzato con lo stesso acquirente.
rejectReason Stringa impostata facoltativamente da un venditore che spiega perché ha rifiutato 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 versioni future, i ping di debug verranno inviati solo quando il dispositivo è connesso alla rete Wi-Fi.

Comportamento sul dispositivo

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

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

Non esistono garanzie assolute sulla completezza dei report di debug. Se il dispositivo si riavvia o il processo adservices 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. Gli URL registrati dopo il raggiungimento del limite vengono eliminati automaticamente.

Infine, se l'utente ha disattivato l'AdId, vengono inviati 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 la generazione di 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 asta dell'annuncio vinta o persa.
  • Ogni richiesta non ha un corpo. Tutti i dati si trovano nei parametri della query.
  • Payload di risposta di grandi dimensioni possono influire negativamente sulle prestazioni e sull'utilizzo dei dati e vengono ignorati.