Inyección de ruido

Inyección de ruido es una técnica que se usa para proteger la privacidad del usuario cuando se envía una consulta a una base de datos. Para ello, añade ruido aleatorio a una cláusula SELECT de agregación de una consulta. Ese ruido protege la privacidad del usuario a la vez que proporciona resultados razonablemente precisos sin tener que hacer comprobaciones de diferencias y reduciendo el umbral de agregación necesario. La mayoría de las consultas se pueden ejecutar en modo de ruido, pero con determinadas limitaciones.

Ventajas de usar Inyección de ruido

No se aplican comprobaciones de diferencias: al ejecutar consultas con Inyección de ruido, el Centro de Datos de Anuncios no filtra filas debido a la similitud con conjuntos anteriores. Así, puedes obtener una vista integral de los datos a la vez que se protege la privacidad del usuario.

Se simplifica la solución de problemas: solo se omiten filas cuando la agregación lo requiere para que sea más fácil solucionar problemas y adaptar las consultas.

No tienes que aprender más sintaxis: no hace falta que te aprendas la sintaxis de nuevas consultas ni que tengas muchos conocimientos sobre privacidad para usar ruido en lugar de comprobaciones de diferencias.

La precisión de los datos está clara: cuando una tarea sale bien, se ve el porcentaje total de datos con la cantidad esperada de ruido.

Cómo influye el ruido en los requisitos de privacidad

Comprobaciones de diferencias: Inyección de ruido no depende de las comprobaciones de diferencias del Centro de Datos de Anuncios. Cuando usas Inyección de ruido, se inhabilitan las comprobaciones de diferencias.

Requisito de agregación: Inyección de ruido devuelve datos de impresiones representados aproximadamente por 20 usuarios únicos o más, y datos de clics y de conversión representados aproximadamente por 10 usuarios únicos o más.

Comprobaciones estáticas: no tienen ningún impacto.

Presupuestos y límites de consultas: las consultas que se ejecutan con ruido comparten el presupuesto de acceso a datos que se usa con las comprobaciones de diferencias. Al igual que ocurre con las comprobaciones de diferencias, si ejecutas la misma consulta en el mismo conjunto de datos muchas veces, podrías perder acceso a las fechas consultadas frecuentemente en el conjunto de datos. Esto puede ocurrir si ejecutas consultas como ventanas deslizantes o si envías la misma solicitud varias veces.

El modo de ruido impone límites adicionales más estrictos en el recálculo de los mismos resultados agregados de distintas consultas o entre ellas. Al igual que con el presupuesto de acceso a datos, puedes perder el acceso a las fechas consultadas frecuentemente en el conjunto de datos. Sin embargo, las limitaciones debidas al recálculo de los mismos resultados agregados solo restringirán las consultas en modo de ruido, no las consultas en modo de comprobación de diferencias. Encontrarás más información en la sección Resultados repetidos.

Más información sobre las comprobaciones de privacidad

Cómo influye Inyección de ruido en los resultados

El Centro de Datos de Anuncios inyecta ruido para reducir el riesgo de que se revelen datos y alguien pueda obtener información sobre un usuario concreto. Así equilibra privacidad y utilidad.

Inyección de ruido del Centro de Datos de Anuncios transforma los resultados de las consultas de la siguiente forma:

Limita las contribuciones de usuarios atípicos en resultados agregados. Suma la contribución de cada usuario en cada agregación y luego limita la contribución con un umbral de contención mínimo y máximo.
Agrega las contribuciones limitadas por usuario.
Añade más ruido a cada resultado agregado, que es el resultado de cada llamada de función de agregación en cada fila. La escala de este ruido aleatorio es proporcional a los umbrales de contención.
Calcula el recuento de usuarios con ruido por cada fila y elimina las filas que tienen muy pocos usuarios. Esto es similar a la k-anonimidad en modo de comprobación de diferencias, pero debido al ruido, las tareas que se ejecuten en el mismo conjunto de datos pueden dejar fuera filas distintas. Además, el modo de ruido deja fuera menos filas porque el requisito de agregación es inferior (aproximadamente 20, en comparación con 50).

El resultado final es un conjunto de datos en el que cada fila tiene resultados agregados con ruido y del que se han eliminado los grupos pequeños. Así, se enmascara el efecto de un usuario único en los resultados.

Acerca de la limitación de la agregación

Inyección de ruido del Centro de Datos de Anuncio contiene la agregación de forma implícita o explícita para limitar la contribución de usuarios atípicos. En función de cada caso práctico, puedes elegir el tipo de limitación.

Limitación implícita

