In den folgenden Best Practices werden Verfahren zur Entwicklung datenschutzkonformer, leistungsfähiger Abfragen vorgestellt.
Datenschutz und Genauigkeit von Daten
Abfragen für Sandbox-Daten entwickeln
Best Practice: Fragen Sie Produktionsdaten nur in der Produktionsphase ab.
Verwenden Sie während der Abfrageentwicklung nach Möglichkeit Sandbox-Daten. Jobs, für die Sandbox-Daten verwendet werden, bieten keine zusätzlichen Möglichkeiten für Differenzprüfungen, um Ihre Abfrageergebnisse zu filtern. Weil keine Datenschutzprüfungen durchgeführt werden, werden Sandbox-Abfragen außerdem schneller ausgeführt. Das ermöglicht eine schnellere Iteration bei der Entwicklung von Abfragen.
Wenn Sie Abfragen für Ihre tatsächlichen Daten entwickeln müssen (z. B. bei der Verwendung von Match-Tables), wählen Sie Zeiträume und andere Parameter, bei denen es unwahrscheinlich ist, dass sich Zeilen bei den einzelnen Iterationen Ihrer Abfrage überschneiden. Führen Sie abschließend die Abfrage für den gewünschten Datenbereich aus.
Bisherige Ergebnisse berücksichtigen
Best Practice: Verringern Sie die Wahrscheinlichkeit, dass sich Ergebnismengen zwischen kürzlich ausgeführten Abfragen überschneiden.
Die Änderungsrate zwischen den Abfrageergebnissen beeinflusst, wie wahrscheinlich es ist, dass Ergebnisse später aufgrund von Datenschutzprüfungen ausgeschlossen werden. Eine zweite Ergebnismenge, die einer kürzlich zurückgegebenen Ergebnismenge ähnelt, wird wahrscheinlich ausgelassen.
Ändern Sie wichtige Parameter in Ihrer Abfrage, z. B. Zeiträume oder Kampagnen-IDs, um die Wahrscheinlichkeit einer erheblichen Überschneidung zu verringern.
Keine „heute“-Daten abfragen
Best Practice: Führen Sie nicht mehrere Abfragen mit „heute“ als Enddatum durch.
Bei mehreren Abfragen mit „heute“ als Enddatum werden Zeilen oft herausgefiltert. Diese Empfehlung gilt auch für Abfragen, die kurz nach Mitternacht für die Daten von gestern durchgeführt werden.
Dieselben Daten nicht öfter als nötig abfragen
Best Practices:
- Wählen Sie eng begrenzte Start- und Enddaten.
- Anstatt Zeiträume abzufragen, die sich überschneiden, sollten Sie Ihre Abfragen für nicht zusammenhängende Datasets ausführen und die Ergebnisse dann in BigQuery aggregieren.
- Verwenden Sie gespeicherte Ergebnisse, anstatt die Abfrage mehrmals auszuführen.
- Erstellen Sie temporäre Tabellen für jeden Zeitraum, für den Sie eine Abfrage ausführen.
In Ads Data Hub können dieselben Daten nur begrenzt oft abgefragt werden. Daher sollten Sie versuchen, die Anzahl der Zugriffe auf bestimmte Daten einzuschränken.
Nicht mehr Aggregationen als nötig in derselben Abfrage verwenden
Best Practices:
- Anzahl der Aggregationen in einer Abfrage minimieren
- Abfragen nach Möglichkeit umschreiben, um Aggregationen zu kombinieren
In Ads Data Hub ist die Anzahl der nutzerübergreifenden Aggregationen, die in einer Unterabfrage zulässig sind, auf 100 begrenzt. Insgesamt empfehlen wir daher, Abfragen zu schreiben, bei denen mehr Zeilen mit eng gefassten Gruppierungsschlüsseln und einfachen Aggregationen anstelle von mehr Spalten mit breit gefassten Gruppierungsschlüsseln und komplexen Aggregationen ausgegeben werden. Folgendes Muster sollte vermieden werden:
SELECT
COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
table
Abfragen, bei denen Ereignisse anhand derselben Felder gezählt werden, sollten mit der GROUP BY-Anweisung umgeschrieben werden.
SELECT
field_1,
field_2,
COUNT(1) AS cnt
FROM
table
GROUP BY
1, 2
Das Ergebnis kann auf dieselbe Weise in BigQuery aggregiert werden.
Abfragen, bei denen Spalten aus einem Array erstellt und anschließend aggregiert werden, sollten so umgeschrieben werden, dass diese Schritte zusammengeführt werden.
SELECT
COUNTIF(a_1) AS cnt_1,
COUNTIF(a_2) AS cnt_2
FROM
(SELECT
1 IN UNNEST(field) AS a_1,
2 IN UNNEST(field) AS a_2,
FROM
table)
Die letzte Abfrage kann so umgeschrieben werden:
SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1
Für Abfragen, bei denen verschiedene Kombinationen von Feldern in verschiedenen Aggregationen verwendet werden, können mehrere gezieltere Abfragen erstellt werden.
SELECT
COUNTIF(field_1 = a_1) AS cnt_a_1,
COUNTIF(field_1 = b_1) AS cnt_b_1,
COUNTIF(field_2 = a_2) AS cnt_a_2,
COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table
Die letzte Abfrage kann so aufgeteilt werden:
SELECT
field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1
und
SELECT
field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1
Sie können diese Ergebnisse in separate Abfragen aufteilen, die Tabellen in einer einzelnen Abfrage erstellen und zusammenführen oder sie mit einer UNION kombinieren, wenn die Schemas kompatibel sind.
Join-Konfigurationen optimieren und verstehen
Best Practice: Verwenden Sie LEFT JOIN
statt INNER JOIN
, um Klicks oder Conversions Impressionen zuzuordnen.
Nicht alle Impressionen werden Klicks oder Conversions zugeordnet. Wenn Sie also INNER JOIN
verwenden, um Klicks oder Conversions mit Impressionen zu verknüpfen, werden Impressionen, die nicht zu Klicks oder Conversions gehören, aus den Ergebnissen herausgefiltert.
Bestimmte Endergebnisse in BigQuery zusammenführen
Best Practice: Vermeiden Sie Ads Data Hub-Abfragen, in denen aggregierte Ergebnisse zusammengeführt werden. Erstellen Sie stattdessen zwei separate Abfragen und führen Sie die Ergebnisse in BigQuery zusammen.
Zeilen, die die Aggregationsanforderungen nicht erfüllen, werden aus den Ergebnissen herausgefiltert. Wenn in Ihre Abfrage eine Zeile mit unzureichend aggregierten Daten mit einer ausreichend aggregierten Zeile zusammengeführt wird, wird die Ergebniszeile herausgefiltert. Außerdem wird mit Abfragen mit mehreren Aggregationen in Ads Data Hub eine geringere Leistung erzielt.
In BigQuery können die Ergebnisse mehrerer Aggregationsabfragen aus Ads Data Hub zusammengeführt werden. Die Ergebnisse, die mit allgemeinen Abfragen berechnet werden, haben dieselben endgültigen Schemas.
Bei der folgenden Abfrage werden einzelne Ads Data Hub-Ergebnisse (campaign_data_123
und campaign_data_456
) in BigQuery zusammengeführt:
SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)
Zusammenfassungen herausgefilterter Zeilen verwenden
Best Practice: Fügen Sie Ihren Abfragen Zusammenfassungen herausgefilterter Zeilen hinzu.
Zusammenfassungen herausgefilterter Zeilen enthalten Daten, die aufgrund von Datenschutzprüfungen herausgefiltert wurden. Die Daten aus herausgefilterten Zeilen werden summiert und in eine universelle Zeile eingefügt. Auch wenn die entsprechenden Daten nicht weiter analysiert werden können, erhalten Sie einen Überblick, wie viele Daten aus den Ergebnissen herausgefiltert wurden.
Auf null gesetzte Nutzer-IDs berücksichtigen
Best Practice: Berücksichtigen Sie in Ihren Ergebnissen auch Nutzer-IDs, die auf null gesetzt wurden.
Es gibt verschiedene Gründe, warum die ID eines Endnutzers auf null gesetzt wird. Vielleicht hat er personalisierte Werbung deaktiviert oder es liegen rechtliche Gründe vor. Daten, die von mehreren Nutzern stammen, werden dann für eine user_id
mit dem Wert „0“ erfasst.
Wenn Sie Gesamtdaten, wie die Impressionen oder Klicks insgesamt, betrachten möchten, sollten Sie diese Ereignisse einschließen. Anhand dieser Daten lassen sich jedoch keine Rückschlüsse auf Kunden ziehen. Sie müssen gefiltert werden, wenn Sie solche Analysen durchführen möchten.
Wenn Sie diese Daten aus den Ergebnissen ausschließen möchten, können Sie Ihren Abfragen WHERE user_id != "0"
hinzufügen.
Leistung
Wiederholte Aggregation vermeiden
Best Practice: Nutzerdaten sollten nicht mehrfach aggregiert werden.
Abfragen, in denen bereits aggregierte Ergebnisse kombiniert werden, erfordern mehr Ressourcen für die Verarbeitung. Das ist z. B. bei Abfragen mit mehreren GROUP BY
s oder verschachtelter Aggregation der Fall.
Häufig lassen sich Abfragen mit mehreren Aggregationsebenen aufteilen, um die Leistung zu verbessern. Sie sollten versuchen, Zeilen auf Ereignis- oder Nutzerebene zu verarbeiten und dann in einem Vorgang zu aggregieren.
Folgende Muster sollten vermieden werden:
SELECT SUM(count)
FROM
(SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)
Abfragen mit mehreren Aggregationsebenen sollten so umgeschrieben werden, dass eine einzelne Ebene verwendet wird.
(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )
Abfragen, die leicht aufgeteilt werden können, sollten aufgeteilt werden. Sie können Ergebnisse in BigQuery zusammenführen.
Für BigQuery optimieren
Im Allgemeinen erzielen Sie mit einfachen Abfragen eine bessere Leistung. Bei der Bewertung der Abfrageleistung hängt der Arbeitsaufwand von den folgenden Faktoren ab:
- Eingabedaten und Datenquellen (E/A): Wie viele Bytes liest die Abfrage?
- Kommunikation zwischen Knoten (Shuffle): Wie viele Bytes werden bei der Abfrage an die nächste Phase übergeben?
- Verarbeitung: Wie viel CPU-Leistung ist für die Abfrage erforderlich?
- Ausgaben (Schreibergebnisse): Wie viele Byte schreibt die Abfrage?
- Schlecht formulierte Abfragen: Entsprechen die Abfragen den Best Practices für SQL?
Wenn die Ausführung von Abfragen nicht Ihren Service Level Agreements (SLAs) entspricht oder Fehler aufgrund von Ressourcenausschöpfung oder Zeitüberschreitungen auftreten, sollten Sie Folgendes in Betracht ziehen:
- Sie können die Ergebnisse früherer Abfragen verwenden, anstatt sie neu zu berechnen. So könnte die wöchentliche Gesamtzahl beispielsweise die in BigQuery berechnete Summe der aggregierten Abfragen von 7 einzelnen Tagen sein.
- Sie können Abfragen in logische Unterabfragen zerlegen und z. B. mehrere Joins in mehrere Abfragen aufteilen oder die zu verarbeitende Datenmenge anderweitig einschränken. So lassen sich die Ergebnisse einzelner Jobs in einem Dataset in BigQuery kombinieren. Dies kann zwar der Ressourcenausschöpfung entgegenwirken, eventuell wird aber die Abfrage verlangsamt.
- Wenn in BigQuery Fehler aufgrund von Ressourcenüberschreitungen auftreten, können Sie versuchen, Ihre Abfrage mithilfe von temporären Tabellen in mehrere BigQuery-Abfragen aufzuteilen.
- Es kann helfen, in einer Abfrage auf weniger Tabellen zu verweisen. Für Abfragen mit vielen Verweisen wird viel Arbeitsspeicher benötigt. Das kann dazu führen, dass sie fehlschlagen.
- Sie können Ihre Abfragen so umformulieren, dass darin weniger Nutzertabellen zusammengeführt werden.
- Sie können Ihre Abfragen so umformulieren, dass eine Tabelle nicht wieder mit sich selbst zusammengeführt wird.
Query Advisor
Wenn Ihre SQL-Abfrage zwar gültig ist, aber eventuell dazu führt, dass zu viel herausgefiltert wird, werden im Query Advisor umsetzbare Empfehlungen angezeigt, mit denen sich unerwünschte Ergebnisse vermeiden lassen.
Zu den Triggern gehören die folgenden Muster:
- Zusammenführen aggregierter Unterabfragen
- Zusammenführen nicht aggregierter Daten mit potenziell unterschiedlichen Nutzern
- Rekursiv definierte temporäre Tabellen
So verwenden Sie den Query Advisor:
- UI: Empfehlungen werden im Query Editor über dem Abfragetext angezeigt.
- API: Verwenden Sie die Methode
customers.analysisQueries.validate
.