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. Para ello, agrega ruido aleatorio a una cláusula SELECT de agregación de una consulta. Este ruido protege la privacidad del usuario y, al mismo tiempo, proporciona resultados razonablemente precisos, lo que elimina la necesidad de realizar verificaciones de diferencias y reduce el umbral de agregación requerido para el resultado. La mayoría de las consultas existentes se pueden ejecutar en modo de ruido, con algunas limitaciones.

Importante: La certificación de la MRC del Centro de Datos de Anuncios no se extiende a las consultas que se ejecutan en modo de ruido.

Conoce los beneficios de usar la inserción de ruido

No se aplican las verificaciones de diferencias: Cuando se ejecutan consultas con inserción de ruido, el Centro de Datos de Anuncios no filtra las filas debido a su similitud con los conjuntos de resultados anteriores. Esto significa que aún puedes obtener una vista integral de los datos y, al mismo tiempo, 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 sintaxis nueva que aprender: No necesitas aprender ninguna sintaxis de consulta nueva ni tener conocimientos sobre conceptos de privacidad para usar el ruido en lugar de las verificaciones de diferencia.

La exactitud de los resultados es clara: Una tarea exitosa 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 inserción de ruido no se basa en las verificaciones de diferencias existentes en el Ads Data Hub. Cuando usas la inyección de ruido, se inhabilitan las verificaciones de diferencias.

Requisito de agregación: La inserció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 ningún impacto.

Presupuestos y límites de consulta: Las consultas que se ejecutan con 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 varias veces, es posible que pierdas 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 para volver a calcular 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 la recompilación de los mismos resultados agregados solo restringirán las consultas en el 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 inserción de ruido afecta los resultados

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

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

• Limita las contribuciones de los 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 mínimos y máximos.
• Agrega las contribuciones restringidas por usuario.
• Agrega ruido a cada resultado agregado, 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 ajustados.
• Calcula un recuento de usuarios ruidoso para cada fila y elimina las filas con muy pocos usuarios. Esto es similar al k-anonimato en el modo de verificación de diferencias, pero debido al ruido, las tareas que se ejecutan en el mismo conjunto de datos pueden descartar filas diferentes. Además, el modo de ruido descarta menos filas porque el requisito de agregación es más bajo (aproximadamente 20 en comparación con exactamente 50).

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

Acerca de la limitación de agregación

La inserción de ruido en Ads Data Hub usa la limitación de agregación implícita o explícita para limitar la contribución de los valores atípicos. Puedes elegir qué tipo de sujeción usar, según tu caso de uso.

Fijación implícita

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

La limitació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 un recorte explícito con límites de 0 y 1.

Restricción explícita

La fijación explícita limita la contribución total de cada usuario a un rango especificado. Los límites explícitos se aplican de forma 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 ellas. Esto hace que los resultados de diferentes filas sean más comparables, aunque algunas filas tienen más ruido que con el recorte implícito.

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

Para usar la restricción explícita, agrega números enteros que representen el límite inferior y el límite superior para establecer los límites de cada función agregada compatible. 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 inserción de ruido

1. Abre un informe.
2. Haz clic en el botón de activación Configuración de ruido de privacidad para colocarlo en la posición Usar ruido.
3. Ejecuta la consulta.
4. Revisa el impacto del ruido agregado.
5. Opcional: Adapta la consulta para reducir el impacto del ruido.

Revisa el impacto del ruido

Una vez que el trabajo se completa correctamente, el Ads Data Hub muestra la confiabilidad del resultado en el resumen de privacidad. La confiabilidad se basa en el porcentaje de celdas del resultado que se ven muy afectadas por el ruido. 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.

En el caso de los conjuntos de datos de salida afectados, el resumen de privacidad enumera las diez columnas más ruidosas, del impacto más alto al más bajo, y su contribución correspondiente al ruido. Este es el desglose de la cantidad de ruido esperada.

Resultados con más del 5% de ruido	Color del indicador	Impacto
<5%	Verde	Impacto bajo
Entre el 5% y el 15%	Amarillo	Impacto medio
15%-25%	Orange	Alto impacto
>25%	Rojo	Impacto muy alto

También puedes obtener una vista previa del resumen de privacidad de los trabajos de informes recientes en la página Principal. Para obtener una vista previa de la privacidad de un trabajo en particular, mantén el cursor sobre el ícono de sugerencia de privacidad privacy_tip en la tarjeta del trabajo en Actividad reciente.

Adapta las consultas

Es más probable que los resultados agregados tengan una cantidad inesperada de ruido cuando pocos usuarios contribuyen a esos resultados. Esto puede ocurrir 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 del ruido, te recomendamos que ajustes tu consulta para aumentar el porcentaje de datos con la cantidad esperada de ruido.

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, agrupando por menos parámetros o reemplazando COUNTIF por COUNT.
• Quita las columnas con ruido.
• Usa la restricción explícita.

---

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 se admite con la función COUNT y solo cuando se usa con una referencia directa a la columna user_id de una tabla de Ads Data Hub o una expresión que muestra user_id o NULL, como COUNT(DISTINCT IF(..., user_id, NULL)).

Las siguientes funciones no son compatibles directamente, 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 cambiarán. Debido a que funciones como COUNT o SUM de INT64 muestran INT64, cualquier parte decimal del resultado con ruido se redondea. Por lo general, esto es despreciable en relación con el tamaño del resultado y el ruido.

Si necesitas el nivel de detalle del decimal en tu resultado, evita escribir funciones que devuelvan INT64, por ejemplo, usando SUM con su entrada convertida a FLOAT64.

---

Patrones de consulta admitidos