En la limitación implícita, los límites se determinan automáticamente sin tener que usar ningún tipo de sintaxis de SQL especial. Si una fila tiene un intervalo de valores más amplio que otra, la limitación implícita aplica diferentes límites a esas filas. De esta forma, se suele reducir el margen de error de cada resultado. En cambio, como cada agregación tiene distintos límites de contención y niveles de ruido, puede ser difícil compararlas.

La limitación implícita puede fallar si una agregación recibe datos de muy pocos usuarios, por ejemplo, en una llamada COUNTIF() con una condición poco común. En estos casos, se devuelven resultados NULL. También, COUNT(DISTINCT user_id) usa automáticamente la limitación implícita con los límites 0 y 1.

Limitación explícita

La limitación explícita contiene el total de la contribución de cada usuario al intervalo especificado. Los límites explícitos se aplican de manera uniforme a todas las filas y deben ser valores literales. Aunque algunas filas tengan un intervalo de contribuciones por usuario más amplio que otras, se aplican los mismos límites a todas. Esto hace que sea más fácil comparar filas distintas, aunque algunas tengan más ruido del que recibirían con la limitación implícita.

La limitación explícita aplica la mitad de ruido que la implícita a un conjunto determinado de límites de contención. Por lo tanto, si puedes estimar límites razonables, obtendrás mejores resultados si los indicas explícitamente.

Para usar la limitación explícita, define los límites de cada función de agregación disponible añadiendo números enteros que representen los límites mínimo y máximo. 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

Ejecutar una consulta con Inyección de ruido

Escribe una consulta o abre una que ya tengas. Para ver qué funciones de agregación puedes usar, consulta las funciones admitidas.
En Editor de consultas, haz clic en Ejecutar para añadir los detalles de una nueva tarea.
Haz clic en el interruptor Configuración de privacidad para que esté en la posición Usar ruido.
Ejecuta la consulta.
Revisa el ruido añadido.
Si quieres, adapta la consulta para reducir el impacto del ruido.

Revisar el impacto del ruido

Una vez que se completa correctamente una consulta, el Centro de Datos de Anuncios muestra la fiabilidad del resultado basándose en el número de celdas de la salida que tienen la cantidad esperada de ruido. Se considera que un valor de la tabla de resultados se ha visto muy influido si la escala de ruido añadido es más del 5 % del resultado de la celda. Consulta los intervalos de impacto en la tabla siguiente.

En los conjuntos de datos de salida, la tabla de detalles indica las 10 columnas con más ruido, ordenándolas poniendo la que más impacto tiene arriba y con su correspondiente contribución al ruido. A continuación, se incluye un desglose de la cantidad de ruido esperada.

Datos con la cantidad de ruido esperada	Color del indicador	Impacto
>95 %	Verde	Impacto bajo
85 %-95 %	Amarillo	Impacto medio
75 %-85 %	Naranja	Impacto alto
<75 %	Rojo	Impacto muy alto

Para ver información detallada sobre el impacto del ruido, sigue estos pasos:

Haz clic en Informes.
Selecciona un informe de la lista. La descripción emergente con el resumen de privacidad indica el porcentaje de resultados que tienen la cantidad esperada de ruido, lo cual se corresponde con la cantidad de ruido añadida que es superior al 5 % del resultado.
Para ver más información, haz clic en Tareas > Detalles.
Consulta la sección Mensajes de privacidad en los detalles de la tarea. Los resultados encajan en una de las categorías que se enumeran.
Si es necesario, ajusta la consulta para mejorar el resultado.

Adaptar consultas

Es más probable que los resultados agregados tengan una cantidad de ruido inesperada si pocos usuarios contribuyen a esos resultados. Esto puede ocurrir cuando las filas tienen pocos usuarios o si algunos usuarios no influyen en los resultados; por ejemplo, cuando se usa la función COUNTIF. En función de los detalles sobre el ruido, puedes ajustar la consulta para aumentar el porcentaje de datos con la cantidad esperada de ruido.

A continuación se incluyen algunas directrices generales:

Amplía el intervalo de fechas.
Reescribe la consulta para reducir la granularidad de los datos; por ejemplo, usando menos parámetros de agrupación o sustituyendo COUNTIF por COUNT.
Retira las columnas con mucho ruido.
Usa la limitación explícita.

Funciones de agregación admitidas

Se pueden usar con ruido las siguientes funciones de agregación:

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

La palabra clave DISTINCT solo se puede usar con la función COUNT, y únicamente con una referencia directa a la columna user_id de una tabla del Centro de Datos de Anuncios o una expresión que devuelva user_id o NULL, como COUNT(DISTINCT IF(..., user_id, NULL)).

