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 do 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 użyć 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 zwrócił oczekiwane wyniki 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 różne 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, a także z pierwotną propozycją.
Aby uzyskać więcej informacji, zapoznaj się z sekcją poświęconą interfejsom Attribution Reporting API lub Private Aggregation API. Więcej informacji o punktach końcowych createJob i getJob znajdziesz w dokumentacji interfejsu Aggregation Service API.