Noise Injection

Noise Injection (Einfügen von Rauschen) ist eine Technik, die zum Schutz der Privatsphäre der Nutzer beim Abfragen von Datenbanken eingesetzt wird. Dabei wird einer SELECT-Anweisung für die Aggregation einer Abfrage zufälliges Rauschen hinzugefügt. Dieses Rauschen schützt die Privatsphäre des Nutzers und liefert dabei relativ genaue Ergebnisse. Die Notwendigkeit von Differenzprüfungen entfällt und der erforderliche Aggregationsschwellenwert für die Ausgabe wird reduziert. Die meisten vorhandenen Abfragen können im Rauschmodus ausgeführt werden. Es gibt aber einige Einschränkungen.

Die Vorteile von „Noise Injection“

Keine Differenzprüfungen erforderlich: Wird „Noise Injection“ bei Abfragen eingesetzt, werden keine Zeilen aufgrund von Ähnlichkeiten mit früheren Ergebnismengen herausgefiltert. So erhalten Sie einen ganzheitlichen Überblick über die Daten und schützen gleichzeitig die Privatsphäre der Nutzer.

Vereinfachte Problembehebung: Zeilen werden nur aufgrund von Aggregationsanforderungen ausgelassen, was die Fehlersuche und Anpassung von Abfragen vereinfacht.

Keine neue Syntax: Sie müssen sich nicht mit einer neuen Abfragesyntax vertraut machen oder mit Datenschutzkonzepten auseinandersetzen, um „Noise Injection“ anstelle von Differenzprüfungen zu verwenden.

Eindeutige Genauigkeit von Ergebnissen: Bei einem erfolgreichen Job wird der Gesamtanteil der Daten mit der erwarteten Menge an Rauschen angezeigt.

Auswirkungen von Rauschen auf Datenschutzanforderungen

Differenzprüfungen: „Noise Injection“ stützt sich nicht auf bestehende Differenzprüfungen in Ads Data Hub. Wenn Sie die Technik verwenden, werden Differenzprüfungen deaktiviert.

Aggregationsanforderung: Bei Verwendung von „Noise Injection“ werden Impressionsdaten ausgegeben, die von mindestens 20 einzelnen Nutzern stammen, sowie Klick- oder Conversion-Daten, die von mindestens 10 einzelnen Nutzern stammen.

Statische Prüfungen: Keine Auswirkungen.

Kontingente und Abfragebegrenzungen: Für Abfragen, die mit Rauschen ausgeführt werden, wird dasselbe Kontingent für den Datenzugriff verwendet wie für Differenzprüfungen. Genau wie bei Differenzprüfungen verlieren Sie möglicherweise den Zugriff auf häufig abgefragte Daten in einem Datensatz, wenn Sie dafür mehrmals dieselbe Abfrage ausführen. Dies kann passieren, wenn Sie Abfragen mit gleitendem Fenster ausführen oder dieselbe Anfrage mehrmals stellen.

Für den Rauschmodus gelten zusätzliche, strengere Begrenzungen für die Neuberechnung derselben aggregierten Ergebnisse aus oder innerhalb von unterschiedlichen Abfragen. Wie beim Kontingent für den Datenzugriff können Sie den Zugriff auf häufig abgefragte Daten in einem Datensatz verlieren. Begrenzungen aufgrund der Neuberechnung derselben aggregierten Ergebnisse gelten jedoch nur für Abfragen im Rauschmodus, nicht für Abfragen im Differenzprüfungsmodus. Weitere Informationen finden Sie unter Wiederholte Ergebnisse.

Weitere Informationen zu Datenschutzprüfungen

Auswirkungen von „Noise Injection“ auf die Ergebnisse

Mit „Noise Injection“ wird in Ads Data Hub das Risiko von Offenlegungen gemindert, also das Risiko, dass Unbefugte Informationen über einen einzelnen Nutzer in Erfahrung bringen können. Sie schafft ein Gleichgewicht zwischen dem Schutz der Privatsphäre und der Funktionalität.

Durch „Noise Injection“ werden die Ergebnisse in Ads Data Hub so transformiert:

• Die Nutzerbeiträge, die Ausreißer darstellen, werden in aggregierten Ergebnissen eingeschränkt. Die Beiträge der einzelnen Nutzer werden in jeder Aggregation summiert und für jede Aggregation werden dann minimale und maximale Grenzwerte festgelegt.
• Die eingeschränkten Beiträge der einzelnen Nutzer werden aggregiert.
• Jedem aggregierten Ergebnis – dem Ergebnis jedes Aggregationsfunktionsaufrufs in jeder Zeile – wird Rauschen hinzugefügt. Das Ausmaß dieses zufälligen Rauschens ist proportional zu den festgelegten Grenzen.
• Es wird eine verrauschte Nutzerzahl für jede Zeile berechnet und Zeilen mit zu wenigen Nutzern werden ausgeschlossen. Das funktioniert ähnlich wie bei der k-Anonymität im Differenzprüfungsmodus, allerdings können aufgrund des Rauschens bei Jobs, die im selben Datensatz ausgeführt werden, verschiedene Zeilen ausgeschlossen werden. Außerdem werden im Rauschmodus weniger Zeilen ausgeschlossen, weil die Aggregationsanforderung geringer ist (ca. 20 im Vergleich zu 50).

Das Endergebnis ist ein Datensatz, in dem jede Zeile verrauschte aggregierte Ergebnisse enthält und kleine Gruppen ausgeschlossen wurden. Dadurch wird der Einfluss eines einzelnen Nutzers auf die ausgegebenen Ergebnisse verschleiert.

Einschränkungen der Aggregation

Bei Verwendung von „Noise Injection“ in Ads Data Hub wird die Aggregation implizit oder explizit eingeschränkt, um Nutzerbeiträge, die Ausreißer darstellen, zu begrenzen. Je nach Anwendungsfall können Sie wählen, welche Art der Einschränkung Sie verwenden möchten.

Implizite Einschränkung

Bei der impliziten Einschränkung werden die Grenzen automatisch festgelegt. Dafür ist keine spezielle SQL-Syntax erforderlich. Hat eine Zeile einen größeren Wertebereich als eine andere, werden bei der impliziten Einschränkung andere Grenzen für diese Zeilen festgelegt. Dadurch ergibt sich in der Regel eine geringere Fehlermarge für die einzelnen Ergebnisse. Andererseits gelten für jede Aggregation eigene Grenzwerte und Rauschstufen, was einen Vergleich erschweren kann.

Die implizite Einschränkung kann fehlschlagen, wenn eine Aggregation Daten von zu wenigen Nutzern enthält, z. B. bei einem COUNTIF()-Aufruf mit einer seltenen Bedingung. In diesem Fall werden NULL Ergebnisse zurückgegeben. Außerdem wird bei COUNT(DISTINCT user_id) automatisch die explizite Einschränkung mit den Grenzen 0 und 1 verwendet.

Explizite Einschränkung

Durch die explizite Einschränkung wird der Gesamtbeitrag jedes Nutzers auf einen bestimmten Bereich begrenzt. Explizite Grenzen werden einheitlich auf alle Zeilen angewendet und müssen Literalwerte sein. Auch wenn einige Zeilen mehr Beiträge pro Nutzer aufweisen als andere, gelten für alle die gleichen Grenzen. Dadurch lassen sich die Ergebnisse verschiedener Reihen besser vergleichen, auch wenn einige Reihen mehr Rauschen erhalten, als dies bei der impliziten Einschränkung der Fall wäre.

Bei der expliziten Einschränkung wird für einen bestimmten Satz von Grenzwerten nur halb so viel Rauschen verwendet wie bei der impliziten Einschränkung. Wenn Sie realistische Grenzen schätzen können, sollten Sie diese deshalb explizit festlegen, um bessere Ergebnisse zu erhalten.

Um eine explizite Einschränkung zu verwenden, legen Sie die Grenzen für jede unterstützte Aggregatfunktion fest, indem Sie Ganzzahlen für die untere und obere Grenze angeben. Beispiel:

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

Abfrage mit „Noise Injection“ ausführen

1. Schreiben Sie eine Abfrage oder öffnen Sie eine vorhandene Abfrage. Die Aggregatfunktionen, die verwendet werden können, finden Sie unter Unterstützte Funktionen.
2. Klicken Sie im Query Editor auf Ausführen und machen Sie Angaben zu einem neuen Job.
3. Klicken Sie auf die Ein/Aus-Schaltfläche für Datenschutzeinstellungen, um Rauschen verwenden zu aktivieren.
4. Führen Sie die Abfrage aus.
5. Prüfen Sie das hinzugefügte Rauschen.
6. Optional: Passen Sie die Abfrage an, um die Auswirkungen des Rauschens zu reduzieren.