Las siguientes funciones no se admiten directamente, pero se pueden sustituir por otras agregadas con ruido para obtener resultados estadísticos. Ten en cuenta que los valores numéricos son solo ejemplos.

LOGICAL_OR(...). Sugerencia de sustitución: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
LOGICAL_AND(...). Sugerencia de sustitución: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

Acerca de los resultados enteros

Aunque el Centro de Datos de Anuncios inyecta ruido automáticamente con estas funciones de agregación, sus firmas no cambian. Como hay funciones como COUNT o SUM de INT64 que devuelven INT64, los decimales de los resultados con ruido se redondean. En general, esto no es significativo en relación con el tamaño de los resultados y el ruido.

Si necesitas la granularidad de los decimales en el resultado, no escribas funciones que devuelvan INT64. Por ejemplo, puedes usar SUM con la entrada convertida a FLOAT64.

Patrones de consulta admitidos

Importante: La mayoría de las prácticas recomendadas estándar del Centro de Datos de Anuncios se aplican a las consultas que usan Inyección de ruido. En concreto, te recomendamos que consultes las instrucciones para consultar de forma repetida los mismos datos.

En esta sección se describen los patrones de consulta que se pueden usar al ejecutar consultas con Inyección de ruido.

Agregaciones a nivel de usuario

Se admiten agregaciones a nivel de usuario sin restricciones del mismo modo que en el modo de comprobación de diferencias. Solo se inyecta ruido en agregaciones que combinan datos de varios usuarios. Las agregaciones que agrupan los datos por user_id de forma explícita o las funciones analíticas que los dividen por user_id no reciben ruido y, por tanto, se admite cualquier función. Las agregaciones a nivel de usuario que no agrupan los datos por user_id de forma explícita, como GROUP BY impression_id, se tratan como agregaciones de varios usuarios y, por tanto, se añade ruido.

Agrupar por external_cookie no es suficiente. Si bien external_cookie se puede usar para unir tablas *_match tables con tablas propiedad del cliente, las agregaciones de un solo usuario deben agrupar explícitamente por la columna user_id column, 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

Las agregaciones de varios usuarios siempre reciben ruido. Puedes ejecutar diferentes agregaciones de este tipo en una misma instrucción, combinando los resultados en una tabla con JOIN or 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)

Aunque es una práctica permitida, debe evitarse en el modo de comprobación de diferencias. Esto no supone un problema cuando hay ruido, ya que cada agregación paralela recibe ruido y se filtra de forma independiente.

Datos agregados combinados con datos no agregados

Como el Centro de Datos de Anuncios solo admite ventanas analíticas que dividen los datos por user_id, es habitual agregar esos resultados por separado y luego autocombinarlos para volver a agregarlos. Estas consultas se admiten en el modo de ruido y a menudo funcionan mejor que en el modo de comprobación de diferencias porque los requisitos de privacidad se resuelven 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 no permite volver a agregar resultados agregados, como AVG(campaign_imps).

Patrones de consulta no admitidos

En esta sección se describen los patrones de consulta que no se pueden usar al ejecutar consultas con Inyección de ruido.

Consultas con datos del día

Las los datos del día en curso no se pueden consultar en modo de ruido (y se desaconseja hacerlo en modo de comprobación de diferencias). No se puede seleccionar la fecha actual en consultas que usan Inyección de ruido.

Resultados repetidos

En el modo de ruido, el Centro de Datos de Anuncios limita la frecuencia con la que puedes repetir una misma agregación. Si alcanzas esos límites, tus consultas en modo de ruido perderán el acceso a las fechas consultadas frecuentemente en el conjunto de datos. A continuación, encontrarás ejemplos de cómo puede ocurrir esto.

La repetición de consultas se da cuando se ejecuta varias veces la misma consulta con los mismos parámetros o parámetros muy parecidos, como intervalos de fechas que se solapan. Puedes evitarlo usando datos que ya se hayan exportado a tu proyecto de BigQuery.

Ten en cuenta que, al consultar en dos tareas intervalos de fechas que se solapen, podrían producirse repeticiones si se hace el mismo cálculo con los mismos usuarios. Por ejemplo, la siguiente consulta ejecutada en intervalos de fechas que se solapan crea repeticiones porque divide los datos 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 conjuntos de datos independientes.

Otro ejemplo de repetición se da cuando los datos son un tanto independientes de la fecha. La siguiente consulta produce repeticiones cuando se ejecuta con fechas solapadas, ya que ambas tareas cubren toda la duración de una campaña:

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

