Quando raggruppi i report aggregabili, è importante ottimizzare le strategie di raggruppamento in modo da non superare i limiti della privacy. Di seguito sono riportate alcune strategie consigliate per l'invio di batch di report al servizio di aggregazione.
Raccogli i report
Quando raccogli i report da includere in un batch, tieni presente quanto segue:
Riproduzioni dei caricamenti dei report
Nota:i criteri per i nuovi tentativi sono soggetti a modifica. In questo caso, le informazioni in questa sezione verranno aggiornate.
Sia sulla piattaforma web che su quella OS, la piattaforma tenterà di inviare il report tre volte, ma se non riesce a inviarlo dopo il terzo tentativo, il report non verrà inviato. Il valore scheduled_report_time originale viene mantenuto invariato indipendentemente dal momento in cui è possibile inviare il report. Le tempistiche per i nuovi tentativi variano a seconda della piattaforma:
- Un browser web invia i report quando è online. Se l'invio del report non va a buon fine, verrà eseguita un'attesa di cinque minuti per il secondo tentativo e di 15 minuti per il terzo. Se il browser è offline, il tentativo successivo sarà un minuto dopo che è di nuovo online. Non esiste un ritardo massimo nell'invio dei report sul web. Ciò significa che, se il browser si disconnette, non importa quanto tempo fa è stato generato il report, quando il browser si riconnette, tenterà di inviarlo in base al criterio di nuovo tentativo.
- Uno smartphone Android con una connessione di rete stabile. Di conseguenza, eseguirà il job per inviare i report una volta all'ora. Ciò significa che se l'invio di un report non va a buon fine, verrà riprovato nell'ora successiva e poi nell'ora successiva ancora. Se il dispositivo non ha una connessione, tenterà di nuovo di inviare il report con il successivo job di generazione di report che viene eseguito dopo che il dispositivo si è di nuovo connesso alla rete. Il ritardo massimo è di 28 giorni, il che significa che il dispositivo non invierà un report generato più di 28 giorni fa.
Attendere i report
Ti consigliamo di attendere i report in ritardo quando raccogli i report per l'aggregazione. I report in ritardo possono essere determinati controllando il valore scheduled_report_time rispetto alla data di ricezione del report. La differenza di tempo tra questi report ti aiuterà a determinare per quanto tempo potresti dover attendere i report in ritardo. Ad esempio, man mano che vengono raccolti i report in ritardo, controlla il campo scheduled_report_time e prendi nota del ritardo in ore quando viene ricevuto il 90%, il 95% e il 99% dei report. Questi dati possono essere utilizzati per determinare il tempo di attesa per i report in ritardo.
I report aggregati istantanei possono essere utilizzati per ridurre la probabilità di report in ritardo.
La seguente visualizzazione mostra i report in ritardo archiviati nei batch appropriati in base all'ora programmata dei report. Il batch T rappresenta scheduled_report_time e T+X il tempo di attesa per i report in ritardo. Il risultato è un report di riepilogo che include la maggior parte dei report inclusi nel batch e che corrisponde all'ora pianificata del report.
Contabilità dei report aggregabili
Il servizio di aggregazione applica una regola"Nessun duplicato". Questa regola impone che tutti i report aggregabili con lo stesso ID condiviso debbano essere inclusi nello stesso batch.
Dopo aver raccolto i report, devono essere raggruppati in modo che tutti i report con lo stesso ID condiviso siano inclusi in un unico batch.
Se un report è già stato elaborato in un altro batch, l'elaborazione può comportare un errore di esaurimento del budget per la privacy. Eseguire correttamente i report batch aiuta a 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à aggregabile dei report. L'ID condiviso garantisce che i report con lo stesso ID condiviso contribuiscano a un solo report di riepilogo. Ciò significa che i report che mappano a un ID condiviso devono essere inclusi tutti in un unico batch. Ad esempio, se i report X e i report Y hanno entrambi lo stesso ID condiviso, devono essere inclusi nello stesso batch per evitare che i report vengano eliminati per i duplicati.
L'immagine seguente mostra i componenti shared_info che vengono sottoposti ad hashing per generare un ID condiviso.
L'immagine seguente mostra come due report diversi possono avere lo stesso ID condiviso:
Nota:scheduled_report_time viene troncato per ora e source_registration_time per giorno. Inoltre, report_id non viene utilizzato per la creazione di ID condivisi. La granularità temporale potrebbe essere aggiornata in futuro.
Duplicare i report all'interno dei batch
Il campo shared_info in 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 saranno considerati duplicati e
eliminati automaticamente. L'aggregazione verrà eseguita normalmente e non verranno inviati errori.
Sebbene non sia obbligatorio, le aziende di tecnologia pubblicitaria possono aspettarsi di ottenere alcuni miglioramenti del rendimento escludendo i report duplicati con gli stessi ID prima dell'aggregazione.
report_id è univoco per ogni report.
Duplicare i report 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 inclusi nello stesso batch. Se
i report con lo stesso ID condiviso vengono inseriti in più batch, verrà accettato solo il primo
e gli altri verranno rifiutati come duplicati. Per evitare questo,
i batch devono essere creati in modo appropriato.
L'immagine seguente mostra un esempio in cui i report con lo stesso ID condiviso tra batch possono causare errori nel batch successivo. Nell'immagine, puoi vedere che due o più report con lo stesso ID condiviso e679aa vengono raggruppati in batch diversi 1 e 2. Poiché il budget per tutti i report con ID condivisoe679aa viene utilizzato durante la generazione del report di riepilogo del batch 1, il batch 2 non è consentito e non va a buon fine con un errore.
Report batch
Di seguito sono riportati i modi consigliati per raggruppare i report per evitare duplicati e ottimizzare la registrazione dei report aggregati.
Batch per inserzionista
Nota:questa strategia è consigliata solo per l'aggregazione dei report sull'attribuzione.
L'aggregazione privata non ha un campo attribution_destination, ovvero l'inserzionista. È consigliabile aggregare i report per inserzionista, ovvero includere i report appartenenti a un singolo inserzionista nello stesso batch, per evitare di raggiungere il limite di account report aggregabili per ogni batch. Inserzionista è un campo preso in considerazione per la 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 raggruppamento, ti consigliamo di prendere in considerazione 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 almeno a intervalli di un'ora, il che significa
che tutti i report con ora del report pianificata all'interno della stessa ora devono essere inclusi nello stesso batch per evitare
di avere report con lo stesso ID condiviso in più batch, il che causerà errori di job.
Frequenza e rumore dei batch
Ti consigliamo di prendere in considerazione l'impatto del rumore sulla frequenza di elaborazione dei report aggregabili. Se i report aggregabili vengono raggruppati più spesso, ad esempio se i report 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, esegui esperimenti con Noise Lab.