El servicio de agregación genera informes de resumen de datos de conversiones detallados y mediciones de alcance a partir de informes agregables sin procesar. Para mantener la privacidad y la seguridad de los datos del usuario, el servicio de agregación usa un marco de trabajo que admite la privacidad diferencial (DP) para cuantificar y limitar la cantidad de información que estos informes revelan sobre los usuarios individuales.
En esta guía, se analizan las herramientas y estrategias para crear informes agregables que ayudan a proteger los datos de los usuarios individuales:
- Crea informes de resumen con ruido agregado
- Establece un presupuesto de contribuciones.
- Estrategias para el procesamiento por lotes de informes
- Cómo manejar informes duplicados en lotes
- Controla los informes con un ID compartido común
- Usa claves de agregación declaradas previamente
Informes de resumen con ruido agregado
Cuando envías informes agregables por lotes, el servicio de agregación crea un informe de resumen. Este informe de resumen es un agregado de todas las contribuciones de todas las claves de dominio predefinidas, con ruido estadístico adicional.
El ruido que se agrega a los informes no depende de la cantidad de informes agregados, los valores de los informes individuales ni los valores de los informes agregados. El ruido se extrae de una versión discreta de la distribución de Laplace y se ajusta al presupuesto de contribución (sensibilidad L1) que aplica el cliente según la API de medición correspondiente y el parámetro de privacidad epsilon.
Para obtener más información sobre el ruido y sus implicaciones para los datos de los informes, consulta Información sobre el ruido en los informes de resumen.
Presupuesto de contribución
Para controlar la sensibilidad de un informe de resumen, la cantidad de contribuciones que se pasan en una llamada está vinculada a un límite de límite de contribuciones específico, también conocido como presupuesto de contribuciones. El presupuesto de contribución varía según si usas la API de Attribution Reporting o la API de Private Aggregation.
Para obtener más información sobre cómo establecer presupuestos de contribución para cada API, consulta las siguientes secciones de la documentación de la API:
- Limitación de contribuciones y presupuesto de la API de Attribution Reporting
- Límites de contribución de la API de Private Aggregation
- Limitación y presupuestación de contribuciones de la API de Private Aggregation
Estrategias para el procesamiento por lotes de informes
Cuando agrupas informes agregables, es importante optimizar las estrategias de agrupación para que no se superen los límites de privacidad. Dos conceptos importantes para crear informes por lotes de forma correcta son la regla"sin duplicados" y la idea de lotes disjuntos.
Regla "Sin duplicados"
El servicio de agregación aplica una regla de “sin duplicados”. Esta regla establece que un informe agregable, que report_id identifica de forma inequívoca, solo puede aparecer una vez en un solo lote. Si un informe agregable aparece más de una vez por lote, el primer informe se incluye en la agregación, se descartan los informes posteriores con el mismo report_id y el lote se completa correctamente.
La regla también indica que el mismo informe no puede aparecer en más de un lote. Si ya se incluyó un informe en un lote anterior que se completó correctamente, un lote posterior que también incluya el mismo informe fallará.
Sin la regla "Sin duplicados", un atacante podría obtener información sobre el contenido de un lote específico manipulando el contenido de los lotes a través de la inclusión de copias duplicadas de un informe en un solo lote o en varios.
Para obtener más información sobre cómo aplicar la regla "Sin duplicados" en un lote de informes o en varios lotes, consulta Informes duplicados dentro de lotes.
Lotes independientes
Para evitar situaciones en las que haya superposición entre lotes, el servicio de agregación aplica lotes disjuntos. Esto significa que dos o más lotes no pueden contener informes que compartan un ID compartido común. Un ID compartido es una combinación de datos recopilados del campo shared_info de un informe agregable.
En el siguiente ejemplo de campo shared_info, puedes ver la API, attribution_destination (para Attribution Reporting), reporting_origin, scheduled_report_time, source_registration_time (para Attribution Reporting) y version. Estos campos, excepto report_id, contribuyen al ID compartido.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Dado que source_registration_time se trunca por día y scheduled_report_time se trunca por hora, hay informes que tienen el mismo ID compartido. En este ejemplo, Informe1 y Informe2 comparten campos de información. Ambos informes tienen la misma API, versión, attribution_destination, reporting_origin y source_registration_time. Como report_id no forma parte del ID compartido, puedes ignorar esta diferencia.
En los siguientes ejemplos de Informe1 y Informe2, el valor de scheduled_report_time es el mismo.
Report1 compartió la siguiente información:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Información que compartió Report2:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Los horarios programados para los informes son "19 de febrero de 2024 9:08:10 p.m." para Informe1 y "19 de febrero de 2024 9:55:10 p.m." para Informe2. Debido a que el valor del campo scheduled_report_time se trunca a la hora, ambos informes tienen 1708376890 (el valor codificado para "19 de febrero de 2024, 9 p.m.") como el valor del campo scheduled_report_time.
Todos los demás campos son iguales, por lo que ambos informes tienen el mismo ID compartido. Y, como ambos informes tienen el mismo ID compartido, se deben incluir en el mismo lote.
Si Report1 se agrupó en un lote que se ejecutó correctamente y Report2 se procesa en un lote posterior, el lote con Report2 falla con un error PRIVACY_BUDGET_EXHAUSTED. Si esto sucede, quita los informes con el ID compartido que se hayan agregado correctamente en lotes anteriores y vuelve a intentarlo. Para obtener más información sobre este error, consulta Códigos de error y mitigaciones del servicio de agregación.
Claves de agregación declaradas previamente
Cuando envías un lote al servicio de agregación, este debe incluir los informes agregables que se reciben del origen de los informes y el archivo de dominio de salida. El dominio de salida contiene las claves o buckets que se recuperan de los informes agregables.
Desde el punto de vista de la privacidad, se agrega ruido a todas las claves declaradas previamente en el dominio de salida, incluso cuando no hay ningún informe real que coincida con una clave en particular. Especificar el dominio de salida protege contra un ataque en el que la presencia de una clave en la salida revela algo sobre un solo usuario o evento. Por ejemplo, si solo mostraste una campaña a un usuario, recibir una clave en el resultado revela que el usuario generó una conversión más adelante, incluso con ruido agregado. Si especificas este dominio primero, puedes asegurarte de que no revele nada sobre las contribuciones de los usuarios.
Puedes declarar estas claves de 128 bits en la API de Attribution Reporting o en la API de Private Aggregation y usarlas para codificar las dimensiones de las que deseas hacer un seguimiento.
Solo se consideran las claves declaradas previamente para la agregación y se incluyen en el informe de resumen. Los valores agregados de los buckets en el informe de resumen tienen ruido estadístico agregado, lo que se refleja en el informe de resumen creado.
Si se incluye una clave de agregación en el archivo de dominio de salida, pero no se encuentra en un informe por lotes, incluso si el valor agregado es cero, es probable que el informe de resumen final no sea cero debido al ruido agregado para preservar la privacidad.