Praktik terbaik berikut akan memberi Anda teknik untuk mengembangkan kueri yang berfokus pada privasi dan berperforma tinggi.
Privasi dan akurasi data
Mengembangkan kueri tentang data {i>sandbox<i}
Praktik terbaik: Hanya buat kueri data produksi saat Anda dalam produksi.
Gunakan data sandbox selama pengembangan kueri Anda jika memungkinkan. Tugas yang menggunakan data sandbox tidak memberikan peluang tambahan untuk pemeriksaan perbedaan guna memfilter hasil kueri Anda. Selain itu, karena kurangnya pemeriksaan privasi, kueri sandbox berjalan lebih cepat, sehingga memungkinkan iterasi yang lebih cepat selama pengembangan kueri.
Jika Anda harus membuat kueri pada data yang sebenarnya (seperti saat menggunakan tabel pencocokan), untuk mengurangi kemungkinan baris tumpang-tindih, pilih rentang tanggal dan parameter lain yang tidak mungkin tumpang-tindih untuk setiap iterasi kueri Anda. Terakhir, jalankan kueri Anda pada rentang data yang diinginkan.
Pertimbangkan hasil historis dengan cermat
Praktik terbaik: Kurangi kemungkinan tumpang-tindih kumpulan hasil antara kueri yang baru-baru ini dijalankan.
Perlu diingat bahwa tingkat perubahan antara hasil kueri akan memengaruhi seberapa besar kemungkinan hasil dihilangkan di kemudian hari karena pemeriksaan privasi. Kumpulan hasil kedua yang sangat mirip dengan kumpulan hasil yang baru-baru ini ditampilkan kemungkinan akan dihapus.
Sebagai gantinya, ubah parameter utama dalam kueri Anda, seperti rentang tanggal atau ID kampanye, untuk mengurangi kemungkinan tumpang-tindih yang signifikan.
Jangan buat kueri data hari ini
Praktik terbaik: Jangan menjalankan beberapa kueri yang tanggal akhirnya adalah hari ini.
Menjalankan beberapa kueri dengan tanggal akhir yang sama dengan hari ini sering kali menyebabkan baris difilter. Panduan ini juga berlaku untuk kueri yang berjalan segera setelah tengah malam pada data kemarin.
Jangan membuat kueri untuk data yang sama lebih dari yang diperlukan
Praktik terbaik:
- Pilih tanggal mulai dan akhir yang terikat erat.
- Daripada membuat kueri untuk jendela yang tumpang-tindih, jalankan kueri Anda pada set data yang terpisah, lalu gabungkan hasilnya di BigQuery.
- Gunakan hasil yang disimpan, bukan menjalankan kembali kueri Anda.
- Buat tabel sementara untuk setiap rentang tanggal yang Anda kueri.
Ads Data Hub membatasi total frekuensi Anda dapat mengkueri data yang sama. Dengan demikian, Anda harus mencoba membatasi berapa kali Anda mengakses bagian data tertentu.
Jangan gunakan agregasi yang melebihi yang diperlukan dalam kueri yang sama
Praktik terbaik:
- Meminimalkan jumlah agregasi dalam kueri
- Menulis ulang kueri untuk menggabungkan agregasi jika memungkinkan
Ads Data Hub membatasi jumlah agregasi lintas-pengguna yang diizinkan untuk digunakan dalam subkueri hingga 100 agregasi. Oleh karena itu, secara keseluruhan kami merekomendasikan penulisan kueri yang menghasilkan lebih banyak baris dengan kunci pengelompokan dan agregasi sederhana yang terfokus, daripada lebih banyak kolom dengan kunci pengelompokan yang luas dan agregasi yang kompleks. Pola berikut harus dihindari:
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
Kueri yang menghitung peristiwa bergantung pada kumpulan kolom yang sama harus ditulis ulang menggunakan pernyataan GROUP BY.
SELECT
field_1,
field_2,
COUNT(1) AS cnt
FROM
table
GROUP BY
1, 2
Hasilnya dapat digabungkan dengan cara yang sama di BigQuery.
Kueri yang membuat kolom dari array, lalu mengagregasinya setelahnya harus ditulis ulang untuk menggabungkan langkah-langkah ini.
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)
Kueri sebelumnya dapat ditulis ulang sebagai:
SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1
Kueri yang menggunakan kombinasi kolom berbeda dalam agregasi yang berbeda dapat ditulis ulang menjadi beberapa kueri yang lebih terfokus.
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
Kueri sebelumnya dapat dibagi menjadi:
SELECT
field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1
dan
SELECT
field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1
Anda dapat membagi hasil ini menjadi kueri terpisah, membuat dan menggabungkan tabel dalam satu kueri, atau menggabungkannya dengan UNION jika skema kompatibel.
Mengoptimalkan dan memahami penggabungan
Praktik terbaik: Gunakan LEFT JOIN
, bukan INNER JOIN
, untuk menggabungkan klik atau konversi dengan tayangan.
Tidak semua tayangan iklan dikaitkan dengan klik atau konversi. Oleh karena itu, jika Anda INNER JOIN
klik atau konversi pada tayangan, tayangan yang tidak terkait dengan klik atau konversi akan difilter dari hasil Anda.
Gabungkan beberapa hasil akhir di BigQuery
Praktik terbaik: Hindari kueri Ads Data Hub yang menggabungkan hasil gabungan. Sebagai gantinya, tulis 2 kueri terpisah dan gabungkan hasilnya di BigQuery.
Baris yang tidak memenuhi persyaratan agregasi akan difilter dari hasil Anda. Oleh karena itu, jika kueri Anda menggabungkan baris yang tidak digabungkan dengan baris yang cukup digabungkan, baris yang dihasilkan akan difilter. Selain itu, kueri dengan beberapa agregasi kurang berperforma baik di Ads Data Hub.
Anda dapat menggabungkan hasil (di BigQuery) dari beberapa kueri agregasi (dari Ads Data Hub). Hasil yang dihitung menggunakan kueri umum akan memiliki skema akhir yang sama.
Kueri berikut mengambil hasil Ads Data Hub individual (campaign_data_123
dan campaign_data_456
) dan menggabungkannya ke BigQuery:
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)
Menggunakan ringkasan baris yang difilter
Praktik terbaik: Tambahkan ringkasan baris yang difilter ke kueri Anda.
Ringkasan baris yang difilter menghitung data yang difilter karena pemeriksaan privasi. Data dari baris yang difilter dijumlahkan dan ditambahkan ke baris generik. Meskipun data yang difilter tidak dapat dianalisis lebih lanjut, data tersebut memberikan ringkasan tentang jumlah data yang difilter dari hasil.
Akun untuk ID pengguna yang disetel ke nol
Praktik terbaik: Perhitungkan ID pengguna yang disetel ke nol dalam hasil Anda.
ID pengguna akhir dapat ditetapkan ke 0 karena sejumlah alasan, termasuk: memilih tidak ikut personalisasi iklan, alasan peraturan, dll. Dengan demikian, data yang berasal dari beberapa pengguna akan dimasukkan ke user_id
0.
Jika Anda ingin memahami total data, seperti total tayangan iklan atau klik, Anda harus menyertakan peristiwa ini. Namun, data ini tidak akan berguna untuk mendapatkan wawasan tentang pelanggan, dan harus difilter jika Anda melakukan analisis tersebut.
Anda dapat mengecualikan data ini dari hasil dengan menambahkan WHERE user_id != "0"
ke kueri Anda.
Performa
Menghindari agregasi ulang
Praktik terbaik: Hindari beberapa lapisan agregasi di seluruh pengguna.
Kueri yang menggabungkan hasil yang telah digabungkan, seperti kueri dengan beberapa GROUP BY
, atau agregasi bertingkat, memerlukan lebih banyak resource untuk diproses.
Sering kali, kueri dengan beberapa lapisan agregasi dapat dipecah, sehingga meningkatkan performa. Anda harus mencoba mempertahankan baris pada tingkat peristiwa atau pengguna saat memproses, lalu menggabungkannya dengan satu agregasi.
Pola berikut harus dihindari:
SELECT SUM(count)
FROM
(SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)
Kueri yang menggunakan beberapa lapisan agregasi harus ditulis ulang untuk menggunakan satu lapisan agregasi.
(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )
Kueri yang dapat dipecah dengan mudah harus dipecah. Anda dapat menggabungkan hasil di BigQuery.
Optimalkan untuk BigQuery
Umumnya, kueri yang lebih sedikit berperforma lebih baik. Saat mengevaluasi performa kueri, jumlah pekerjaan yang diperlukan bergantung pada faktor berikut:
- Data input dan sumber data (I/O): Berapa byte yang dibaca kueri Anda?
- Komunikasi antar-node (pengacakan): Berapa byte yang diteruskan kueri Anda ke tahap berikutnya?
- Komputasi: Berapa banyak pekerjaan CPU yang diperlukan kueri Anda?
- Output (materialisasi): Berapa byte yang ditulis oleh kueri Anda?
- Anti-pola kueri: Apakah kueri Anda mengikuti praktik terbaik SQL?
Jika eksekusi kueri tidak memenuhi perjanjian tingkat layanan, atau Anda mengalami error karena kehabisan resource atau waktu tunggu habis, pertimbangkan untuk:
- Menggunakan hasil dari kueri sebelumnya, bukan menghitung ulang. Misalnya, total mingguan Anda dapat berupa jumlah yang dihitung di BigQuery dari 7 kueri gabungan satu hari.
- Menguraikan kueri menjadi sub kueri logis (seperti membagi beberapa gabungan menjadi beberapa kueri), atau membatasi kumpulan data yang sedang diproses. Anda dapat menggabungkan hasil dari setiap tugas ke dalam satu set data di BigQuery. Meskipun dapat membantu kehabisan resource, cara ini dapat memperlambat kueri Anda.
- Jika Anda mengalami error resource terlampaui di BigQuery, coba gunakan tabel sementara untuk membagi kueri Anda menjadi beberapa kueri BigQuery.
- Mereferensikan lebih sedikit tabel dalam satu kueri, karena tindakan ini menggunakan memori dalam jumlah besar dan dapat menyebabkan kueri Anda gagal.
- Menulis ulang kueri Anda sehingga menggabungkan lebih sedikit tabel pengguna.
- Menulis ulang kueri Anda untuk menghindari penggabungan kembali tabel yang sama.
Penasihat kueri
Jika SQL Anda valid tetapi dapat memicu pemfilteran berlebihan, kueri menampilkan saran yang dapat ditindaklanjuti selama proses pengembangan kueri, untuk membantu Anda menghindari hasil yang tidak diinginkan.
Pemicu mencakup pola berikut:
- Menggabungkan subkueri agregat
- Menggabungkan data yang tidak diagregasi dengan kemungkinan pengguna yang berbeda
- Tabel sementara yang ditentukan secara rekursif
Untuk menggunakan {i>query query<i}:
- UI. Rekomendasi akan ditampilkan di editor kueri, di atas teks kueri.
- API. Gunakan metode
customers.analysisQueries.validate
.