Auswirkungen des Rauschens prüfen

Nachdem eine Abfrage erfolgreich abgeschlossen wurde, wird in Ads Data Hub die Zuverlässigkeit des Ergebnisses angezeigt. Sie hängt davon ab, wie viele Zellen in der Ausgabe den erwarteten Anteil an Rauschen haben. Die Auswirkung auf einen Wert in der Ergebnistabelle wird als hoch eingestuft, wenn das Ausmaß des hinzugefügten Rauschens höher als 5 % des Ergebnisses in der Zelle ist. Die Bereiche für die Auswirkung sind in der folgenden Tabelle aufgeführt.

Für entsprechende Ausgabedatensätze werden auf dem Tab „Details“ die 10 Spalten mit dem meisten Rauschen in absteigender Reihenfolge mit dem entsprechenden Beitrag zum Rauschen aufgeführt. Hier ist die Aufschlüsselung der erwarteten Menge an Rauschen.

Daten mit erwarteter Menge an Rauschen	Farbe der Anzeige	Auswirkungen
> 95 %	Grün	Geringe Auswirkungen
85 % bis 95 %	Gelb	Mittlere Auswirkungen
75 % bis 85 %	Orange	Hohe Auswirkungen
< 75 %	Rot	Sehr hohe Auswirkungen

So rufen Sie detaillierte Informationen zu den Auswirkungen des Rauschens auf:

1. Klicken Sie auf Berichte.
2. Wählen Sie in der Liste einen Bericht aus. Die Kurzinfo „Zusammenfassung – Datenschutz“ gibt den Prozentsatz der Ergebnisse an, die den erwarteten Anteil an Rauschen aufweisen (bei denen der Anteil des hinzugefügten Rauschens mehr als 5 % des Ergebnisses ausmacht).
3. Weitere Informationen finden Sie unter Jobs > Details.
4. Sehen Sie sich in den Jobdetails das Feld Datenschutzbezogene Nachrichten an. Die Ergebnisse lassen sich einer der unten aufgeführten Kategorien zuordnen.
5. Passen Sie Ihre Abfrage bei Bedarf an, um das Ergebnis zu verbessern.

Abfragen anpassen

Aggregierte Ergebnisse weisen eher ein unerwartetes Maß an Rauschen auf, wenn nur wenige Nutzer dazu beitragen. Dies kann vorkommen, wenn Zeilen nur wenige Nutzer aufweisen oder wenn einige Nutzer keinen Einfluss auf die Ergebnisse haben, z. B. bei Verwendung der Funktion COUNTIF. Anhand der Details zum Rauschen können Sie Ihre Abfrage anpassen, um den Prozentsatz der Daten mit der erwarteten Menge an Rauschen zu erhöhen.

Nachstehend finden Sie allgemeine Hinweise:

• Erweitern Sie den Zeitraum.
• Ändern Sie die Abfrage, um den Detaillierungsgrad der Daten zu reduzieren. Dazu können Sie beispielsweise nach weniger Parametern gruppieren oder COUNTIF durch COUNT ersetzen.
• Entfernen Sie Spalten mit starkem Rauschen.
• Verwenden Sie die explizite Einschränkung.

---

Unterstützte Aggregatfunktionen

Für folgenden Aggregatfunktionen wird Rauschen unterstützt:

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

Das Keyword DISTINCT wird nur mit der Funktion COUNT unterstützt und nur, wenn es mit einem direkten Verweis auf die Spalte user_id aus einer Ads Data Hub-Tabelle oder einem Ausdruck verwendet wird, der entweder user_id oder NULL zurückgibt, z. B. COUNT(DISTINCT IF(..., user_id, NULL)).

Die folgenden Funktionen werden nicht direkt unterstützt, können aber durch andere Aggregatfunktionen mit Rauschen ersetzt werden, um Statistiken zu erhalten. Bei den numerischen Werten handelt es sich um Beispiele:

• LOGICAL_OR(...). Empfohlener Ersatz: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
• LOGICAL_AND(...). Empfohlener Ersatz: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

Ganzzahlige Ergebnisse

