Il servizio di aggregazione genera report di riepilogo dei dati sulle conversioni dettagliati e misurazioni della copertura da report aggregabili non elaborati. Per mantenere i dati utente privati e protetti, il servizio di aggregazione utilizza un framework che supporta la privacy differenziale per quantificare e limitare la quantità di informazioni che questi report rivelano sui singoli utenti.
Questa guida illustra strumenti e strategie per creare report aggregabili che contribuiscono a proteggere i dati dei singoli utenti:
- Creare report di riepilogo con rumore aggiunto
- Impostare un budget per i contributi
- Strategie per l'aggregazione dei report
- Gestire i report duplicati in batch
- Gestire i report con un ID condiviso comune
- Utilizza le chiavi di aggregazione predefinite
Report di riepilogo con rumore aggiunto
Quando raggruppi i report aggregabili, il servizio di aggregazione crea un report di riepilogo. Questo report di riepilogo è un aggregato di tutti i contributi di tutte le chiavi di dominio predefinite, con un rumore statistico aggiuntivo.
Il rumore aggiunto ai report non dipende dal numero di report aggregati, dai valori dei singoli report o dai valori dei report aggregati. Il rumore viene estratto da una versione discreta della distribuzione di Laplace e viene scalato in base al budget di contributo (sensibilità L1) applicato dal client in base all'API di misurazione corrispondente e al parametro della privacy epsilon.
Per scoprire di più sul rumore e sulle sue implicazioni per i dati dei report, consulta Informazioni sul rumore nei report di riepilogo.
Budget per i contributi
Per controllare la sensibilità di un report di riepilogo, il numero di contributi passati in una chiamata è legato a un limite di confine dei contributi specifico, noto anche come budget dei contributi. Il budget dei contributi varia a seconda che tu utilizzi l'API Attribution Reporting o l'API Private Aggregation.
Per scoprire di più su come impostare i budget dei contributi per ogni API, consulta le seguenti sezioni della documentazione dell'API:
- Budgeting e definizione dei limiti dei contributi dell'API Attribution Reporting
- Limiti per i contributi dell'API Private Aggregation
- Budgeting e limiti dei contributi dell'API Private Aggregation
Strategie per l'aggregazione dei report
Quando raggruppi i report aggregabili, è importante ottimizzare le strategie di raggruppamento in modo che i limiti di privacy non vengano superati. Due concetti importanti per raggruppare correttamente i report sono la regola "Nessun duplicato" e l'idea di lotti sconnessi.
Regola "Nessun duplicato"
Il servizio di aggregazione applica una regola "Nessun duplicato". Questa regola stabilisce che un report aggregabile, identificato in modo univoco da report_id, può essere visualizzato una sola volta in un singolo batch. Se un report aggregabile viene visualizzato più di una volta per batch, il primo report viene incluso nell'aggregazione, i report successivi con lo stesso report_id vengono ignorati e il batch viene completato correttamente.
La regola stabilisce inoltre che lo stesso ID condiviso non può comparire in più di un batch. Se un ID condiviso è già stato incluso in un batch precedente andato a buon fine, un batch successivo che include anche lo stesso ID condiviso non andrà a buon fine.
Senza la regola "Nessun duplicato", un malintenzionato potrebbe ottenere informazioni sui contenuti di un batch specifico manipolando i contenuti dei batch includendo copie duplicate di un report in un singolo batch o in più batch.
Per scoprire di più sull'applicazione della regola "Nessun duplicato" all'interno di un batch di report o in più batch, consulta Report duplicati all'interno di batch.
Batch non congiunti
Per evitare situazioni in cui si verificano sovrapposizioni tra i batch, il servizio di aggregazione applica batch distinti. Ciò significa che due o più batch non possono contenere report che condividono un ID condiviso comune. Un ID condiviso è una combinazione di dati raccolti dal campo shared_info di un report aggregabile, insieme all'ID filtro della richiesta di job. Se non viene specificato alcun ID filtro, viene utilizzato un valore predefinito di 0.
Nel seguente esempio di campo shared_info, puoi vedere l'API, attribution_destination (per Attribution Reporting), reporting_origin, scheduled_report_time, source_registration_time (per Attribution Reporting) e version. Questi campi, ad eccezione di report_id, insieme all'ID filtro della richiesta di job, contribuiscono all'ID condiviso.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Poiché source_registration_time viene troncato per giorno e scheduled_report_time per ora, esistono report con lo stesso ID condiviso. In questo esempio, Report1 e Report2 hanno campi di informazioni condivisi. Entrambi i report hanno la stessa API, versione, attribution_destination, reporting_origin e source_registration_time. Poiché report_id non fa parte dell'ID condiviso, puoi ignorare questa differenza.
Nei seguenti esempi per Report1 e Report2, il valore scheduled_report_time è lo stesso.
Informazioni condivise da Report1:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Informazioni condivise da Report2:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Le ore di generazione dei report pianificati sono "19 febbraio 2024 21:08:10" per Report1 e "19 febbraio 2024 21:55:10" per Report2. Poiché il valore del campo scheduled_report_time viene troncato all'ora, entrambi i report hanno 1708376890 (il valore codificato di "19 febbraio 2024 21:00") come valore per il campo scheduled_report_time.
Poiché tutti gli altri campi e l'ID filtro sono uguali, entrambi i report hanno lo stesso ID condiviso. Poiché entrambi i report hanno lo stesso ID condiviso, devono essere inclusi nello stesso batch.
Se il report Report1 è stato aggregato in un batch precedente andato a buon fine e il report Report2 viene elaborato in un batch successivo, il batch con Report2 non va a buon fine con un errore PRIVACY_BUDGET_EXHAUSTED. In questo caso, rimuovi i report con l'ID condiviso che sono stati raggruppati correttamente nei batch precedenti e riprova. Per ulteriori informazioni su questo errore, consulta Codici di errore e mitigazioni per il servizio di aggregazione.
Chiavi di aggregazione predefinite
Quando invii un batch al servizio di aggregazione, questo deve includere sia i report aggregabili ricevuti dall'origine report sia il file del dominio di output. Il dominio di output contiene le chiavi o i bucket recuperati dai report aggregabili.
Dal punto di vista della privacy, il rumore viene aggiunto a tutte le chiavi preannunciate nel dominio di output, anche quando nessun report reale corrisponde a una determinata chiave. La specifica del dominio di output protegge da un attacco in cui la presenza di una chiave nell'output rivela qualcosa su un singolo utente o evento. Ad esempio, se hai mostrato una campagna a un solo utente, la ricezione di una chiave nell'output indica che l'utente ha generato una conversione in un secondo momento, anche con l'aggiunta di rumore. Se specifichi prima questo dominio, puoi assicurarti che non riveli nulla sui contributi degli utenti.
Puoi dichiarare queste chiavi a 128 bit nell'API Attribution Reporting o nell'API Private Aggregation e utilizzarle per codificare le dimensioni da monitorare.
Solo le chiavi predefinite vengono prese in considerazione per l'aggregazione e incluse nel report di riepilogo. Ai valori aggregati dei bucket nel report di riepilogo viene aggiunto del rumore statistico, che si riflette nel report di riepilogo creato.
Se una chiave di aggregazione è inclusa nel file del dominio di output, ma non si trova in un report batch, anche se il valore aggregato è zero, il report di riepilogo finale probabilmente non sarà uguale a zero a causa del rumore aggiunto per preservare la privacy.