Injection de bruit

La technique d'injection de bruit permet de protéger la confidentialité des données utilisateur lorsqu'une base de données est interrogée. Elle consiste à ajouter du bruit aléatoire à une clause SELECT d'agrégation d'une requête. Ce bruit protège la confidentialité des données utilisateur tout en fournissant des résultats raisonnablement précis. Il n'est plus nécessaire de vérifier les différences et cela permet de réduire le seuil d'agrégation requis pour les résultats. La plupart des requêtes existantes peuvent être exécutées en mode bruit, avec quelques restrictions.

Avantages de l'injection de bruit

La vérification des différences ne s'applique pas : quand vous exécutez des requêtes avec une injection de bruit, Ads Data Hub ne filtre pas les lignes en raison de leur similarité avec des ensembles de résultats précédents. Vous pouvez donc toujours obtenir une vue globale des données tout en protégeant la confidentialité des utilisateurs.

Le dépannage est plus simple : des lignes ne peuvent être omises qu'en raison des exigences d'agrégation, ce qui simplifie le dépannage et l'adaptation des requêtes.

Il n'est pas nécessaire d'apprendre une nouvelle syntaxe : vous n'avez pas besoin d'apprendre une nouvelle syntaxe des requêtes ni de connaître les concepts de confidentialité pour utiliser le bruit au lieu de la vérification des différences.

La précision des résultats est claire : lorsqu'un job a réussi, il affiche le pourcentage total de données ainsi que la quantité de bruit attendue.

Impact du bruit sur les exigences de confidentialité

Vérification des différences : l'injection de bruit ne repose pas sur la vérification des différences incluse dans Ads Data Hub. Lorsque vous utilisez l'injection de bruit, la vérification des différences est désactivée.

Exigences d'agrégation : l'injection de bruit génère des données sur les impressions représentées par environ 20 utilisateurs uniques ou plus, et des données sur les clics ou les conversions représentées par environ 10 utilisateurs uniques ou plus.

Vérifications statiques : aucun impact.

Budgets et limites des requêtes : les requêtes exécutées avec du bruit partagent le budget d'accès aux données utilisé pour les vérifications des différences. Comme pour les vérifications des différences, si vous exécutez de nombreuses fois la même requête sur le même ensemble de données, vous risquez de perdre l'accès aux dates fréquemment interrogées dans l'ensemble de données. Cela peut se produire si vous exécutez des requêtes sur fenêtre glissante ou si vous exécutez plusieurs fois la même requête.

Le mode bruit impose des limites supplémentaires, plus strictes, pour recalculer les mêmes résultats regroupés au sein d'une même requête ou d'une requête à l'autre. Comme pour le budget d'accès aux données, vous pouvez perdre l'accès aux dates fréquemment interrogées dans l'ensemble de données. Toutefois, les limitations dues au recalcul des mêmes résultats regroupés ne restreindront que les requêtes en mode bruit, et non celles en mode vérification des différences. Pour en savoir plus, consultez Résultats répétés.

En savoir plus sur les contrôles de confidentialité

Impact de l'injection de bruit sur les résultats

Ads Data Hub injecte du bruit afin de limiter le risque de divulgation, c'est-à-dire le risque qu'un utilisateur puisse obtenir des informations sur une autre personne. L'objectif est de trouver l'équilibre entre confidentialité et utilité.

Dans Ads Data Hub, l'injection de bruit transforme les résultats des requêtes comme suit :