Importante: La mayoría de las prácticas recomendadas estándar de Ads Data Hub aún se aplican a las consultas que usan la inserción de ruido. En particular, te recomendamos que revises la guía sobre cómo consultar los mismos datos de forma reiterada.

En esta sección, se describen los patrones de consulta que se admiten cuando se ejecutan consultas con la inserción de ruido.

Totales a nivel del usuario

Las agregaciones sin restricciones a nivel del usuario se admiten de la misma manera que en el modo de verificación de diferencias. El ruido solo se inyecta en las agregaciones que combinan datos de varios usuarios. Las agregaciones que agrupan de forma explícita por user_id o las funciones analíticas que se particionan por user_id no reciben ningún ruido y se permite cualquier función. Las agregaciones a nivel del usuario que no se 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.

No es suficiente agrupar por external_cookie. Si bien external_cookie se puede usar para unir tablas *_match con tablas que pertenecen al cliente, cualquier agregación de un solo usuario debe agruparse de forma explícita por la 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;

Agrupaciones en paralelo

Cada agregación entre usuarios recibe ruido de forma independiente. Puedes ejecutar varias de estas agregaciones en una sola sentencia y combinar los resultados en una tabla con una 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 es un problema con el ruido, ya que cada agregado en paralelo se contamina y filtra de forma independiente.

Datos agregados unidos con datos no agregados

Nota: Cada agregación recibe ruido de forma independiente, por lo que es posible que los valores totales no coincidan. En este caso, es posible que los valores sumados de imps para un campaign_id en particular no coincidan con el valor correspondiente de campaign_imps.

Dado que el Centro de Datos de Anuncios solo admite ventanas de análisis que se particionan por user_id, una solución alternativa común es agregar estos resultados por separado y unirlos por sí mismos antes de volver a agregarlos. Estas consultas son compatibles con el modo de ruido y, a menudo, tienen un mejor rendimiento que en el modo de verificación de diferencias, ya que 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 prohíbe reagregar resultados agregados, como AVG(campaign_imps).

---

Patrones de consulta no admitidos

En esta sección, se describen los patrones de búsqueda que no se admiten cuando se ejecutan consultas con la inserción de ruido.

Consultas que incluyen el día de hoy

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

Resultados repetidos

En el modo de 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 de ruido perderán el acceso a las fechas consultadas con frecuencia en el conjunto de datos. A continuación, se muestran ejemplos de cómo puede ocurrir esto.

La repetición de consultas ocurre cuando se ejecuta la misma consulta varias veces con los mismos parámetros o parámetros muy similares, como intervalos de fechas superpuestos. Para evitar esto, usa los datos que ya se exportaron a tu proyecto de BigQuery.

Ten en cuenta que, si dos trabajos consultan períodos superpuestos, es posible que generen repeticiones si realizan el mismo procesamiento en los mismos usuarios. Por ejemplo, la siguiente consulta, ejecutada en períodos superpuestos, crea repeticiones porque se 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 disjuntos.

Otro ejemplo de repetición ocurre cuando los datos son independientes de la fecha. La siguiente consulta produce repeticiones cuando se ejecuta en fechas superpuestas, en las que ambas tareas 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 registrarían como una repetición. En otras palabras, si los valores de condition1 y condition2 son los mismos 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 muy similares para algunos grupos de usuarios, te recomendamos que reescribas 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 manera que cada fila de la tabla del Centro de Datos de Anuncios coincida con varias filas de 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 para que bq_table tenga solo una fila por valor de clave de unión (campaign_id, en este caso).

Ten en cuenta que desanidar un array de la tabla del Centro de Datos de Anuncios podría producir 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 información sobre otras prácticas recomendadas para las consultas.

Reagrupació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 agregados con ruido, pero los agregados finales pueden tener un ruido mucho más alto.

Si esto no se puede evitar, puedes reescribir la consulta para exportar los resultados directamente desde la primera capa. Para hacerlo en 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 reescribir la consulta con agrupaciones a nivel del usuario. Si esto no es posible, significa que esta consulta no es compatible con el modo de ruido.

IDs de usuario no unidos

Las consultas en modo de ruido no deben combinar datos de usuarios separados en una sola fila, excepto cuando se realiza una agregación con ruido. Como resultado, las uniones de datos del Centro de Datos de Anuncios no agregados deben unirse 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)

Para corregir este error, ajusta 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 combinaciones entre tablas de Google Ads Data Hub (con la excepción de 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 que pertenecen al cliente en BigQuery no tienen identificadores de usuario, por lo que no se pueden unir a una agregación de ruido sin unirse a una tabla de Ads Data Hub.

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 para aumentar los datos de Ads Data Hub 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 pertenecen al cliente, pero no puedes combinar ambas.

Uniones derechas de BigQuery y el Centro de Datos de Anuncios

Las uniones externas con datos que pertenecen al cliente pueden generar filas con identificadores de usuario faltantes, lo que impide que el ruido funcione bien.

Ambas consultas generan errores de validación porque permiten filas que no coinciden con 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 cualquiera de las uniones funcionaría si se invirtiera el orden de las tablas.

Resumen de filas filtradas

La especificación de resumen de filas filtradas no es compatible con el modo de ruido. Por lo general, esta función no es necesaria con ruido debido a las tasas de filtrado más bajas y la falta de filtrado de 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 en paralelo 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 independiente y es posible que los valores totales no se sumen, pero el recuento total suele ser más preciso que la suma de las filas con ruido.

Tablas creadas en modo mixto

Las tablas que no se exportaron en el 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 el modo de agregación normal y usarla en el modo de ruido, o viceversa (a menos que esa tabla se exporte primero a BigQuery).