Praktik terbaik

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

Privasi dan akurasi data

Mengembangkan kueri pada data sandbox

Praktik terbaik: Hanya kueri data produksi saat Anda berada dalam produksi.

Gunakan data sandbox selama pengembangan kueri 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 kecocokan), 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 set hasil antara kueri yang baru saja dijalankan.

Perlu diingat bahwa laju perubahan antara hasil kueri akan memengaruhi kemungkinan hasil dihilangkan di kemudian hari karena pemeriksaan privasi. Kumpulan hasil kedua yang sangat menyerupai 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 kueri data hari ini

Praktik terbaik: Jangan jalankan 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 menjalankan kueri segera setelah tengah malam pada data kemarin.

Jangan kueri data yang sama lebih dari yang diperlukan

Praktik terbaik:

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

Ads Data Hub membatasi jumlah total kueri yang dapat Anda lakukan pada data yang sama. Oleh karena itu, Anda harus berupaya membatasi frekuensi Anda mengakses data tertentu.

Jangan gunakan lebih banyak agregasi daripada 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 kami merekomendasikan penulisan kueri yang menghasilkan lebih banyak baris dengan kunci pengelompokan yang terfokus dan agregasi sederhana, 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 diagregasi dengan cara yang sama di BigQuery.

Kueri yang membuat kolom dari array, lalu menggabungkannya 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 berbagai kombinasi kolom dalam berbagai agregasi 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 skemanya kompatibel.

Mengoptimalkan dan memahami gabungan

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.

Gambar yang menampilkan beberapa jenis gabungan 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 diagregasi dengan baris yang cukup diagregasi, baris yang dihasilkan akan difilter. Selain itu, kueri dengan beberapa agregasi kurang berperforma 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 berbagi skema akhir.

Kueri berikut mengambil hasil Ads Data Hub individual (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 umum. Meskipun data yang difilter tidak dapat dianalisis lebih lanjut, data tersebut memberikan ringkasan tentang jumlah data yang difilter dari hasil.

Memperhitungkan ID pengguna yang bernilai nol

Praktik terbaik: Perhitungkan ID pengguna yang bernilai nol dalam hasil Anda.

ID pengguna akhir dapat disetel ke 0 karena sejumlah alasan, termasuk: memilih tidak ikut personalisasi iklan, alasan peraturan, dll. Dengan demikian, data yang berasal dari beberapa pengguna akan dikaitkan dengan 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 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 penggabungan ulang

Praktik terbaik: Hindari beberapa lapisan agregasi di seluruh pengguna.

Kueri yang menggabungkan hasil yang telah diagregasi, 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 menyimpan 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 dipecah dengan mudah 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-faktor berikut:

Jika eksekusi kueri tidak memenuhi perjanjian tingkat layanan Anda, 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 subkueri logis (seperti membagi beberapa gabungan menjadi beberapa kueri), atau membatasi set data yang sedang diproses. Anda dapat menggabungkan hasil dari setiap tugas ke dalam satu set data di BigQuery. Meskipun dapat membantu mengatasi kelelahan resource, hal ini dapat memperlambat kueri Anda.
  • Jika Anda mengalami error karena resource yang terlampaui di BigQuery, coba gunakan tabel sementara untuk membagi kueri menjadi beberapa kueri BigQuery.
  • Mereferensikan lebih sedikit tabel dalam satu kueri, karena hal ini menggunakan sejumlah besar memori dan dapat menyebabkan kueri Anda gagal.
  • Menulis ulang kueri sehingga menggabungkan lebih sedikit tabel pengguna.
  • Menulis ulang kueri untuk menghindari penggabungan tabel yang sama dengan dirinya sendiri.

Penasihat kueri

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

Pemicunya mencakup pola berikut:

Untuk menggunakan penasihat kueri: