Praktik terbaik

Praktik terbaik berikut akan memberi Anda teknik untuk mengembangkan kueri yang berfokus pada privasi dan berperforma tinggi. Untuk praktik terbaik khusus menjalankan kueri dalam mode derau, lihat bagian tentang pola kueri yang didukung dan tidak didukung di Injeksi derau.

Privasi dan akurasi data

Mengembangkan kueri pada data sandbox

Praktik terbaik: Hanya buat kueri data produksi saat Anda berada 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 tidak adanya pemeriksaan privasi, kueri sandbox berjalan lebih cepat, sehingga memungkinkan iterasi yang lebih cepat selama pengembangan kueri.

Jika Anda harus mengembangkan kueri pada data sebenarnya (seperti saat menggunakan tabel pencocokan), agar tidak terlalu mungkin terjadi tumpang-tindih baris, 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 set hasil antara kueri yang baru saja dijalankan.

Perlu diingat bahwa tingkat perubahan antara hasil kueri akan memengaruhi kemungkinan hasil dihilangkan nanti karena pemeriksaan privasi. Kumpulan hasil kedua yang sangat mirip dengan kumpulan hasil yang baru saja 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 membuat kueri data hari ini

Praktik terbaik: Jangan menjalankan beberapa kueri dengan tanggal akhir hari ini.

Menjalankan beberapa kueri dengan tanggal akhir yang sama dengan hari ini sering kali menyebabkan baris difilter. Panduan ini juga berlaku untuk menjalankan kueri segera setelah tengah malam pada data kemarin.

Jangan membuat kueri data yang sama lebih dari yang diperlukan

Praktik terbaik:

  • Pilih tanggal mulai dan akhir yang sangat dekat.
  • Daripada membuat kueri pada periode yang tumpang-tindih, jalankan kueri pada set data yang tidak tumpang-tindih, lalu gabungkan hasilnya di BigQuery.
  • Gunakan hasil tersimpan, bukan menjalankan ulang kueri.
  • Buat tabel sementara untuk setiap rentang tanggal yang Anda kueri.

Ads Data Hub membatasi jumlah total kueri yang dapat Anda buat untuk data yang sama. Oleh karena itu, Anda harus mencoba membatasi frekuensi akses ke bagian data tertentu.

Jangan gunakan agregasi lebih dari 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. Oleh karena itu, secara keseluruhan, sebaiknya tulis kueri yang menghasilkan lebih banyak baris dengan kunci pengelompokan yang difokuskan dan agregasi sederhana, bukan 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 menggabungkannya setelah itu, 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 berbagai kombinasi kolom 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 join

Praktik terbaik: Gunakan LEFT JOIN, bukan INNER JOIN, untuk menggabungkan klik atau konversi ke 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.

Gambar yang menampilkan beberapa jenis join melalui diagram venn

Menggabungkan 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 cukup digabungkan dengan baris yang cukup digabungkan, baris yang dihasilkan akan difilter. Selain itu, kueri dengan beberapa agregasi memiliki performa yang lebih rendah 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 setiap hasil Ads Data Hub (campaign_data_123 dan campaign_data_456) dan menggabungkannya di 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 jumlah data yang difilter dari hasil.

Memperhitungkan ID pengguna yang di-nol

Praktik terbaik: Perhitungkan ID pengguna yang di-nolkan 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 diberi kunci ke user_id 0.

Jika ingin memahami total data, seperti total tayangan iklan atau klik, Anda harus menyertakan peristiwa ini. Namun, data ini tidak akan berguna untuk mendapatkan insight 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.

Performa

Menghindari agregasi ulang

Praktik terbaik: Hindari beberapa lapisan agregasi di seluruh pengguna.

Kueri yang menggabungkan hasil yang telah digabungkan, seperti dalam kasus 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 di 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 dengan mudah dipecah harus dipecah. Anda dapat menggabungkan hasil di BigQuery.

Mengoptimalkan untuk BigQuery

Umumnya, kueri yang melakukan lebih sedikit pekerjaan akan berperforma lebih baik. Saat mengevaluasi performa kueri, jumlah pekerjaan yang diperlukan bergantung pada faktor berikut:

Jika eksekusi kueri tidak memenuhi perjanjian tingkat layanan, atau Anda mengalami error karena kehabisan resource atau waktu tunggu habis, pertimbangkan:

  • 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.
  • Mendekomposisi kueri menjadi subkueri logis (seperti membagi beberapa join 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 mengatasi kehabisan resource, tindakan ini dapat memperlambat kueri Anda.
  • Jika Anda mengalami error resource exceeded di BigQuery, coba gunakan tabel sementara untuk membagi kueri menjadi beberapa kueri BigQuery.
  • Mereferensikan lebih sedikit tabel dalam satu kueri, karena hal ini menggunakan memori dalam jumlah besar dan dapat menyebabkan kueri Anda gagal.
  • Menulis ulang kueri sehingga bergabung dengan lebih sedikit tabel pengguna.
  • Menulis ulang kueri untuk menghindari penggabungan tabel yang sama kembali ke dirinya sendiri.

Penasihat kueri

Jika SQL Anda valid, tetapi mungkin memicu pemfilteran yang berlebihan, penasihat kueri akan menampilkan saran yang dapat ditindaklanjuti selama proses pengembangan kueri, untuk membantu Anda menghindari hasil yang tidak diinginkan.

Pemicu mencakup pola berikut:

Untuk menggunakan konsultan kueri: