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, se 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 búsquedas existentes se pueden ejecutar en modo de ruido, con algunas limitaciones.

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

Descubre los beneficios de usar la inyección de ruido

No se aplican verificaciones de diferencias: Cuando se ejecutan consultas con inyección de ruido, Ads Data Hub no filtra las filas debido a la 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.

Se simplifica la solución de problemas: Las filas solo se omiten debido a los requisitos de agregación, lo que simplifica 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 conocer los conceptos de privacidad para usar el ruido en lugar de las verificaciones de diferencias.

La exactitud de los resultados es clara: Un trabajo exitoso muestra el porcentaje total de datos con la cantidad esperada de ruido.

Obtén más información sobre 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 Ads Data Hub. Cuando usas la inyección de ruido, se inhabilitan las verificaciones de diferencias.

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

Verificaciones estáticas: No hay impacto.

Presupuestos y límites de consultas: Las consultas ejecutadas 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 muchas 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 ventana deslizante 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, pero las limitaciones debidas al nuevo cálculo 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 inyección de ruido afecta los resultados

El Centro de datos de anuncios inyecta 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 y la utilidad.

La inserción de ruido en Ads Data Hub transforma los resultados de la consulta de la siguiente manera:

• Ajusta 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 de ajuste 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 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, los trabajos que se ejecutan en el mismo conjunto de datos pueden descartar diferentes filas. Además, el modo de ruido descarta menos filas porque el requisito de agregación es menor (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 devueltos.

Acerca de la fijación de la agregación

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

Fijación implícita

En el ajuste implícito, los límites se determinan automáticamente. No necesitas ninguna sintaxis de SQL especial para usar el ajuste 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 ajuste y niveles de ruido, lo que puede dificultar su comparación.

El ajuste implícito puede fallar cuando una agregación obtiene datos de muy pocos usuarios, por ejemplo, una llamada COUNTIF() con una condición poco común. En estos casos, se devuelven resultados de NULL. También ten en cuenta que COUNT(DISTINCT user_id) usa automáticamente el ajuste explícito con límites de 0 y 1.

Restricción explícita

La fijación explícita fija 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 reciben más ruido del que podrían recibir con el ajuste implícito.

La restricción explícita usa la mitad de ruido que la restricción 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 estableces de forma explícita.

Para usar la restricción explícita, establece los límites para cada función agregada admitida agregando números enteros que representen el límite inferior y el límite 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 inyección de ruido

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

Revisa el impacto del ruido

Una vez que el trabajo se completa correctamente, el Centro de Datos de Anuncios 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. Se considera que un valor de la tabla de resultados se ve 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, de mayor a menor impacto, y su contribución correspondiente al ruido. Esta es la distribución de la cantidad de ruido esperada.

Resultados con más del 5% de ruido	Color del indicador	Impacto
<5%	Verde	Impacto bajo
5%-15%	Amarillo	Impacto medio
15%-25%	Orange	Alto impacto
Más del 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 puntero sobre el ícono de sugerencia de privacidad privacy_tip en la tarjeta de trabajo, en Actividad reciente.

Adaptar las búsquedas

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

A continuación, se indican algunos lineamientos generales:

• Expande el período.
• Vuelve a escribir la consulta para reducir la granularidad 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

Se admiten las siguientes funciones de agregación con 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 muestre user_id o NULL, como COUNT(DISTINCT IF(..., user_id, NULL)).

Acerca de los resultados de números enteros

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

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

Acerca de los resultados negativos

En principio, el ruido con valores muy pequeños puede generar números negativos, incluso cuando esto debería ser semánticamente imposible para la búsqueda. Para mantener el comportamiento esperado, todas las formas de COUNT y COUNTIF se ajustan automáticamente en cero, por lo que nunca arrojan resultados negativos. Si deseas este mismo comportamiento con otra función, como SUM, puedes ajustar los resultados manualmente con GREATEST(0, SUM(...)).

Por lo general, este cambio es insignificante, pero introduce un pequeño sesgo positivo en los resultados generales. Si necesitas evitar esto, considera usar ADH.ANON_COUNT en lugar de COUNT, o bien GROUP BY ROLLUP para calcular los recuentos totales en las filas.

---

Patrones de búsqueda admitidos

Importante: La mayoría de las prácticas recomendadas estándar de Ads Data Hub siguen siendo válidas para 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 repetida.

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

Agregados a nivel del usuario

Los agregados 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 explícitamente por user_id o las funciones analíticas que particionan por user_id no reciben ruido, y se permite cualquier función. Los agregados a nivel del usuario que no se agrupan de forma explícita por user_id (por ejemplo, GROUP BY impression_id) se tratan como agregados entre usuarios, por lo que se agrega ruido.

No basta con agrupar por external_cookie. 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 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;

Agregados paralelos

Cada agregación entre usuarios recibe ruido de forma independiente. Puedes ejecutar varias de estas agregaciones en una sola instrucción y combinar los resultados en una tabla con un JOIN o un 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 sería compatible, pero se debe evitar en el modo de verificación de diferencias. Esta práctica no genera problemas de ruido, ya que cada agregado paralelo se filtra y se le agrega ruido 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, los valores sumados de imps para un campaign_id determinado pueden no coincidir 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 antes de volver a agregarlos. Estas búsquedas se admiten en 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 desalienta la reagregación de resultados agregados, como AVG(campaign_imps).

---

Patrones de búsqueda no admitidos

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

Búsquedas que incluyen el día de hoy

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

Resultados repetidos

En el modo de ruido, Ads Data Hub limita la frecuencia con la que puedes repetir la misma agregación. Si alcanzas estos límites, tus búsquedas en el 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 se produce cuando se ejecuta la misma consulta varias veces con los mismos parámetros o parámetros muy similares, como rangos 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 rangos de fechas superpuestos, es posible que produzcan repeticiones si realizan el mismo cálculo en los mismos usuarios. Por ejemplo, la siguiente consulta, ejecutada en rangos de fechas superpuestos, crea repeticiones porque realiza la partición 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 algo independientes de la fecha. La siguiente consulta produce repeticiones cuando se ejecuta en fechas superpuestas, en las que ambos trabajos abarcan todo el ciclo de vida 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 la agregación se produce 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 considerará 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, puedes considerar volver a escribir la consulta para que solo tenga un COUNT.

La duplicación de filas ocurre cuando una tabla del Centro de Datos de Anuncios se une con una tabla de BigQuery de tal manera que cada fila de la tabla del Centro de Datos de Anuncios coincide 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 anular el anidamiento de un array de la tabla de Ads Data Hub 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 más información sobre otras prácticas recomendadas para las búsquedas.

Reagregación directa

Se aplica ruido a la primera capa de agregación entre usuarios en la consulta. Las consultas con varias capas de agregación combinarán resultados ruidosos, por lo que los agregados finales pueden tener mucho más ruido. Estas búsquedas reciben una advertencia en la validació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 en una sola agregación. Por ejemplo, toma una SUM de eventos en lugar de una SUM de recuentos intermedios.

Si la agregación de varias capas es inevitable, puedes resolver la advertencia exportando los resultados directamente desde la primera capa. Para ello, crea una tabla temporal (o una tabla exportada a tu proyecto de BigQuery) con la sintaxis OPTIONS(privacy_checked_export=true) en un solo trabajo sin cambiar los resultados de la secuencia de comandos. 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 el primer nivel de agregación es demasiado detallado para las verificaciones de privacidad, considera volver a escribir la consulta con agregados a nivel del usuario. Si esto no es posible, la búsqueda no se admite en 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 no agregados de Ads Data Hub deben unirse de forma explícita en la columna user_id.

Esta consulta no realiza una unión explícita en la columna user_id, lo que genera una advertencia de validación:

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

Es posible que las uniones como esta no se comporten como se espera, ya que solo coincidirán las filas con el mismo valor de user_id. Esto se puede corregir ajustando la cláusula USING para incluir explícitamente user_id, por ejemplo, USING(impression_id, user_id).

Ten en cuenta que esta limitación solo se aplica a las uniones entre tablas de Ads Data Hub (con la excepción de las tablas de dimensiones). No se aplica a las tablas propiedad del cliente. Por ejemplo, se permite lo siguiente:

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

Combinaciones externas a la derecha de BigQuery y el Centro de Datos de Anuncios

Las combinaciones externas con datos propiedad del cliente pueden generar filas con identificadores de usuario faltantes, lo que impide que el ruido funcione bien.

Ambas consultas generan advertencias de validación porque permiten filas no coincidentes 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. También hay una excepción para las tablas de RDID que se unen directamente en device_id_md5. Por ejemplo, la siguiente consulta funcionará sin advertencias:

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)

Resumen de filas filtradas

La especificación del resumen de filas filtradas no se admite en el modo de ruido. Esta función suele ser innecesaria con el ruido debido a las tasas de filtrado más bajas y a 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 paralela en todo el conjunto de datos 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 se ajusta de forma independiente y que los valores totales pueden no coincidir, pero el recuento total suele ser más preciso que la suma de las filas ajustadas.

Tablas creadas en varios modos

Las tablas no exportadas 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, ni viceversa (a menos que primero se exporte esa tabla a BigQuery).