Inyección de ruido

La inyección de ruido es una técnica que se usa para proteger la privacidad del usuario cuando se consulta una base de datos. Funciona agregando ruido aleatorio a una cláusula SELECT agregada de una consulta. Este ruido protege la privacidad del usuario y, al mismo tiempo, proporciona resultados bastante precisos, lo que elimina la necesidad de verificaciones de diferencias y reduce el umbral de agregación requerido para la salida. La mayoría de las consultas existentes se pueden ejecutar en el modo de ruido, con algunas limitaciones.

Conoce los beneficios de usar la inyección de ruido

No se aplican las verificaciones de diferencias: Cuando se ejecutan consultas con inyección de ruido, el Centro de Datos de Anuncios no filtra las filas debido a la similitud con los conjuntos de resultados anteriores. Esto significa que puedes obtener una vista integral de los datos sin dejar de proteger la privacidad del usuario.

La solución de problemas se simplifica: Las filas solo se omiten debido a los requisitos de agregación, lo que facilita la solución de problemas y la adaptación de las consultas.

No hay nueva sintaxis para aprender: no es necesario que aprendas ninguna nueva sintaxis de consulta ni que te familiarices con los conceptos de privacidad para usar el ruido en lugar de las verificaciones de diferencias.

La precisión del resultado es clara: un trabajo correcto muestra el porcentaje total de datos con la cantidad de ruido esperada.

Descubre cómo el ruido afecta los requisitos de privacidad

Verificaciones de diferencias: La inyección de ruido no se basa en las verificaciones de diferencias existentes en el Centro de Datos de Anuncios. Cuando usas la inyección de ruido, las verificaciones de diferencias están inhabilitadas.

Requisito de agregación: La inyección de ruido genera datos de impresiones representados por aproximadamente 20 o más usuarios únicos, y datos de clics o conversiones representados por aproximadamente 10 o más usuarios únicos.

Verificaciones estáticas: No tienen impacto.

Presupuestos y límites de consultas: Las consultas ejecutadas con un porcentaje de ruido comparten el presupuesto de acceso a los datos que se usa con las verificaciones de diferencias. Al igual que con las verificaciones de diferencias, si ejecutas la misma consulta en el mismo conjunto de datos muchas veces, podrías perder el acceso a las fechas consultadas con frecuencia en el conjunto de datos. Esto puede suceder si ejecutas consultas de ventanas deslizantes o si realizas la misma solicitud varias veces.

El modo de ruido impone límites adicionales y más estrictos a la hora de volver a procesar los mismos resultados agregados dentro de las consultas o entre ellas. Al igual que con el presupuesto de acceso a los datos, puedes perder el acceso a las fechas consultadas con frecuencia en el conjunto de datos. Sin embargo, las limitaciones debido a volver a calcular los mismos resultados agregados solo restringirán las consultas en modo de ruido, no las consultas en el modo de verificación de diferencias. Para obtener más información, consulta Resultados repetidos.

Obtén más información sobre las verificaciones de privacidad.

Comprende cómo la inyección de ruido afecta los resultados

El Centro de Datos de Anuncios inyecta ruido para mitigar el riesgo de la divulgación, es decir, el riesgo de que alguien pueda obtener información sobre un usuario individual. Equilibra la privacidad y la utilidad.

La inyección de ruido en el Centro de Datos de Anuncios transforma los resultados de la consulta de la siguiente manera:

  • Limita las contribuciones de usuarios atípicos en los resultados agregados. Suma la contribución de cada usuario en cada agregación y, luego, limita cada contribución con límites de restricción mínimos y máximos.
  • Agrega las contribuciones restringidas por usuario.
  • Agrega ruido a cada resultado agregado, es decir, el resultado de cada llamada a la función de agregación en cada fila. La escala de este ruido aleatorio es proporcional a los límites restringidos.
  • Calcula un recuento de usuarios ruidosos para cada fila y elimina las que tienen muy pocos usuarios. Esto es similar al k-anonimato en el modo de verificación de diferencias, pero debido al ruido, los trabajos que se ejecutan en el mismo conjunto de datos pueden descartar filas diferentes. Además, el modo con ruido disminuye menos filas porque el requisito de agregación es más bajo (aproximadamente 20 en comparación con 50 exactamente).

