No momento, com o serviço de agregação, é possível processar algumas medições em cadências diferentes usando IDs de filtragem. Agora, os IDs de filtragem podem ser transmitidos na criação de jobs no Aggregation Service (link em inglês) da seguinte maneira:
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
}
}
Para usar essa implementação de filtragem, é recomendável começar com as APIs do cliente de medição (API Attribution Reporting ou API Private Aggregation) e transmitir seus IDs de filtragem. Elas serão transmitidas para o serviço de agregação implantado, para que o relatório de resumo final retorne com os resultados filtrados esperados.
Se você estiver preocupado com o impacto disso no seu orçamento, saiba que o orçamento agregado da conta de relatórios será consumido apenas para filtrar IDs especificados no job_parameters para relatórios. Assim, você poderá executar novamente os jobs para os mesmos relatórios especificando IDs de filtragem diferentes sem encontrar erros de esgotamento do orçamento.
O fluxo a seguir mostra como você pode usar isso na API Private Aggregation, na API Shared Storage e no serviço de agregação na sua nuvem pública.
Este fluxo mostra como usar IDs de filtragem com a API Attribution Reporting e o serviço de agregação na sua nuvem pública.
Para mais informações, consulte a explicação da API Attribution Reporting e da API Private Aggregation, além da proposta inicial.
Continue para as seções API Attribution Reporting ou API Private Aggregation para ler uma conta mais detalhada. Leia mais sobre os endpoints createJob e getJob na documentação da API Aggregation Service.