Aşağıdaki en iyi uygulamalarda, gizlilik odaklı ve yüksek performanslı sorgular geliştirmek için kullanabileceğiniz teknikler sunulmaktadır.
Gizlilik ve verilerin doğruluğu
Korumalı alan verileri üzerinde sorgu geliştirin
En iyi uygulama: Üretim ortamındayken yalnızca üretim verilerini sorgulayın.
Mümkün olduğunda sorgu geliştirmeniz sırasında korumalı alan verilerinden yararlanın. Korumalı alan verilerini kullanan işler, sorgu sonuçlarınızı filtrelemek üzere farklılık kontrolleri için ek fırsatlar sunmaz. Ayrıca, gizlilik kontrolü eksikliği nedeniyle korumalı alan sorguları daha hızlı çalışarak sorgu geliştirme sırasında daha hızlı iterasyon sağlar.
Gerçek verilerinizde (eşleşme tablolarını kullanırken olduğu gibi) sorgu geliştirmeniz gerekiyorsa satırların çakışma olasılığını azaltmak için tarih aralıklarını ve diğer parametreleri sorgunuzun her iterasyonuyla çakışma olasılığı düşük olacak şekilde seçin. Son olarak, sorgunuzu istediğiniz veri aralığı üzerinde çalıştırın.
Geçmiş sonuçları dikkatle değerlendirin
En iyi uygulama: Son çalıştırılan sorgular arasında sonuç kümesi çakışma olasılığını azaltın.
Sorgu sonuçları arasındaki değişiklik oranının, daha sonra gizlilik kontrolleri nedeniyle sonuçlara dahil edilmeme olasılığını etkileyebileceğini unutmayın. Kısa süre önce döndürülen bir sonuç kümesine benzeyen ikinci bir sonuç kümesinin atlanma olasılığı yüksektir.
Bunun yerine, önemli ölçüde çakışma olasılığını azaltmak için sorgunuzdaki tarih aralıkları veya kampanya kimlikleri gibi temel parametreleri değiştirin.
Bugünün verileri üzerinde sorgu çalıştırmayın
En iyi uygulama: Bitiş tarihi bugün olduğunda birden fazla sorgu çalıştırmayın.
Bitiş tarihleri bugün olan birden fazla sorgu çalıştırıldığında, genellikle satırlar filtrelenir. Bu kılavuz, dünün verilerinde gece yarısından kısa bir süre sonra sorguların çalıştırılması için de geçerlidir.
Aynı verileri gereğinden fazla sorgulamayın
En iyi uygulamalar:
- Oldukça yakın başlangıç ve bitiş tarihleri seçin.
- Çakışan aralıkları sorgulamak yerine, sorgularınızı ayrı veri kümelerinde çalıştırın ve sonuçları BigQuery'de birleştirin.
- Sorgunuzu yeniden çalıştırmak yerine kayıtlı sonuçları kullanın.
- Sorguladığınız her tarih aralığı için geçici tablolar oluşturun.
Ads Data Hub, aynı verileri toplam kaç kez sorgulayabileceğinizle ilgili bir sınır uygular. Bu nedenle, belirli bir veriye erişim sayınızı sınırlamaya çalışmalısınız.
Aynı sorguda gereğinden fazla toplama kullanmayın
En iyi uygulamalar:
- Bir sorgudaki toplama sayısını en aza indirin
- Mümkün olduğunda toplamaları birleştirmek için sorguları yeniden yazın
Ads Data Hub, bir alt sorguda kullanılmasına izin verilen kullanıcılar arası toplama sayısını 100 ile sınırlandırır. Bu nedenle, genel gruplandırma anahtarları ve karmaşık toplamalar içeren daha fazla sütun yerine, odaklanmış gruplandırma anahtarları ve basit toplamalar içeren daha fazla satır üreten sorgular yazmanız önerilir. Aşağıdaki kalıbı kullanmaktan kaçınmalısınız:
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
Etkinlikleri aynı alan grubuna göre sayan sorgular GROUP BY ifadesi kullanılarak yeniden yazılmalıdır.
SELECT
field_1,
field_2,
COUNT(1) AS cnt
FROM
table
GROUP BY
1, 2
Sonuç, BigQuery'de aynı şekilde toplanabilir.
Bir diziden sütun oluşturan ve daha sonra bu sütunları toplayan sorgular, bu adımları birleştirmek için yeniden yazılmalıdır.
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)
Önceki sorgu şu şekilde yeniden yazılabilir:
SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1
Farklı toplamalarda farklı alan kombinasyonlarını kullanan sorgular, daha odaklanmış sorgular olarak yeniden yazılabilir.
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
Önceki sorgu şu bölümlere ayrılabilir:
SELECT
field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1
ve
SELECT
field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1
Bu sonuçları ayrı sorgulara bölebilir, tabloları tek bir sorguda oluşturup birleştirebilir veya şemalar uyumluysa UNION ifadesi ile birleştirebilirsiniz.
Birleştirmeleri optimize edin ve anlayın
En iyi uygulama: Tıklamaları veya dönüşümleri gösterimlerle birleştirmek için INNER JOIN
yerine LEFT JOIN
kullanın.
Tüm gösterimler, tıklama veya dönüşümlerle ilişkilendirilmez. Bu nedenle, gösterimlerde INNER JOIN
tıklama veya gösterim olursa tıklamalar veya dönüşümlerle bağlantılı olmayan gösterimler sonuçlarınızdan filtrelenir.
BigQuery'deki bazı nihai sonuçları birleştirin
En iyi uygulama: Toplanan sonuçları birleştiren Ads Data Hub sorgularından kaçının. Bunun yerine 2 ayrı sorgu yazın ve sonuçları BigQuery'de birleştirin.
Toplama koşullarını karşılamayan satırlar filtrelenir. Bu nedenle, sorgunuz yeterince toplanmamış bir satırla yeterince toplanmış bir satırı birleştirirse ortaya çıkan satır filtrelenir. Ayrıca, birden fazla toplama içeren sorgular Ads Data Hub'da daha düşük performans gösterir.
Birden fazla toplama sorgusundan (Ads Data Hub'dan) gelen sonuçları birleştirebilirsiniz (BigQuery'de). Sık görülen sorgular kullanılarak hesaplanan sonuçlar nihai şemaları paylaşır.
Aşağıdaki sorguda, ayrı Ads Data Hub sonuçları (campaign_data_123
ve campaign_data_456
) BigQuery'de birleştirilmektedir:
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)
Filtrelenmiş satır özetlerini kullanın
En iyi uygulama: Sorgularınıza filtrelenmiş satır özetleri ekleyin.
Filtrelenmiş satır özetleri, gizlilik kontrolleri nedeniyle filtrelenen verileri bir araya getirir. Filtrelenmiş satırlardaki veriler toplanır ve her şeyi içeren bir satıra eklenir. Filtrelenmiş verilerin daha fazla analiz edilememesine rağmen sonuçlardan ne kadar verinin filtrelendiğine dair bir özet sağlanır.
Sıfırlanmış kullanıcı kimliklerini hesaba katın
En iyi uygulama: Sonuçlarınızda sıfırlanan kullanıcı kimliklerini hesaba katın.
Son kullanıcının kimliği, reklam kişiselleştirmenin devre dışı bırakılması, düzenlemelerle ilgili nedenler gibi çeşitli nedenlerle 0 olarak ayarlanmış olabilir. Bu nedenle, birden fazla kullanıcıdan gelen verilerde user_id
0 olarak ayarlanır.
Toplam gösterim sayısı veya tıklama sayısı gibi veri toplamlarını anlamak istiyorsanız bu etkinlikleri dahil etmeniz gerekir. Ancak bu veriler, müşteriler hakkında bilgi edinmek için kullanışlı olmaz ve böyle bir analiz yapıyorsanız filtrelenmelidir.
Sorgularınıza WHERE user_id != "0"
ekleyerek bu verileri sonuçlarınızdan hariç tutabilirsiniz.
Performans
Yeniden toplamadan kaçının
En iyi uygulama: Kullanıcılar arasında birden fazla toplama katmanı kullanmaktan kaçının.
Birden fazla GROUP BY
içeren sorgu veya iç içe toplama gibi daha önce toplanmış sonuçları birleştiren sorguların işlenmesi için daha fazla kaynak gerekir.
Çoğu zaman, birden fazla toplama katmanı içeren sorgular bölünerek performans artırılabilir. İşleme sırasında satırları etkinlik veya kullanıcı düzeyinde tutmaya çalışmanız ve ardından tek bir toplamada birleştirmeniz gerekir.
Aşağıdaki kalıplardan kaçınılmalıdır:
SELECT SUM(count)
FROM
(SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)
Birden fazla toplama katmanı kullanan sorgular, tek bir toplama katmanı kullanacak şekilde yeniden yazılmalıdır.
(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )
Kolayca bölünebilecek sorgular ayrılmalıdır. Sonuçları BigQuery'de birleştirebilirsiniz.
BigQuery için optimizasyon yapın
Genelde, daha az işlem yapan sorgular daha iyi performans gösterir. Sorgu performansını değerlendirirken gereken iş miktarı şu faktörlere bağlıdır:
- Giriş verileri ve veri kaynakları (G/Ç): Sorgunuz kaç bayt okuyor?
- Düğümler arasındaki iletişim (karıştırma): Sorgunuz bir sonraki aşamaya kaç bayt aktarıyor?
- Hesaplama: Sorgunuz için ne kadar CPU çalışması gerekiyor?
- Çıkışlar (gerçekleştirme): Sorgunuz kaç bayt yazıyor?
- Kalıp dışı verileri sorgulama: Sorgularınız SQL en iyi uygulamalarına uygun mu?
Sorgu yürütme, hizmet düzeyi sözleşmelerinizi karşılamıyorsa veya kaynakların tükenmesi ya da zaman aşımı nedeniyle hata alıyorsanız şunları deneyebilirsiniz:
- Yeniden hesaplama yerine önceki sorgulara ait sonuçları kullanın. Örneğin, haftalık toplamınız 7 tek günlük toplama sorgusunun BigQuery'de hesaplanan toplamı olabilir.
- Sorguları mantıksal alt sorgulara ayırın (birden çok birleştirmeyi birden fazla sorguya bölme gibi) veya işlenmekte olan veri kümesini başka şekilde kısıtlayın. Bağımsız işlerin sonuçlarını BigQuery'de tek bir veri kümesinde birleştirebilirsiniz. Bu durum, kaynak kullanımını azaltsa da sorgunuzu yavaşlatabilir.
- BigQuery'de kaynak aşım hatalarıyla karşılaşıyorsanız sorgunuzu birden fazla BigQuery sorgusuna bölmek için geçici tablolar kullanmayı deneyin.
- Çok fazla bellek kullandığı ve sorgunuzun başarısız olmasına neden olabileceği için tek bir sorguda daha az tabloya referans verin.
- Sorgularınızı daha az kullanıcı tablosunu birleştirecek şekilde yeniden yazın.
- Sorgularınızı aynı tablonun kendisiyle birleştirilmesini önleyecek şekilde yeniden yazın.
Sorgu danışmanı
SQL'iniz geçerliyse ancak aşırı filtrelemeyi tetikleyebiliyorsa sorgu danışmanı, istenmeyen sonuçlardan kaçınmanıza yardımcı olmak için sorgu geliştirme süreci sırasında uygulanabilir öneriler gösterir.
Tetikleyiciler aşağıdaki kalıpları içerir:
- Toplu alt sorgulara katılma
- Birleştirilmemiş verileri potansiyel olarak farklı kullanıcılarla birleştirme
- Yinelemeli olarak tanımlanmış geçici tablolar
Sorgu danışmanını kullanmak için:
- Kullanıcı arayüzü. Öneriler, sorgu düzenleyicide sorgu metninin üzerinde gösterilir.
- API.
customers.analysisQueries.validate
yöntemini kullanın.