Pour le moment, le service d'agrégation vous permet de traiter certaines mesures à différentes cadences en utilisant des ID de filtrage. Les ID de filtrage peuvent désormais être transmis lors de la création de jobs dans votre service d'agrégation, comme suit :
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
}
}
Pour utiliser cette implémentation de filtrage, il est recommandé de commencer par les API clientes de mesure (API Attribution Reporting ou API Private Aggregation) et de transmettre vos ID de filtrage. Elles seront transmises au service d'agrégation que vous avez déployé, afin que votre rapport récapitulatif final renvoie les résultats filtrés attendus.
Si vous vous inquiétez de l'impact sur votre budget, sachez que le budget de votre compte de rapports agrégés ne sera utilisé que pour les ID de filtrage spécifiés dans votre job_parameters pour les rapports. Vous pourrez ainsi réexécuter des tâches pour les mêmes rapports en spécifiant différents ID de filtrage sans rencontrer d'erreurs de dépassement de budget.
Le flux suivant montre comment vous pouvez utiliser cette fonctionnalité dans l'API Private Aggregation, l'API Shared Storage et le service d'agrégation dans votre cloud public.
Ce flux montre comment utiliser les ID de filtrage avec l'API Attribution Reporting et le service d'agrégation dans votre cloud public.
Pour en savoir plus, consultez la vidéo d'explication de l'API Attribution Reporting et la vidéo d'explication de l'API Private Aggregation, ainsi que la proposition initiale.
Pour en savoir plus, consultez les sections API Attribution Reporting ou API Private Aggregation. Pour en savoir plus sur les points de terminaison createJob et getJob, consultez la documentation de l'API Aggregation Service.