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 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 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.

Se informa la precisión de los resultados: Un trabajo exitoso muestra el porcentaje total de datos que podrían haberse visto afectados por el 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 ocurrir 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 búsquedas 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 debido 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

Ads Data Hub 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ínimo y máximo.
• 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 lugar de 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 el Centro de Datos de Anuncios usa la fijación de agregación implícita o explícita 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

No necesitas ninguna sintaxis especial de SQL para usar el ajuste implícito, ya que se aplica de forma predeterminada. Los límites implícitos se derivan de los datos y se determinan para cada agregación. Si algunas agregaciones tienen un rango de valores más amplio que otras, el límite implícito puede inferir diferentes límites para diferentes agregaciones según corresponda. Por lo general, esto genera menos errores. Ten en cuenta que COUNT(DISTINCT user_id) usa automáticamente la fijación explícita con el límite superior de 1.

Fijació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 agregaciones y deben ser valores literales. La restricción explícita puede proporcionar mejores resultados cuando los límites se conocen de forma general. Por ejemplo, el límite de edades entre 0 y 100 refleja la información pública porque la edad de la mayoría de las personas suele estar dentro de este rango.

El Centro de Datos de Anuncios proporciona ADH.ANONfunciones de agregación complementarias para la reducción explícita. Para usar la restricción explícita, establece los límites para cada función de agregación 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 un 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 pueden verse muy afectadas por el ruido. Se considera que un valor de la tabla de resultados se ve 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 las etiquetas de impacto del ruido.

Porcentaje de resultados afectados	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 búsquedas

Es más probable que las agregaciones se vean afectadas por el ruido cuando pocos usuarios contribuyen al resultado. Esto puede ocurrir cuando las agregaciones se calculan a partir de conjuntos de usuarios pequeños o cuando algunos usuarios no afectan los resultados, lo que puede suceder, por ejemplo, con la función COUNTIF. Según el informe de ruido, es posible que quieras ajustar tu búsqueda para reducir el porcentaje de resultados afectados.

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.
• Prueba el ajuste explícito cuando se puedan elegir límites razonables.

---

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)).

Ten en cuenta que estas limitaciones solo se aplican a las agregaciones con ruido, que es el primer nivel de agregación entre usuarios. Los agregados a nivel del usuario y los agregados que siguen la inyección de ruido no están restringidos.

Funciones de agregación complementarias

Además de admitir agregadores regulares, Ads Data Hub introduce funciones de agregación ADH.ANON complementarias que admiten el ajuste explícito. Estos agregadores comparten la sintaxis con las funciones de agregación con privacidad diferencial de BigQuery, pero no requieren la cláusula WITH DIFFERENTIAL_PRIVACY:

• ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )

Parámetros ADH.ANON_SUM, ADH.ANON_COUNT y ADH.ANON_AVG:

• contribution_bounds_per_group: Las contribuciones por usuario se fijan para cada partición definida por las claves GROUP BY. Los límites inferior y superior se aplican a los valores por grupo después de que se agregan por usuario.
• lower_bound: Es un literal numérico que representa el valor más pequeño para incluir en una agregación.
• upper_bound: Literal numérico que representa el valor más grande para incluir en una agregación.

Parámetros de ADH.ANON_PERCENTILE_CONT:

• percentile: Es el percentil que se calculará, un literal en el rango [0, 1].
• contribution_bounds_per_row: Las contribuciones por usuario se restringen por fila (registro). Ten en cuenta que se requieren límites de ajuste explícitos para el percentil, por lo que solo se admite como una función complementaria.
• lower_bound: Es un literal numérico que representa el valor más pequeño para incluir en una agregación.
• upper_bound: Literal numérico que representa el valor más grande para incluir en una agregación.

Calcula MIN y MAX

Las funciones MIN y MAX no se admiten directamente en las agregaciones de ruido, pero a menudo existen métodos alternativos para calcular estos resultados.

Si tienes un MIN o un MAX de valores que se pueden usar como claves de agrupación, como la fecha del evento, primero puedes usar GROUP BY en ese valor y, luego, calcular MIN/MAX. Devuelve el valor mínimo o máximo que supera el umbral de agregación.

Ejemplo:

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

Como alternativa, si tienes un MIN o un MAX de valores detallados con límites conocidos, puedes usar PERCENTILE_CONT con límites explícitos para obtener un resultado aproximado.

Ejemplo:

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

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.

Grupos públicos