Elle limite les contributions des utilisateurs correspondant à des anomalies dans les résultats agrégés. Elle additionne la contribution de chaque utilisateur dans chaque agrégation, puis limite chaque contribution avec des marges de limitation minimale et maximale.
Elle agrège les contributions limitées par utilisateur.
Elle ajoute du bruit à chaque résultat agrégé (résultat de chaque appel de fonction d'agrégation sur chaque ligne). L'ampleur de ce bruit aléatoire est proportionnelle aux limites définies.
Elle calcule un nombre d'utilisateurs avec bruit pour chaque ligne et élimine les lignes comportant trop peu d'utilisateurs. Ce comportement est semblable à celui du k-anonymat en mode vérification des différences, mais en raison du bruit, les tâches exécutées sur le même ensemble de données peuvent supprimer des lignes différentes. En outre, le mode bruit supprime moins de lignes, car le seuil minimal exigé pour l'agrégation est plus faible (environ 20 contre exactement 50).

Le résultat final est un ensemble de données dans lequel chaque ligne comporte des résultats agrégés avec bruit et où les petits groupes ont été éliminés. Cela masque l'effet d'un utilisateur unique sur les résultats affichés.

À propos de la limitation de l'agrégation

Dans Ads Data Hub, l'injection de bruit utilise une limitation d'agrégation implicite ou explicite pour réduire la contribution des anomalies. Vous pouvez choisir quel type de limitation utiliser en fonction de votre cas d'utilisation.

Limitation implicite

Avec la limitation implicite, les limites sont déterminées automatiquement. Vous n'avez besoin d'aucune syntaxe SQL spéciale pour utiliser la limitation implicite. Si une ligne comporte une plage de valeurs plus étendue, la limitation implicite recherche des limites différentes pour cette ligne. Cela donne généralement une marge d'erreur inférieure pour chaque résultat. Par ailleurs, chaque agrégation est associée à différentes marges de limitation et niveaux de bruit, ce qui peut compliquer la comparaison des agrégations.

La limitation implicite peut échouer lorsqu'une agrégation collecte des données auprès d'un nombre d'utilisateurs trop faible (par exemple, un appel COUNTIF() avec une condition rare). Ces cas renvoient des résultats NULL. Notez également que COUNT(DISTINCT user_id) utilise automatiquement la limitation explicite selon la plage 0-1.

Limitation explicite

La limitation explicite limite à une plage spécifiée le nombre total de contributions de chaque utilisateur. Les limites explicites sont appliquées uniformément à toutes les lignes et doivent correspondre à des valeurs littérales. Même si certaines lignes ont une plage de contributions par utilisateur plus étendue que d'autres, les mêmes limites s'appliquent à toutes. Cela permet de mieux comparer les résultats des différentes lignes, même si certaines lignes reçoivent plus de bruit que si elles utilisaient la limitation implicite.

La limitation explicite utilise deux fois moins de bruit que la limitation implicite pour un ensemble donné de marges de limitation. Par conséquent, si vous estimez que des limites sont raisonnables, vous obtiendrez de meilleurs résultats en les définissant explicitement.

Pour utiliser la limitation explicite, définissez les limites pour chaque fonction d'agrégation compatible en ajoutant des entiers représentant la limite inférieure et la limite supérieure. Exemple :

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

Exécuter une requête en utilisant l'injection de bruit

Écrivez une requête ou ouvrez une requête existante. Pour savoir quelles fonctions d'agrégation peuvent être utilisées, consultez Fonctions compatibles.
Dans l'éditeur de requête, cliquez sur Exécuter, puis saisissez les informations pour un nouveau job.
Cliquez sur le bouton Paramètres de confidentialité pour activer l'option Utiliser le bruit.
Exécutez la requête.
Examinez le bruit ajouté.
Facultatif : adaptez la requête pour réduire l'impact du bruit.

Examiner l'impact du bruit

Lorsqu'une requête est exécutée correctement, Ads Data Hub affiche la fiabilité du résultat en fonction du nombre de cellules qui, dans le résultat, ont la quantité de bruit attendue. Dans la table de résultat, l'impact sur une valeur est considéré comme élevé si le bruit ajouté à cette valeur est supérieur à 5 % du résultat dans la cellule. Consultez les plages d'impact dans le tableau suivant.

Pour les ensembles de données de sortie impactés, l'onglet "Détails" liste les 10 colonnes ayant le niveau de bruit le plus important, de l'impact le plus élevé au moins élevé, et leur contribution au bruit correspondante. Voici comment se répartit la quantité de bruit attendue.

Données ayant la quantité de bruit attendue	Couleur de l'indicateur	Impact
>95 %	Vert	Faible impact
85 %-95 %	Jaune	Impact moyen
75 %-85 %	Orange	Impact élevé
<75 %	Rouge	Impact très élevé

Pour obtenir des informations détaillées sur l'impact du bruit :

Cliquez sur Rapports.
Sélectionnez un rapport dans la liste. L'info-bulle du récapitulatif sur la confidentialité indique le pourcentage de résultats ayant la quantité de bruit attendue, ce qui correspond à la quantité de bruit ajoutée supérieure à 5 % du résultat.
Pour en savoir plus, cliquez sur Jobs > Détails.
Consultez Messages concernant la confidentialité dans les détails du job. Les résultats sont compris dans l'une des catégories listées.
Si nécessaire, ajustez votre requête pour améliorer le résultat.

Adapter les requêtes

Il est plus probable que les résultats agrégés aient une quantité de bruit inattendue lorsque peu d'utilisateurs contribuent à ces résultats. Cela peut se produire lorsque les lignes incluent peu d'utilisateurs ou lorsque certains utilisateurs n'influent pas sur les résultats (par exemple, lorsque la fonction COUNTIF est utilisée). En fonction des détails sur le bruit, vous souhaiterez peut-être ajuster votre requête afin d'accroître le pourcentage de données ayant la quantité de bruit attendue.

Voici quelques consignes générales :

Étendez la plage de dates.
Réécrivez la requête pour réduire la précision des données (par exemple, en les regroupant selon moins de paramètres ou en remplaçant COUNTIF par COUNT).
Supprimez les colonnes avec bruit.
Utilisez la limitation explicite.

Fonctions d'agrégation compatibles

Les fonctions d'agrégation suivantes sont compatibles avec le bruit :

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

Le mot clé DISTINCT n'est compatible qu'avec la fonction COUNT, et seulement lorsqu'il est utilisé avec une référence directe à la colonne user_id à partir d'une table Ads Data Hub ou une expression qui renvoie user_id ou NULL, comme COUNT(DISTINCT IF(..., user_id, NULL)).

Les fonctions suivantes ne sont pas directement compatibles, mais elles peuvent être remplacées par d'autres fonctions d'agrégation avec bruit afin d'obtenir des résultats statistiques. Notez que les valeurs numériques ne sont fournies qu'à titre d'exemple :

LOGICAL_OR(...). Remplacement proposé : COUNT(DISTINCT IF(..., user_id, NULL)) > 0
LOGICAL_AND(...). Remplacement proposé : COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

À propos des résultats entiers

Même si Ads Data Hub injectera automatiquement du bruit pour ces fonctions d'agrégation, les signatures de fonctions ne changent pas. Comme les fonctions telles que COUNT ou SUM d'INT64 renvoient INT64, toute partie décimale du résultat avec bruit est arrondie. C'est généralement négligeable par rapport à la taille du résultat et du bruit.

Si vous avez besoin de la précision de la décimale dans votre résultat, évitez d'écrire des fonctions qui renvoient INT64 (par exemple, en utilisant SUM avec son entrée castée en FLOAT64).

Schémas de requête acceptés

Important : La plupart des bonnes pratiques standards d'Ads Data Hub s'appliquent aussi aux requêtes qui utilisent l'injection de bruit. En particulier, nous vous recommandons d'examiner les consignes à suivre pour interroger les mêmes données de façon répétée.

Cette section décrit les schémas de requête qui sont acceptés lorsque vous exécutez des requêtes en utilisant l'injection de bruit.

Agrégations au niveau de l'utilisateur

Les agrégations non limitées au niveau de l'utilisateur sont acceptées de la même façon que pour le mode vérification des différences. Le bruit n'est injecté que dans les agrégations qui combinent des données entre plusieurs utilisateurs. Les agrégations qui regroupent explicitement les données par user_id ou les fonctions analytiques qui partitionnent les données par user_id ne reçoivent aucun bruit, et toutes les fonctions sont autorisées. Les agrégations au niveau de l'utilisateur qui ne regroupent pas explicitement les données par user_id (GROUP BY impression_id, par exemple) sont traitées comme des agrégations multi-utilisateurs, et du bruit est donc ajouté.

Le regroupement par external_cookie ne suffit pas. Alors qu'external_cookie peut être utilisé pour joindre les tables *_match avec celles appartenant au client, toute agrégation d'utilisateur unique doit être explicitement groupée par la colonne user_id, et pas seulement par la colonne external_cookie.

Exemple pour une fonction d'agrégation :

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;

Exemple pour une fonction analytique :

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;

Agrégations parallèles

Chaque agrégation multi-utilisateur reçoit du bruit de façon indépendante. Vous pouvez exécuter plusieurs agrégations de ce type dans une même instruction, en combinant les résultats dans une table à l'aide de JOIN ou UNION.

Exemple :

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)

