Quando raggruppi i report aggregabili, è importante ottimizzare le strategie di raggruppamento in modo che i limiti di privacy non vengano superati. Di seguito sono riportate alcune strategie consigliate per l'invio di batch di report al servizio di aggregazione.
Raccogliere i report
Quando raccogli i report da includere in un batch, tieni presente quanto segue:
Tentativi di caricamento dei report
Nota:i criteri di ripetizione sono soggetti a modifica. In questo caso, le informazioni in questa sezione verranno aggiornate.
Sia sulle piattaforme web che su quelle OS, una piattaforma tenterà di inviare il report tre volte, ma se
l'invio non va a buon fine dopo il terzo tentativo, il report non verrà inviato. Il valore
scheduled_report_time originale viene conservato indipendentemente da quando il report può essere inviato. La
tempistica per i tentativi varia a seconda della piattaforma:
- Un browser web invia i report quando è online. Se l'invio del report non va a buon fine, il sistema attenderà cinque minuti per il secondo tentativo e poi 15 minuti per il terzo. Se il browser va offline, il successivo tentativo verrà eseguito un minuto dopo il ritorno online. Non esiste un ritardo massimo nell'invio dei report sul web. Ciò significa che, se il browser va offline, indipendentemente da quanto tempo fa è stato generato il report, una volta che il browser torna online, tenterà di inviarlo in conformità con il criterio di ripetizione dei tentativi.
- Uno smartphone Android con una connessione di rete stabile. Pertanto, eseguirà il job per inviare i report una volta all'ora. Ciò significa che se un report non viene inviato, verrà ritentato l'invio l'ora successiva e di nuovo l'ora dopo. Se il dispositivo non ha una connessione, riproverà a inviare il report con il successivo job di reporting eseguito dopo che il dispositivo si è connesso di nuovo alla rete. Il ritardo massimo è di 28 giorni, il che significa che il dispositivo non invierà un report generato più di 28 giorni fa.
Attendi i report
Ti consigliamo di attendere i report in ritardo quando li raccogli per il batching. I report
in ritardo possono essere determinati controllando il valore scheduled_report_time rispetto al momento in cui il report è stato
ricevuto. La differenza di tempo tra questi report ti aiuterà a determinare per quanto tempo potresti voler
attendere i report in ritardo. Ad esempio, man mano che vengono raccolti i report ritardati, controlla il campo
scheduled_report_time e annota il ritardo in ore man mano che vengono ricevuti il 90%, il 95% e il 99% dei report. Questi dati possono essere utilizzati per determinare per quanto tempo attendere i report arrivati in ritardo.
I report aggregati istantanei
possono essere utilizzati per ridurre la probabilità di ritardi nella generazione dei report.
La seguente immagine mostra i report in ritardo archiviati nei batch appropriati in base all'ora del report pianificata. Batch T rappresenta scheduled_report_time, mentre T+X rappresenta il tempo di attesa
per i report ritardati. Il risultato è un report di riepilogo che include la maggior parte dei report inclusi nel batch che corrisponde all'ora del report pianificato.
Contabilizzazione dei report aggregabili
Il servizio di aggregazione mantiene una "regola di eliminazione dei duplicati". Questa regola impone che tutti i report aggregabili con lo stesso ID condiviso debbano essere inclusi nello stesso batch.
Una volta raccolti, i report devono essere raggruppati in modo che tutti quelli con lo stesso ID condiviso facciano parte di un unico batch.
Se un report è già stato elaborato in un altro batch, l'elaborazione può generare un errore di esaurimento del budget di privacy. La creazione corretta di report batch consente di evitare che i batch vengano rifiutati a causa della regola "Nessun duplicato".
Un ID condiviso è una chiave generata per ogni report per monitorare la contabilità dei report aggregabili. L'ID condiviso garantisce che i report con lo stesso ID condiviso contribuiscano a un solo report di riepilogo. Ciò significa che i report mappati insieme a un ID condiviso devono essere tutti inclusi in un unico batch. Ad esempio, se il report X e il report Y hanno lo stesso ID condiviso, devono essere inclusi nello stesso batch per evitare che i report vengano eliminati per duplicazione.
L'immagine seguente mostra i componenti shared_info di cui viene eseguito l'hashing per generare un ID condiviso.
L'immagine seguente mostra come due report diversi possono avere lo stesso ID condiviso:
Nota: scheduled_report_time è troncato per ora e source_registration_time per giorno. Inoltre, report_id non viene utilizzato nella creazione di ID condivisi. La granularità temporale potrebbe essere aggiornata in futuro.
Duplicare i report all'interno dei batch
Il campo shared_info di un report aggregabile contiene un UUID nel campo report_id, che viene
utilizzato per identificare i report duplicati all'interno di un batch. Se in un batch è presente più di un report con lo stesso
report_id, verrà aggregato solo il primo report, mentre gli altri verranno considerati
duplicati e ignorati automaticamente; l'aggregazione procederà normalmente e non verranno inviati errori.
Sebbene non sia obbligatorio, le tecnologie pubblicitarie possono prevedere un miglioramento del rendimento filtrando i report duplicati con gli stessi ID report prima dell'aggregazione.
Il report_id è univoco per ogni report.
Report duplicati in più batch
A ogni report viene assegnato un ID condiviso, ovvero un ID generato da punti dati combinati provenienti
dal campo shared_info del report. Più report possono avere lo stesso ID condiviso e ogni batch
può contenere più ID condivisi. Tutti i report con lo stesso ID condiviso devono essere inseriti nello stesso batch. Se
i report con lo stesso ID condiviso finiscono in più batch, verrà accettato solo il primo batch,
mentre gli altri verranno rifiutati in quanto duplicati. Per evitare questo problema,
i batch devono essere creati in modo appropriato.
L'immagine seguente mostra un esempio in cui i report con lo stesso ID condiviso tra i batch possono causare
l'errore del batch successivo. Nell'immagine puoi vedere che due o più report con lo stesso ID condiviso
e679aa sono raggruppati in batch diversi, #1 e #2. Poiché il budget per tutti i report con ID condiviso
e679aa viene utilizzato durante la generazione del report riepilogativo del batch n. 1, il batch n. 2 non è consentito e genera
un errore.
Report batch
Di seguito sono riportati i modi consigliati per raggruppare i report in batch per evitare duplicati e ottimizzare la contabilità dei report aggregati.
Batch per inserzionista
Nota:questa strategia è consigliata solo per l'aggregazione dei report sull'attribuzione.
Private Aggregation non ha un campo attribution_destination, ovvero l'inserzionista. È
consigliabile raggruppare per inserzionista, ovvero includere i report appartenenti a un singolo inserzionista nello
stesso batch, per evitare di raggiungere il limite dell'account report aggregabile per ogni batch. L'inserzionista è
un campo considerato nella generazione dell'ID condiviso, pertanto i report con lo stesso inserzionista potrebbero avere anche
lo stesso ID condiviso, il che richiederebbe che si trovino nello stesso batch per evitare errori.
Batch per ora
Quando esegui il batch, ti consigliamo di considerare l'ora del report pianificato (shared_info.scheduled_report_time). L'ora del report pianificato viene troncata all'ora
nella generazione dell'ID condiviso, pertanto i report devono essere raggruppati a intervalli orari, il che significa
che tutti i report con l'ora del report pianificato nella stessa ora devono essere inseriti nello stesso batch per evitare
che i report con lo stesso ID condiviso vengano distribuiti su più batch, il che comporterà errori del job.
Frequenza batch e rumore
Ti consigliamo di considerare l'impatto del rumore sulla frequenza di elaborazione dei report aggregabili. Se i report aggregabili vengono raggruppati più frequentemente, ad esempio vengono elaborati una volta all'ora, verranno inclusi meno eventi di conversione e il rumore avrà un impatto relativo maggiore. Se la frequenza viene ridotta e i report vengono elaborati una volta alla settimana, il rumore avrà un impatto relativo minore. Per comprendere meglio l'impatto del rumore sui batch, prova Noise Lab.