Auch wenn Ads Data Hub automatisch Rauschen für diese Aggregationsfunktionen einfügt, ändern sich die Funktionssignaturen nicht. Da Funktionen wie COUNT oder SUM für INT64 den Wert INT64 zurückgeben, werden die Dezimalstellen des verrauschten Ergebnisses gerundet. Im Vergleich zur Größe des Ergebnisses und des Rauschens ist dies normalerweise vernachlässigbar.

Wenn Sie den Detaillierungsgrad der Dezimalstellen in Ihrem Ergebnis benötigen, sollten Sie keine Funktionen schreiben, die INT64 zurückgeben. Sie können beispielsweise SUM verwenden, wobei die Eingabe in FLOAT64 umgewandelt wird.

---

Unterstützte Abfragemuster

Wichtig: Die meisten standardmäßigen Best Practices von Ads Data Hub treffen auch auf Abfragen mit „Noise Injection“ zu. Wir empfehlen Ihnen insbesondere, die Anleitung zur wiederholten Abfrage derselben Daten zu lesen.

In diesem Abschnitt werden Abfragemuster beschrieben, die für Abfragen mit „Noise Injection“ unterstützt werden.

Aggregatfunktionen auf Nutzerebene

Uneingeschränkte Aggregatfunktionen auf Nutzerebene werden genauso unterstützt wie im Differenzprüfungsmodus. Rauschen wird nur in Aggregationen eingefügt, in denen Daten von mehreren Nutzern kombiniert werden. Aggregationen, die explizit nach user_id gruppiert sind, oder analytische Funktionen, die nach user_id partitionieren, werden nicht verrauscht. Hier ist jede Funktion erlaubt. Aggregationen auf Nutzerebene, die nicht explizit nach user_id gruppiert sind, z. B. GROUP BY impression_id, werden als nutzerübergreifende Aggregationen behandelt und verrauscht.

Es reicht nicht aus, nach external_cookie zu gruppieren. Die Spalte „external_cookie“ kann zwar verwendet werden, um *_match-Tabellen und kundeneigene Tabellen zusammenzuführen, Aggregationen einzelner Nutzer sollten aber explizit nach der Spalte „user_id“ gruppiert werden und nicht nur nach der Spalte „external_cookie“.

Beispiel für eine Aggregatfunktion:

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;

Beispiel für eine analytische Funktion:

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;

Parallele Aggregatfunktionen

Jede nutzerübergreifende Aggregation wird unabhängig verrauscht. Sie können mehrere solcher Aggregationen in einer einzigen Anweisung ausführen und die Ergebnisse mithilfe einer JOIN- oder UNION-Anweisung in einer Tabelle zusammenführen.

Beispiel:

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)

Das ist im Differenzprüfungsmodus zwar möglich, sollte aber vermieden werden. Diese Praxis stellt kein Problem beim Rauschen dar, da jede parallele Aggregatfunktion unabhängig verrauscht und gefiltert wird.

Aggregierte Daten zusammen mit nicht aggregierten Daten

Hinweis: Da jede Aggregation der Ads Data Hub-Tabelle unabhängig voneinander verrauscht wird, stimmen die Gesamtwerte möglicherweise nicht überein. In diesem Fall stimmen die summierten Werte von imps für eine bestimmte campaign_id möglicherweise nicht mit dem entsprechenden Wert von campaign_imps überein.

Da Ads Data Hub nur Analysefenster unterstützt, die nach user_id partitioniert sind, ist es eine gängige Lösung, diese Ergebnisse separat zu aggregieren und sie vor der erneuten Aggregation per Self Join zu verknüpfen. Diese Abfragen werden im Rauschmodus unterstützt und funktionieren dort oft besser als im Differenzprüfungsmodus, da die Datenschutzanforderungen früher erfüllt werden.

Beispiel:

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

Im Rauschmodus ist es nicht zulässig, aggregierte Ergebnisse wie AVG(campaign_imps) neu zu aggregieren.

---

Nicht unterstützte Abfragemuster

In diesem Abschnitt werden Abfragemuster beschrieben, die für Abfragen mit „Noise Injection“ nicht unterstützt werden.

Abfragen, die die heutigen Daten einschließen

Im Rauschmodus werden Abfragen von Daten des aktuellen Tages nicht unterstützt. (Dies sollte auch im Differenzprüfungsmodus vermieden werden.) Für Abfragen mit „Noise Injection“ kann das aktuelle Datum nicht ausgewählt werden.