Notez que cette situation serait acceptée en mode vérification des différences, mais qu'elle devrait être évitée. Cette pratique ne présente pas de problème concernant le bruit, car le bruit et le filtrage sont appliqués à chaque agrégation de façon indépendante.

Données agrégées jointes à des données non agrégées

Ads Data Hub n'accepte que les fonctions analytiques qui partitionnent les données par user_id. La solution la plus courante consiste donc à agréger ces résultats séparément et à les autojointer avant de les réagréger. Ces requêtes sont acceptées en mode bruit et sont généralement plus performantes qu'avec le mode vérification des différences, car les exigences de confidentialité sont résolues plus tôt.

Exemple :

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

Le mode bruit interdit la réagrégation des résultats agrégés, tels que AVG(campaign_imps).

Schémas de requête non acceptés

Cette section décrit les schémas de requête qui ne sont pas acceptés lorsque vous exécutez des requêtes en utilisant l'injection de bruit.

Requêtes incluant le jour même

Les requêtes en mode bruit ne permettent pas d'interroger les données de la journée en cours (cette méthode devrait être évitée en mode vérification des différences). Vous ne pouvez pas sélectionner la date du jour pour les requêtes qui utilisent l'injection de bruit.

Résultats répétés

En mode bruit, Ads Data Hub limite la fréquence à laquelle vous pouvez répéter la même agrégation. Si vous atteignez ces limites, vos requêtes en mode bruit perdront l'accès aux dates fréquemment interrogées dans l'ensemble de données. Voici quelques exemples illustrant une telle situation.