En este caso, debes ejecutar la consulta una sola vez, ya que el resultado no varía.

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

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

En este caso, debes quitar una de las repeticiones.

Ten en cuenta que, si las agregaciones calculan el mismo valor incluso con una sintaxis distinta, se considera una repetición. En otras palabras, si los valores de condition1 y condition2 son iguales para todos los usuarios con valor de key, se considera que la siguiente consulta genera una repetición:

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

Si tienes condiciones muy parecidas en determinados grupos de usuarios, te recomendamos reescribir la consulta para que solo tenga un valor COUNT.

Los duplicados de filas se dan cuando una tabla del Centro de Datos de Anuncios se une con una tabla de BigQuery de forma que cada fila de la tabla del Centro de Datos de Anuncios se corresponda con varias filas de la tabla de BigQuery. Por ejemplo, en la siguiente consulta se da 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 para que bq_table solo tenga una fila por valor de clave de unión (concretamente, campaign_id).

Ten en cuenta que desanidar un array de la tabla del Centro de Datos de Anuncios podría tener la misma consecuencia 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

Consulta otras prácticas recomendadas para ejecutar consultas.

Reagregación directa

El ruido se aplica a la primera capa de la agregación de varios usuarios en una consulta. Las consultas con varias capas de agregación se bloquean:

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 posibles del ruido, calcula todas las operaciones de varios usuarios con una única agregación. Por ejemplo, usa SUM de eventos en lugar de utilizar SUM de recuentos intermedios. También puedes reformular una consulta para reagregar datos agregados con ruido, pero los datos agregados finales podrían tener mucho más ruido.

Si es inevitable, puedes reformular la consulta para que, en su lugar, se exporten los resultados directamente desde la primera capa. Para hacerlo en una sola tarea 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

Más información sobre las tablas temporales

Si la primera capa de agregación es demasiado granular para las comprobaciones de privacidad, reformula la consulta con datos agregados a nivel de usuario. Si no se puede, es porque esta consulta no admite el modo de ruido.

IDs de usuario no combinados

En el modo de ruido, las consultas no pueden combinar datos de diferentes usuarios en una misma fila, excepto al ejecutar una agregación con ruido. Por eso, las combinaciones de datos del Centro de Datos de Anuncios sin agregar deben unirse de forma explícita en la columna user_id.

Esta consulta no une los datos de forma explícita en la columna user_id, lo que da lugar a un error de validación.

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

Para solucionarlo, se puede ajustar la cláusula USING para incluir user_id de forma explícita, como en USING(impression_id, user_id).

Ten en cuenta que esta limitación solo se aplica a las combinaciones entre tablas del Centro de Datos de anuncios (excepto tablas de dimensiones) y no a tablas que sean propiedad de los clientes. Por ejemplo, se permite lo siguiente:

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

Uniones entre el Centro de Datos de Anuncios y BigQuery

En las agregaciones con ruido, los identificadores de usuario deben funcionar bien. En BigQuery, los datos propiedad del cliente no tienen identificadores de usuario, por lo que no se pueden combinar con una agregación con ruido sin unirlos a una tabla del Centro de Datos de Anuncios.

Esta consulta devuelve 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 solucionarlo, debes combinar la tabla de BigQuery para ampliar los datos del Centro de Datos de Anuncios, o bien separar los datos para agregar cada fuente de manera independiente.

Aunque se puede crear una unión entre varias tablas del Centro de Datos de Anuncios con datos de usuario o entre varias tablas de BigQuery propiedad del cliente, no puedes mezclar ambas.

Uniones correctas entre el Centro de Datos de Anuncios y BigQuery

Las uniones externas con datos propiedad del cliente pueden dar lugar a filas en las que falten identificadores de usuario, lo que haría que el ruido no funcionara bien.

Estas dos consultas devolverían errores de validación porque admiten filas sin identificadores de usuario 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 cualquiera de estas uniones funcionaría si se invirtiera el orden de las tablas.

Resumen de filas excluidas

El resumen de filas excluidas no se admite en el modo de ruido. En general, esta función es innecesaria cuando hay ruido debido a las bajas tasas de exclusión y a la falta de exclusión de las comprobaciones de diferencias.

Si observas que se excluyen cantidades significativas de datos en un resultado con ruido, puedes aumentar los datos agregados. Puedes ejecutar 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 recibe ruido de forma independiente y que la suma de los valores totales podría no corresponderse, pero el recuento total suele ser más preciso que la suma de las filas con ruido.

Tablas creadas en diferentes modos

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