Önce sorgulanacak kararı belirleyin
BigQuery bağlantısı yalnız daha gelişmiş görünsün diye kurulmaz. Sipariş olaylarını iç satış kayıtlarıyla karşılaştırmak, olay parametrelerini ayrıntılı incelemek veya tutarlı bir rapor veri modeli oluşturmak somut ihtiyaç olabilir. Standart rapor soruyu zaten yanıtlıyorsa yeni veri ambarı bakım yükü yaratabilir. Başlangıçta sorgu örneği, gerekli alanlar ve veri sorumlusu yazılmalıdır.
Ham olay ile arayüz raporu aynı tablo değildir
Google Analytics, topladığı ham olayları BigQuery’ye aktarabilir. GA4 arayüzündeki modelleme, kapsam ve raporlama mantığıyla ham olay sorgusu otomatik aynı sonucu vermez. Bu yüzden aktarılan satırların toplamını paneldeki kullanıcı ya da gelir kartıyla doğrudan eşitlemeyin. Sorguda olay adı, tarih, zaman dilimi ve kullanıcı/oturum tanımı açık olmalıdır.
Yetki ve maliyet kabulünü yapın
Bulut projesinin sahibi, faturalandırma sorumlusu, veri seti erişimleri ve saklama yaklaşımı işletmede kalmalıdır. Export seçeneği, veri hacmi ve sorgulama maliyeti ayrı incelenir; sandbox veya ücretsiz sınır bütün projelerin masrafsız olduğu anlamına gelmez. Gerekli kişilere en dar erişim verin. Analitiğe alınmaması gereken kişisel veri, BigQuery’ye taşınarak uygun hâle gelmez.
Aktarımın çalıştığını kanıtlayın
Seçili bir gün için beklenen olay adlarını, sipariş kimliklerini, tekrarları ve eksik parametreleri örnekleyin. Günlük ve varsa gün içi veriyi gelişigüzel birleştirerek aynı olayı iki kez saymayın. Kabul dosyasında çalışan sorgu, tarih aralığı, bilinen farklar ve bakım sahibi bulunur. BigQuery bağlantısının açılması tek başına sağlıklı veri veya daha fazla müşteri kanıtı değildir.