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 zwracał oczekiwane wyniki po zastosowaniu filtra.
Jeśli nie wiesz, jak to wpłynie na Twój budżet, pamiętaj, że budżet konta raportów zbiorczych jest 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.