Wiederholte Ergebnisse

Im Rauschmodus schränkt Ads Data Hub ein, wie oft dieselbe Aggregation wiederholt werden kann. Wenn Sie die Limits erreichen, verlieren Sie für Abfragen im Rauschmodus den Zugriff auf im Datensatz häufig abgefragte Daten. Die folgenden Beispiele zeigen, wie es dazu kommt.

Bei Abfragewiederholungen wird dieselbe Abfrage mehrfach mit denselben oder sehr ähnlichen Parametern ausgeführt, wobei sich auch die Zeiträume überschneiden. Sie können das umgehen, indem Sie Daten verwenden, die schon in Ihr BigQuery-Projekt exportiert wurden.

Wenn mit zwei Jobs sich überschneidende Zeiträume abgefragt werden, kann es zu Wiederholungen kommen, wenn dieselbe Berechnung für dieselben Nutzer ausgeführt wird. Die folgende Abfrage, die für sich überschneidende Zeiträume ausgeführt wird, führt beispielsweise zu einer Wiederholung, da sie nach Datum partitioniert:

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

In diesem Fall sollten Sie die Abfrage für getrennte Datumssegmente ausführen.

Es kann auch zu Wiederholungen kommen, wenn Daten relativ unabhängig vom Datum sind. Die folgende Abfrage führt zu Wiederholungen, wenn sie für sich überschneidende Zeiträume ausgeführt wird, wobei beide Jobs die gesamte Laufzeit einer Kampagne abdecken:

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

Hier sollten Sie die Abfrage nur einmal ausführen, da sich das Ergebnis nicht ändern wird.

Zu Aggregationswiederholungen kommt es, wenn dieselbe Aggregation innerhalb einer Abfrage mehrfach wiederholt wird:

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

In diesem Fall sollten Sie eine der Wiederholungen entfernen.

Wenn die Aggregationen syntaktisch unterschiedlich sind, aber denselben Wert berechnen, würde dies trotzdem als Wiederholung gelten. Mit anderen Worten: Wenn die Werte von condition1 und condition2 für alle Nutzer mit einem bestimmten Wert von key gleich sind, würde die folgende Abfrage zu einer Wiederholung führen:

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

Wenn Sie Bedingungen verwenden, die für einige Nutzergruppen sehr ähnlich sind, können Sie die Abfrage so umschreiben, dass sie nur eine COUNT-Funktion enthält.

Zu duplizierten Zeilen kommt es, wenn eine Ads Data Hub-Tabelle mit einer BigQuery-Tabelle so verbunden wird, dass jede Zeile der Ads Data Hub-Tabelle mehreren Zeilen in der BigQuery-Tabelle entspricht. So führt die folgende Abfrage beispielsweise zu einer Wiederholung, wenn es mehrere Zeilen mit derselben Kampagnen-ID in bq_table gibt:

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

In diesem Fall sollten Sie die Abfrage so umstrukturieren, dass bq_table nur eine Zeile pro Schlüssel/Wert-Paar (hier campaign_id) enthält.

Das Aufheben der Verschachtelung eines Arrays aus der Ads Data Hub-Tabelle könnte den gleichen Effekt haben, wenn die meisten Nutzer die gleichen Werte-Arrays haben:

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

Weitere Best Practices für Abfragen

Direkte Neuaggregation

Rauschen wird auf die erste Ebene der nutzerübergreifenden Aggregation in der Abfrage angewendet. Abfragen mit mehreren Aggregationsebenen werden blockiert:

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

Die besten Ergebnisse durch Rauschen lassen sich erzielen, wenn alle nutzerübergreifenden Vorgänge innerhalb einer einzigen Aggregation berechnet werden. Berechnen Sie z. B. die SUM der Ereignisse und nicht die SUM der Zwischenwerte. Sie können eine Abfrage so umschreiben, dass verrauschte Zusammenfassungen neu aggregiert werden. Das führt jedoch zu einem viel stärkeren Rauschen bei den endgültigen zusammengefassten Werten.

