Obecnie dzięki usłudze agregacji możesz przetwarzać określone pomiary z różną częstotliwością, korzystając z identyfikatorów filtrowania. Identyfikatory filtrowania można teraz przekazywać podczas tworzenia zadania w usłudze agregacji w ten sposób:
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
}
}
Aby korzystać z tej implementacji filtrowania, zalecamy rozpoczęcie od interfejsów API klienta pomiarów (Attribution Reporting API lub Private Aggregation API) i przekazanie identyfikatorów filtrowania. Zostaną one przekazane do wdrożonej usługi agregacji, aby końcowy raport podsumowujący z oczekiwanymi wynikami po zastosowaniu filtra.
Jeśli martwisz się, jak to wpłynie na Twój budżet, pamiętaj, że budżet konta raportów zbiorczych będzie wykorzystywany tylko do filtrowania identyfikatorów, które są określone w konfiguracji job_parameters na potrzeby raportów. Dzięki temu możesz ponownie uruchomić zadania dotyczące tych samych raportów, podając inne identyfikatory filtrowania, bez występowania błędów związanych z wyczerpaniem budżetu.
Poniższy schemat przedstawia, jak możesz korzystać z tego interfejsu w ramach interfejsu Private Aggregation API, Shared Storage API i Aggregation Service w chmurze publicznej.
Ten schemat przedstawia, jak używać filtrowania identyfikatorów za pomocą interfejsu Attribution Reporting API i usług skrótu w chmurze publicznej.
Aby dowiedzieć się więcej, zapoznaj się z artykułami Omówienie interfejsu Attribution Reporting API i Omówienie interfejsu Private Aggregation API oraz z pierwotną propozycją.
Aby uzyskać więcej informacji, zapoznaj się z sekcją interfejsu Attribution Reporting API lub interfejsu Private Aggregation API. Więcej informacji o punktach końcowych createJob i getJob znajdziesz w dokumentacji interfejsu Aggregation Service API.