Une répétition de requête se produit lorsqu'une même requête est exécutée plusieurs fois avec des paramètres identiques ou très similaires, tels que des plages de dates qui se chevauchent. Pour éviter cela, utilisez des données qui sont déjà exportées vers votre projet BigQuery.

Notez que si deux jobs interrogent des plages de dates qui se chevauchent, ils risquent de produire des répétitions s'ils effectuent le même calcul sur les mêmes utilisateurs. Par exemple, la requête suivante exécutée sur des plages de dates qui se chevauchent crée des répétitions, car elle partitionne les données par date :

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

Dans ce cas, vous devriez exécuter la requête sur des plages de dates distinctes.

Une répétition se produit également lorsque les données ne dépendent pas vraiment de la date. La requête suivante génère des répétitions lorsqu'elle est exécutée sur des dates qui se chevauchent et que les deux jobs couvrent toute la durée d'une campagne :

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

Dans ce cas, vous devez n'exécuter cette requête qu'une seule fois, car le résultat ne change pas.

Une répétition d'agrégation se produit lorsqu'une même agrégation est répétée plusieurs fois dans une requête :

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

Dans ce cas, vous devez supprimer une des répétitions.

Notez que même si les agrégations sont différentes au niveau syntaxique, mais qu'elles calculent la même valeur, elles seront comptabilisées comme une répétition. En d'autres termes, si les valeurs de condition1 et condition2 sont les mêmes pour tous les utilisateurs avec la valeur key, la requête suivante génère une répétition :

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

Si certaines de vos conditions sont très similaires pour des groupes d'utilisateurs, vous pourriez envisager de réécrire la requête pour n'avoir qu'un seul COUNT.

Une duplication des lignes se produit lorsqu'une table Ads Data Hub est jointe à une table BigQuery de sorte que chaque ligne de la table Ads Data Hub corresponde à plusieurs lignes de la table BigQuery. Par exemple, la requête suivante génère une répétition si plusieurs lignes comportent le même ID de campagne dans bq_table :

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

Dans ce cas, vous devez restructurer la requête pour que bq_table ne comporte qu'une seule ligne par valeur de clé de jointure (campaign_id, dans ce cas).

Notez que désimbriquer un tableau de la table Ads Data Hub pourrait produire le même effet si la plupart des utilisateurs disposent des mêmes tableaux de valeurs :

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

En savoir plus sur nos autres bonnes pratiques concernant les requêtes

Réagrégation directe

Le bruit est appliqué à la première couche d'agrégation multi-utilisateur dans la requête. Les requêtes comportant plusieurs couches d'agrégation sont bloquées :

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

