En este momento, con el Servicio de agregación, puedes procesar ciertas mediciones con diferentes cadencias aprovechando los IDs de filtrado. Ahora se pueden pasar IDs de filtrado en la creación de trabajos dentro de tu Aggregation Service de la siguiente manera:
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 esta implementación de filtrado, se recomienda comenzar con las APIs del cliente de medición (API de Attribution Reporting o API de Private Aggregation) y pasar tus IDs de filtrado. Estos se pasarán a tu Servicio de agregación implementado, de modo que tu informe de resumen final se muestre con los resultados filtrados esperados.
Si te preocupa cómo afectará esto a tu presupuesto, el presupuesto de tu cuenta de informes agregados solo se consumirá para los IDs de filtrado que se especifiquen en tu job_parameters para los informes. De esta manera, podrás volver a ejecutar trabajos para los mismos informes y especificar diferentes IDs de filtrado sin que se agote el presupuesto.
El siguiente flujo muestra cómo puedes usar esta función en la API de Private Aggregation, la API de Shared Storage y el Servicio de agregación en tu nube pública.
En este flujo, se muestra cómo usar los IDs de filtrado con la API de Attribution Reporting y a través del Servicio de agregación en tu nube pública.
Para obtener más información, consulta la explicación de la API de Attribution Reporting y la explicación de la API de Private Aggregation, así como la propuesta inicial.
Continúa a nuestras secciones de la API de Attribution Reporting o la API de Private Aggregation para obtener una explicación más detallada. Puedes leer más sobre los extremos createJob y getJob en la documentación de la API de Aggregation Service.