El resultado final es un conjunto de datos en el que cada fila tiene resultados agregados ruidosos y se eliminaron grupos pequeños. Esto enmascara el efecto de un usuario individual en los resultados que se muestran.

Información acerca de la restricción de agregación

La inyección de ruido en el Centro de Datos de Anuncios usa restricciones de agregación implícitas o explícitas para limitar la contribución de valores atípicos. Puedes elegir qué tipo de restricción usar, según tu caso de uso.

Restricción implícita

En la restricción implícita, los límites se determinan automáticamente. No necesitas ninguna sintaxis de SQL especial para usar restricciones implícitas. Si una fila tiene un rango de valores más amplio que otra, el límite implícito encuentra límites diferentes para estas filas. Esto generalmente da un margen de error más bajo para cada resultado. Por otro lado, cada agregación tiene diferentes límites de restricción y niveles de ruido, lo que puede dificultar su comparación.

La restricción implícita puede fallar cuando una agregación obtiene datos de muy pocos usuarios, por ejemplo, una llamada a COUNTIF() con una condición poco frecuente. Estos casos muestran resultados de NULL. Además, ten en cuenta que COUNT(DISTINCT user_id) usa automáticamente una restricción explícita con límites de 0 y 1.

Restricción explícita

La restricción explícita restringe la contribución total de cada usuario a un rango especificado. Los límites explícitos se aplican de manera uniforme a todas las filas y deben ser valores literales. Incluso si algunas filas tienen un rango más amplio de contribuciones por usuario que otras, se aplican los mismos límites a todas. Esto hace que los resultados de diferentes filas sean más comparables, aunque algunas filas tienen más ruido que con la restricción implícita.

La restricción explícita usa la mitad de ruido que la fijación implícita para un conjunto determinado de límites de restricción. Por lo tanto, si puedes estimar los límites razonables, obtendrás mejores resultados si los configuras de forma explícita.

Para usar restricciones explícitas, configura los límites para cada función de agregación admitida. Para ello, agrega números enteros que representen el límite inferior y el superior. Por ejemplo:

SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1

Ejecuta una consulta con la inyección de ruido

  1. Escribe una consulta o abre una existente. Para ver qué funciones agregadas se pueden usar, consulta Funciones admitidas.
  2. En el editor de consultas, haz clic en Ejecutar y ingresa los detalles para un trabajo nuevo.
  3. Haz clic en el botón Configuración de privacidad para activar la posición Usar ruido.
  4. Ejecuta la consulta.
  5. Revisa el ruido agregado.
  6. Opcional: Adapta la consulta para reducir el impacto del ruido.

Revisar el impacto del ruido

Una vez que una consulta se completa correctamente, el Centro de Datos de Anuncios muestra la confiabilidad del resultado, según la cantidad de celdas del resultado que tengan la cantidad de ruido esperada. Un valor en la tabla de resultados se considera muy afectado si la escala del ruido agregado es mayor que el 5% del resultado en la celda. Consulta los rangos de impacto en la siguiente tabla.

Para los conjuntos de datos de salida afectados, la pestaña de detalles enumera las 10 columnas más ruidosas (de mayor a menor impacto) y su correspondiente contribución al ruido. Este es el desglose de la cantidad de ruido esperada.

Datos con la cantidad de ruido esperada Color del indicador Impacto
>95% de color verde Impacto bajo
Entre el 85% y el 95% de color amarillo Impacto medio
Entre el 75% y el 85% Orange Alto impacto
Menos del 75% Rojo Impacto muy alto

Sigue estos pasos para ver información detallada sobre el impacto del ruido:

  1. Haz clic en Informes.
  2. Selecciona un informe de la lista. La información sobre la herramienta de resumen de privacidad indica el porcentaje de resultados que tienen la cantidad de ruido esperada, que corresponde a la cantidad de ruido agregada que es superior al 5% del resultado.
  3. Para ver más información, haz clic en Trabajos > Detalles.
  4. Consulta los mensajes de privacidad en los detalles del trabajo. Los resultados se encuentran en una de las categorías enumeradas.
  5. Si es necesario, ajusta la consulta para mejorar el resultado.

Adapta consultas