Con una cláusula GROUP BY, los resultados anonimizados de una consulta se agregan en grupos. Se aplica un umbral de agregación para garantizar que haya una cantidad suficiente de usuarios en el grupo y que se protejan los datos de los usuarios individuales. El proceso para determinar qué grupos se pueden lanzar se denomina "selección de particiones".

En muchos casos, los grupos pueden ser de conocimiento público. Por ejemplo, agrupar por versión del navegador, día de la semana o región geográfica no depende de los datos del usuario si los valores de la clave de agrupación se conocen de antemano. En este caso, se puede omitir la selección de particiones, ya que la presencia o ausencia de un grupo en el resultado no proporciona información nueva sobre los usuarios.

Ads Data Hub identifica las consultas aptas para los grupos públicos y no aplica umbrales de agregación a estas consultas. Esto significa que no se filtran filas de salida. Ten en cuenta que los resultados calculados a partir de una pequeña cantidad de usuarios pueden verse muy afectados por el ruido.

Para ser apta para los grupos públicos, la consulta debe estructurarse de manera que todas las claves de agrupación se conozcan de antemano. Las columnas de agrupación deben cumplir con las siguientes condiciones:

• Provienen de una tabla pública (una tabla o una cláusula SELECT sin datos del usuario del Centro de Datos de Anuncios).
• Tienen SELECT DISTINCT aplicado para aplicar valores únicos.
• Se unen a la consulta con un OUTER JOIN en todas las columnas individuales.

Ejemplos de consultas de grupos públicos:

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT age_group_id FROM adh.age_group)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT * FROM UNNEST([1, 2, 3]) AS age_group_id)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

En el primer ejemplo, el adh.google_ads_impressions table protegido se une con la tabla adh.age_group que no contiene datos del usuario en la columna age_group_id. La misma columna de la tabla pública age_group_id aparece en la cláusula GROUP BY.

Del mismo modo, en el segundo ejemplo, la tabla protegida adh.google_ads_impressions se une con la tabla pública, que se proporciona de forma explícita como UNNEST([1, 2, 3]). Ten en cuenta que, en ambos ejemplos, la clave de agrupación age_group_id proviene de la tabla pública.

También se pueden proporcionar varios elementos de agrupación, por ejemplo:

SELECT campaign_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT campaign_id, customer_id FROM adh.google_ads_campaign)
USING (campaign_id, customer_id)
GROUP BY campaign_id, customer_id

SELECT p.campaign_id, p.browser, COUNT(*) FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
 SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
 CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
 ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY campaign_id, browser;

La ausencia de filtrado en las consultas de grupos públicos puede ser beneficiosa para las consultas que se ejecutan de forma recurrente, ya que el resultado siempre se devuelve para los mismos valores de las claves de agrupación fijas. Esto puede ser particularmente útil, por ejemplo, para crear paneles periódicos.

Una advertencia: Si una tabla pública proporciona una gran cantidad de valores de claves de agrupación, es posible que obtengas muchas filas con pocos datos o sin datos, y todas estas filas se informarán como que tienen un alto impacto de ruido. En este caso, debes considerar proporcionar de forma explícita una lista más pequeña de claves con solo los valores que te interesan.

---

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 utilizan la inyecció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 consultas que se admiten cuando se ejecutan consultas con inyección de ruido.

Agregados a nivel del usuario

Los agregados no restringidos 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_creative_conversions
  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 de forma automática 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 búsquedas que usan la inserció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 ocurre 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 datos que ya se hayan exportado 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 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 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 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.

Acerca de las ventanas de visualización

Algunos patrones de búsqueda generan informes durante un período extenso y se regeneran periódicamente para incluir resultados nuevos. Es posible que estas consultas deban ajustarse para que funcionen en el modo de ruido, ya que, si vuelven a calcular los resultados anteriores, se bloquearán. En cambio, cada trabajo solo debe generar resultados nuevos, que luego se pueden combinar con los resultados de trabajos anteriores para obtener un informe completo.

Por ejemplo, si creas un informe de métricas por fecha que se actualiza a diario, haz lo siguiente:

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

No debes ejecutar esta opción con un rango de fechas amplio, ya que se volverán a calcular los resultados de los días anteriores. En cambio, debes ejecutar cada trabajo solo el día más reciente, que tiene datos nuevos, y, luego, combinarlo con los resultados de los trabajos anteriores.

Si necesitas actualizar un resultado anterior (por ejemplo, para tener en cuenta los datos que llegan tarde), debes evitar volver a calcular un solo resultado más de 1 o 2 veces. De lo contrario, es posible que recibas errores debido a intentos repetidos de consultas.

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 la primera capa de agregación es demasiado detallada 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_creative_conversions 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 de 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 diferentes 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).