Pour optimiser les résultats du bruit, calculez toutes les opérations multi-utilisateurs dans une même agrégation. Par exemple, utilisez une SUM d'événements plutôt qu'une SUM de totaux intermédiaires. Vous pouvez réécrire une requête pour réagréger des agrégations avec bruit, mais les agrégations finales risquent de présenter un bruit bien plus élevé.

S'il n'est pas possible de faire autrement, vous pouvez réécrire votre requête pour exporter les résultats directement à partir de la première couche. Pour effectuer cette action dans un même job sans modifier les résultats du script, créez une table temporaire (ou une table exportée vers votre projet BigQuery) avec la syntaxe OPTIONS(privacy_checked_export=true). Exemple :

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

En savoir plus sur les tables temporaires

Si la première couche d'agrégation est trop précise pour les contrôles de confidentialité, vous pouvez envisager de réécrire la requête avec des agrégations au niveau de l'utilisateur. Si ce n'est pas possible, cette requête n'est pas acceptée en mode bruit.

ID utilisateur non joints

En mode bruit, les requêtes ne doivent pas combiner de données provenant d'utilisateurs distincts dans une même ligne, sauf lorsqu'une agrégation est effectuée avec du bruit. Par conséquent, les jointures des données Ads Data Hub non agrégées sont requises pour joindre explicitement les ID utilisateur dans la colonne user_id.

Cette requête n'est pas jointe explicitement dans la colonne user_id, ce qui entraîne une erreur de validation :

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

Pour résoudre le problème, vous pouvez ajuster la clause USING afin d'inclure explicitement user_id (par exemple, USING(impression_id, user_id)).

Notez que cette limitation ne s'applique qu'aux jointures entre les tables Ads Data Hub (à l'exception des tables de dimensions). Elle ne s'applique pas aux tables appartenant au client. L'exemple suivant illustre ce qui est autorisé :

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

Unions Ads Data Hub-BigQuery

Pour qu'elles fonctionnent, les agrégations avec bruit nécessitent des identifiants utilisateur. Dans BigQuery les données appartenant au client ne comportent pas d'identifiant utilisateur et ne peuvent donc pas être unies dans une agrégation avec bruit sans être jointes à une table Ads Data Hub.

Cette requête entraîne une erreur de validation :

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

Pour résoudre ce problème, vous devez soit joindre la table BigQuery pour augmenter les données Ads Data Hub au lieu d'utiliser l'union, soit séparer les données afin d'agréger chaque source séparément.

Notez que vous pouvez unir plusieurs tables Ads Data Hub avec des données utilisateur ou plusieurs tables BigQuery appartenant au client, mais vous ne pouvez pas mélanger les deux.

Jointures droite Ads Data Hub-BigQuery

Les jointures externes avec les données appartenant au client peuvent se traduire par des lignes sans identifiant utilisateur, ce qui empêche le bon fonctionnement du bruit.

Ces deux requêtes entraînent des erreurs de validation, car elles autorisent les lignes sans correspondance et sans identifiant utilisateur côté Ads Data Hub :

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)

Notez que les deux jointures fonctionneraient si l'ordre des tables était inversé.

Récapitulatif des lignes filtrées

La spécification de récapitulatif des lignes filtrées n'est pas acceptée en mode bruit. Le plus souvent, cette fonctionnalité n'est pas nécessaire avec le bruit, en raison de taux de filtrage inférieurs et de l'absence de filtrage lors de la vérification des différences.

Si vous constatez un filtrage des données important dans un résultat avec bruit, augmentez les données agrégées. Vous pouvez effectuer une agrégation parallèle sur l'intégralité de l'ensemble de données pour comparer une estimation du total. Par exemple :

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

Remarque : Le bruit est appliqué au total de façon indépendante et il est possible que les valeurs totales ne s'additionnent pas, mais le total est souvent plus précis que la somme des lignes avec bruit.

Tables créées dans plusieurs modes

Les tables non exportées dans Ads Data Hub ne peuvent être utilisées qu'avec le mode de confidentialité dans lequel elles ont été créées. Vous ne pouvez pas créer une table dans un mode d'agrégation normal et l'utiliser en mode bruit, ni l'inverse (sauf si la table est d'abord exportée vers BigQuery).