Es más probable que los resultados agregados tengan una cantidad de ruido inesperada cuando pocos usuarios contribuyen a esos resultados. Esto puede suceder cuando las filas tienen pocos usuarios o cuando algunos usuarios no afectan los resultados, por ejemplo, cuando se usa la función COUNTIF. En función de los detalles de ruido, es posible que desees ajustar tu consulta para aumentar el porcentaje de datos con la cantidad de ruido esperada.

Los siguientes son lineamientos generales:

  • Expande el período.
  • Vuelve a escribir la consulta para reducir el nivel de detalle de los datos, por ejemplo, agrupándolos por menos parámetros o reemplazando COUNTIF por COUNT.
  • Quita las columnas con ruido.
  • Usa restricciones explícitas.

Funciones de agregación compatibles

Las siguientes funciones de agregación son compatibles con el ruido:

  • SUM(...)
  • COUNT(*)
  • COUNT(...)
  • COUNTIF(...)
  • COUNT(DISTINCT user_id)
  • APPROX_COUNT_DISTINCT(user_id)
  • AVG(...)

La palabra clave DISTINCT solo es compatible con la función COUNT y solo cuando se usa con una referencia directa a la columna user_id de una tabla del Centro de Datos de Anuncios o una expresión que muestra user_id o NULL, como COUNT(DISTINCT IF(..., user_id, NULL)).

Las siguientes funciones no son directamente compatibles, pero se pueden reemplazar por otros agregados con ruido para obtener resultados estadísticos. Ten en cuenta que los valores numéricos son solo ejemplos:

  • LOGICAL_OR(...). Reemplazo sugerido: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
  • LOGICAL_AND(...). Reemplazo sugerido: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

Acerca de los resultados de números enteros

Aunque el Centro de Datos de Anuncios insertará ruido automáticamente para estas funciones de agregación, las firmas de las funciones no cambian. Debido a que las funciones como COUNT o SUM de INT64 muestran INT64, cualquier parte decimal del resultado con ruido se redondea. Por lo general, esto es insignificante en relación con el tamaño del resultado y el ruido.

Si necesitas el nivel de detalle del decimal en el resultado, evita escribir funciones que muestren INT64, por ejemplo, usando SUM con su conversión de entrada a FLOAT64.

Patrones de consulta compatibles

Importante: La mayoría de las prácticas recomendadas estándar del Centro de Datos de Anuncios aún se aplican a las consultas que usan la inyección de ruido. En particular, te recomendamos que revises la guía sobre cómo consultar los mismos datos repetidamente.

En esta sección, se describen los patrones de consulta que son compatibles cuando se ejecutan consultas mediante la inyección de ruido.

Agregados a nivel de usuario

Las agregaciones no restringidas a nivel de usuario se admiten de la misma manera que se admiten en el modo de verificación de diferencias. El ruido solo se inyecta en agregaciones que combinan datos de varios usuarios. Las agregaciones que agrupan explícitamente por user_id o funciones analíticas que particionan por user_id, no reciben ruido y se permiten cualquier función. Las agregaciones a nivel de usuario que no agrupan de forma explícita por user_id, por ejemplo, GROUP BY impression_id, se tratan como agregaciones entre usuarios, por lo que se agrega ruido.

La agrupación por external_cookie no es suficiente. Si bien external_cookie se puede usar para unir tablas *_match con tablas propiedad del cliente, cualquier agregación de un solo usuario debe agruparse de forma explícita por columna user_id, no solo por la columna external_cookie.

Ejemplo de función de agregación:

