Al momento, con il servizio di aggregazione puoi elaborare determinate misurazioni con frequenze diverse sfruttando gli ID filtro. Ora gli ID filtro possono essere trasmessi durante la creazione del job nel servizio di aggregazione nel seguente modo:
POST createJob
Body: {
"job_parameters": {
"output_domain_blob_prefix": "domain/domain.avro",
"output_domain_bucket_name": "<data_bucket>",
"filtering_ids": [1, 3] // IDs to keep in the query
}
}
Per utilizzare questa implementazione dei filtri, ti consigliamo di iniziare dalle API client di misurazione (API Attribution Reporting o API Private Aggregation) e di passare gli ID filtro. Questi verranno trasmessi al servizio di aggregazione di cui è stato eseguito il deployment, in modo che il report di riepilogo finale restituisca i risultati filtrati previsti.
Se temi che questo possa influire sul tuo budget, tieni presente che il budget dell'account report aggregato verrà utilizzato solo per filtrare gli ID specificati in job_parameters per i report. In questo modo, potrai eseguire nuovamente i job per gli stessi report specificando ID filtro diversi senza riscontrare errori di esaurimento del budget.
Il seguente flusso illustra come puoi utilizzare questa funzionalità all'interno dell'API Private Aggregation, dell'API Shared Storage e fino al servizio Aggregation nel tuo cloud pubblico.
Questo flusso illustra come utilizzare gli ID filtro con l'API Attribution Reporting e fino al servizio di aggregazione nel tuo cloud pubblico.
Per ulteriori informazioni, consulta l'explainer dell'API Attribution Reporting e l'explainer dell'API Private Aggregation, nonché la proposta iniziale.
Per una descrizione più dettagliata, consulta le sezioni relative all'API Attribution Reporting o all'API Private Aggregation. Per saperne di più sugli endpoint createJob e getJob, consulta la documentazione dell'API Aggregation Service.