Falls sich das nicht vermeiden lässt, können Sie Ihre Abfrage umschreiben, um Ergebnisse stattdessen direkt aus der ersten Ebene zu exportieren. Um dies innerhalb eines einzelnen Jobs zu erreichen, ohne die Skriptergebnisse zu ändern, können Sie eine temporäre Tabelle (oder eine nach BigQuery exportierte Tabelle) mit der Syntax OPTIONS(privacy_checked_export=true) erstellen. Beispiel:

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

Weitere Informationen zu temporären Tabellen

Ist die erste Aggregationsebene zu detailliert für Datenschutzprüfungen, sollten Sie die Abfrage umschreiben und dabei eine Aggregatfunktion auf Nutzerebene verwenden: Wenn das nicht möglich ist, wird diese Abfrage im Rauschmodus nicht unterstützt.

Nicht zusammengeführte Nutzer-IDs

Bei Abfragen im Rauschmodus dürfen keine Daten verschiedener Nutzer in einer einzelnen Zeile kombiniert werden, es sei denn, es wird eine verrauschte Aggregation erstellt. Folglich müssen Joins nicht aggregierter Ads Data Hub-Daten explizit über die Spalte user_id erfolgen.

Bei dieser Abfrage wird ein Validierungsfehler ausgegeben, da der Join nicht explizit über die Spalte user_id erfolgt:

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

Um Abhilfe zu schaffen, können Sie die USING-Anweisung so anpassen, dass user_id explizit eingeschlossen wird, z. B. USING(impression_id, user_id).

Diese Einschränkung gilt nur für Joins zwischen Ads Data Hub-Tabellen (mit Ausnahme von Dimensionstabellen). Sie gilt nicht für kundeneigene Tabellen. Folgendes ist beispielsweise zulässig:

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

Ads Data Hub/BigQuery-Unions

Für verrauschte Aggregationen sind Nutzerkennungen erforderlich, damit sie gut funktionieren. Da kundeneigene Daten in BigQuery keine Nutzerkennungen haben, ist ohne Join mit einer Ads Data Hub-Tabelle keine Union in einer verrauschten Aggregation möglich.

Für diese Abfrage wird ein Validierungsfehler zurückgegeben:

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

Um dies zu beheben, sollten Sie statt einer Union einen Join der BigQuery-Tabelle durchführen, um die Daten von Ads Data Hub zu erweitern, oder die Daten trennen und jede Quelle separat aggregieren.

Es ist zulässig, eine Union mehrerer Ads Data Hub-Tabellen mit Nutzerdaten oder mehrerer kundeneigener BigQuery-Tabellen vorzunehmen, aber Sie dürfen die beiden nicht mischen.

Right Joins zwischen Ads Data Hub und BigQuery

Outer Joins mit kundeneigenen Daten können Zeilen zur Folge haben, in denen Nutzerkennungen fehlen. Das Rauschen kann dann nicht richtig funktionieren.

Beide Abfragen führen zu Validierungsfehlern, da sie nicht zugeordnete Zeilen mit fehlenden Nutzerkennungen auf der Ads Data Hub-Seite zulassen:

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)

Wäre die Reihenfolge der Tabellen umgekehrt, würden beide Joins funktionieren.

Zusammenfassung herausgefilterter Zeilen

Die Spezifikation für die Zusammenfassung herausgefilterter Zeilen wird im Rauschmodus nicht unterstützt. Aufgrund der geringeren Filterraten und da keine Daten aufgrund von Differenzprüfungen herausgefiltert werden, ist diese Funktion im Rauschmodus meist überflüssig.

Wenn bei verrauschten Ergebnissen viel herausgefiltert wird, sollten Sie die Menge der aggregierten Daten erhöhen. Sie können eine parallele Aggregation des gesamten Datensatzes durchführen, um eine Schätzung der Gesamtmenge zu vergleichen, zum Beispiel:

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

Die Gesamtzahl wird unabhängig verrauscht und die Gesamtwerte stimmen möglicherweise nicht überein, aber die Gesamtzahl ist oft genauer als die Summe der verrauschten Zeilen.

Modusübergreifend erstellte Tabellen

Nicht exportierte Tabellen in Ads Data Hub können nur mit demselben Datenschutzmodus verwendet werden, in dem sie erstellt wurden. Es ist nicht möglich, eine Tabelle im normalen Aggregationsmodus zu erstellen und sie dann im Rauschmodus zu verwenden oder umgekehrt (es sei denn, die Tabelle wird zuerst in BigQuery exportiert).