WITH user_paths AS (
  # Grouping by user_id, no noise needed, all functions allowed
  SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;

Ejemplo de función analítica:

WITH events AS (
  # Partitioning by user_id, no noise needed, all functions allowed
  SELECT
    campaign_id,
    ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
  FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;

Agregaciones paralelas

Cada agregación de varios usuarios recibe el ruido de forma independiente. Puedes ejecutar varias de estas agregaciones en una sola declaración y combinar los resultados en una tabla con JOIN o UNION.

Ejemplo:

WITH result_1 AS (
  # Noise applied here to num_impressions
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
  GROUP BY 1
), result_2 AS (
  # Noise applied here to num_clicks
  SELECT campaign_id, COUNT(*) AS num_clicks
  FROM adh.google_ads_clicks
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

Ten en cuenta que esto se admitiría, pero se debe evitar en el modo de verificación de diferencias. Esta práctica no representa un problema de ruido, ya que cada agregación paralela recibe ruido y filtra de forma independiente.

Datos agregados unidos con datos no agregados

Dado que el Centro de Datos de Anuncios solo admite ventanas analíticas que particionan por user_id, una solución común es agregar estos resultados por separado y unirlos de forma automática antes de volver a agregarse. Estas consultas son compatibles con el modo de ruido y, a menudo, funcionan mejor de lo que obtendrían en el modo de verificación de diferencias debido a que los requisitos de privacidad se resolvieron antes.

Ejemplo:

WITH campaign_totals AS (
  # Noise applied here to campaign_imps
  SELECT campaign_id, COUNT(*) AS campaign_imps
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3

El modo de ruido prohíbe la reagregación de resultados agregados, como AVG(campaign_imps).

Patrones de consulta no admitidos

En esta sección, se describen los patrones de consulta que no son compatibles cuando se ejecutan consultas con inyección de ruido.

Consultas actuales

Las consultas del modo de ruido no admiten la consulta de los datos del día actual. (No se recomendada usar el modo de verificación de diferencias). No se puede seleccionar la fecha actual para las consultas que usan la inyección de ruido.

Resultados repetidos

En el modo con ruido, el Centro de Datos de Anuncios limita la frecuencia con la que puedes repetir la misma agregación. Si alcanzas estos límites, tus consultas del modo ruidoso perderán el acceso a las fechas consultadas con frecuencia en el conjunto de datos. Los siguientes son ejemplos de cómo puede ocurrir esto.

La repetición de consultas ocurre cuando la misma consulta se ejecuta varias veces con los mismos parámetros o parámetros muy similares, como períodos superpuestos. Puedes evitar esto si usas datos que ya se exportaron a tu proyecto de BigQuery.

Ten en cuenta que si dos trabajos consultan períodos superpuestos, podrían generar repeticiones si se realiza el mismo procesamiento para los mismos usuarios. Por ejemplo, la siguiente consulta, que se ejecuta en períodos superpuestos, crea repeticiones porque particiona por fecha:

SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1

En este caso, debes ejecutar la consulta en segmentos de fechas inconexos.

Otro ejemplo de repetición ocurre cuando los datos son de alguna manera independientes de la fecha. La siguiente consulta produce repeticiones cuando se ejecuta en fechas superpuestas, en las que ambos trabajos abarcan toda la vida útil de una campaña:

SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1

En este caso, debes ejecutar esta consulta solo una vez, ya que el resultado no cambia.

La repetición de agregación ocurre cuando la misma agregación se repite varias veces dentro de una consulta:

SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table

En este caso, debes quitar una de las repeticiones.

Ten en cuenta que, incluso si las agregaciones son sintácticamente diferentes, pero calculan el mismo valor, se contarían como una repetición. En otras palabras, si los valores de condition1 y condition2 son iguales para todos los usuarios con algún valor de key, la siguiente consulta tendría una repetición:

SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key

Si tienes condiciones que son muy similares para algunos grupos de usuarios, puedes considerar volver a escribir la consulta para que tenga solo un COUNT.

La duplicación de filas ocurre cuando una tabla del Centro de Datos de Anuncios se une a una tabla de BigQuery de modo que cada fila de la tabla del Centro de Datos de Anuncios coincida con varias filas en la tabla de BigQuery. Por ejemplo, la siguiente consulta produce una repetición si hay varias filas con el mismo ID de campaña en bq_table:

SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id

En este caso, debes reestructurar la consulta de modo que bq_table tenga solo una fila por valor de clave de unión (en este caso, campaign_id).

Ten en cuenta que desanidar un array de la tabla del Centro de Datos de Anuncios podría tener el mismo efecto si la mayoría de los usuarios tienen los mismos arrays de valores:

SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1

Obtén más información sobre otras prácticas recomendadas para las consultas.

Agregación directa

El ruido se aplica a la primera capa de agregación entre usuarios en la consulta. Se bloquean las consultas con varias capas de agregación:

WITH layer_1 AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

Para obtener los mejores resultados del ruido, calcula todas las operaciones entre usuarios dentro de una sola agregación. Por ejemplo, toma un SUM de eventos en lugar de un SUM de recuentos intermedios. Es posible reescribir una consulta para volver a agregar las agregaciones con ruido, pero las agregaciones finales pueden tener mucho más ruido.

Si esto no se puede evitar, puedes reescribir tu consulta para exportar los resultados directamente desde la primera capa. Para hacer esto dentro de un solo trabajo sin cambiar los resultados de la secuencia de comandos, crea una tabla temporal (o una tabla exportada a tu proyecto de BigQuery) con la sintaxis OPTIONS(privacy_checked_export=true). Por ejemplo:

CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

Obtén más información sobre las tablas temporales.

Si la primera capa de agregación es demasiado detallada para las verificaciones de privacidad, considera volver a escribir la consulta con agregados a nivel de usuario. Si esto no es posible, entonces esta consulta no es compatible con el modo con ruido.

IDs de usuarios no unidos

Las consultas en modo con ruido no deben combinar datos de usuarios separados en una sola fila, excepto cuando se realiza una agregación con ruido. Como resultado, es necesario que las uniones de los datos del Centro de Datos de Anuncios no agregados se unan de forma explícita en la columna user_id.

Esta consulta no se une de forma explícita en la columna user_id, lo que genera un error de validación:

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_id)

Esto se puede solucionar si ajustas la cláusula USING para incluir user_id de forma explícita, por ejemplo, USING(impression_id, user_id).

Ten en cuenta que esta limitación solo se aplica a las uniones entre tablas del Centro de Datos de Anuncios (excepto las tablas de dimensiones). No se aplica a las tablas que pertenecen al cliente. Por ejemplo, se permite lo siguiente:

SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

Uniones de BigQuery y el Centro de Datos de Anuncios

Las agregaciones con ruido requieren que los identificadores de usuario tengan un buen rendimiento. Los datos del cliente en BigQuery no tienen identificadores de usuario, por lo que no se pueden unir en una agregación de ruido sin unirse a una tabla del Centro de Datos de Anuncios.

Esta consulta genera un error de validación:

SELECT COUNT(*) FROM (
  SELECT 1 FROM adh.google_ads_impressions
  UNION ALL
  SELECT 1 FROM bigquery_project.dataset.table
)

Para solucionar este problema, debes unir la tabla de BigQuery a fin de aumentar los datos del Centro de Datos de Anuncios en lugar de unirlos, o bien separar los datos para agregar cada fuente por separado.

Ten en cuenta que está bien unir varias tablas del Centro de Datos de Anuncios con datos del usuario o varias tablas de BigQuery que son propiedad del cliente, pero no puedes combinar ambas.

Unión a la derecha de BigQuery Data Hub

Las uniones externas con datos que son propiedad del cliente pueden generar filas en las que falten identificadores de usuario, lo que evita que el ruido funcione bien.

Ambas consultas generan errores de validación porque permiten filas sin coincidencias e identificadores de usuario faltantes en el Centro de Datos de Anuncios:

SELECT …
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)

Ten en cuenta que cualquier combinación funcionaría si se invierte el orden de las tablas.

Resumen de filas filtradas

La especificación de resumen de filas filtradas no se admite en el modo ruido. A menudo, esta función no es necesaria con el ruido debido a las tasas de filtrado más bajas y la falta de filtrado en las verificaciones de diferencias.

Si observas un filtrado de datos significativo en un resultado de ruido, aumenta los datos agregados. Puedes realizar una agregación paralela en el conjunto de datos completo para comparar una estimación del total, por ejemplo:

SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1

Ten en cuenta que el recuento total tiene ruido de forma independiente y es posible que los valores totales no sumen, pero que el recuento total suele ser más preciso que tomar la suma de las filas con ruido.

Tablas creadas en modo cruzado

Las tablas no exportadas del Centro de Datos de Anuncios solo se pueden usar con el mismo modo de privacidad en el que se crearon. No puedes crear una tabla en modo de agregación normal y usarla en modo ruido, ni viceversa (a menos que esa tabla se exporte a BigQuery primero).