Pazarlama olaylarını sunucuda toplamak: Bir geliştiricinin kontrol listesi

Pazarlama ekibi "dönüşümler panelde düşük görünüyor" dediğinde, sorun çoğu zaman kampanyada değil, verinin yolculuğundadır. Tarayıcıda çalışan izleme kodları reklam engelleyicilere, Safari'nin çerez kısıtlamalarına ve onay bannerlarına takılır. Sonuçta reklam panelindeki sayı ile CRM'deki gerçek satış birbirinden uzaklaşır.

Koray Yalçın'ın GA4, PostHog ve CDP üzerine yazdığı mimari yazısı bu tabloyu üst seviyeden anlatıyor: birinci taraf veri toplama, sunucu taraflı etiketleme, merkezi veri ambarı ve Reverse ETL ile verinin CRM'e ve reklam platformlarına geri yazılması. Ben bu yazıda aynı mimariye geliştirici koltuğundan bakmak ve işi yaparken sık atlanan teknik noktaları bir kontrol listesine dökmek istiyorum.

1. Olayı bir kez tanımla, her yere aynı adla gönder

Sunucu taraflı kurulumda en büyük kazanç, tek bir olay şemasından GA4'e, ürün analitiğine ve reklam platformlarına dağıtım yapabilmektir. Bunun çalışması için olay adlarının ve alanlarının baştan sabitlenmesi gerekir. form_submit, formSubmitted ve lead aynı şeyi anlatıyorsa, üç ayrı rapor ve üç ayrı tartışma doğar.

Pratik öneri: olay sözlüğünü kodla birlikte versiyonlayın. Basit bir JSON şeması ya da TypeScript tipi bile, yeni bir alan eklendiğinde kimin neyi bozduğunu görmenizi sağlar.

2. Kişisel veriyi tarayıcıdan dışarı çıkarmayın

E-posta ve telefon gibi kişisel verileri doğrudan üçüncü taraf betiklere vermek yerine, kendi sunucunuza alın, normalize edin ve hash'leyin. Burada en sık hata normalizasyonu atlamaktır: büyük harf, baştaki boşluk ya da ülke kodu farkı, aynı kişiyi farklı bir hash'e dönüştürür ve eşleşme oranı sessizce düşer.

import hashlib

def normalize_email(email: str) -> str:
    return email.strip().lower()

def normalize_phone(phone: str, default_cc: str = "90") -> str:
    digits = "".join(ch for ch in phone if ch.isdigit())
    if digits.startswith("0"):
        digits = default_cc + digits[1:]
    return digits

def sha256(value: str) -> str:
    return hashlib.sha256(value.encode("utf-8")).hexdigest()

Bu adım aynı zamanda KVKK ve GDPR açısından da savunulabilir bir sınır çizer: ham veri sizin altyapınızda kalır, dışarıya yalnızca gerekli ve dönüştürülmüş alanlar çıkar. Hangi alanın hangi hedefe gittiğini bir tabloda belgelemek, denetim günü işinizi çok kolaylaştırır.

3. Çift sayımı event_id ile önleyin

Geçiş döneminde hem tarayıcı pikseli hem sunucu çağrısı aynı dönüşümü gönderir. Reklam platformlarının çoğu bu ikisini ortak bir olay kimliğiyle eşleştirip tekilleştirir. Kimliği istemcide üretip hem piksele hem sunucu isteğine aynı değeri taşımazsanız, dönüşümler bir anda iki katına çıkar ve kimse bunun bir hata olduğunu hemen fark etmez.

4. Alt alan adını ve gecikmeyi ciddiye alın

Toplayıcıyı data.alanadiniz.com gibi kendi alt alan adınızda çalıştırmak, isteklerin birinci taraf olarak işlenmesine yardım eder. Ama bu sunucu artık sizin üretim altyapınızın parçasıdır: izleme, alarm ve hata günlüğü ister. Toplayıcı çöktüğünde veri sessizce kaybolur; sağlık kontrolü ve kuyruk (retry) mekanizması olmadan kurulan bir sunucu taraflı izleme, tarayıcı tarafındakinden daha kırılgan olabilir.

5. Ürün olaylarını pazarlama verisiyle aynı kimlikte buluşturun

GA4 "ziyaretçi nereden geldi" sorusuna, PostHog gibi ürün analitiği araçları ise "geldikten sonra ne yaptı" sorusuna cevap verir. İkisini anlamlı kılan şey ortak bir kullanıcı ya da hesap kimliğidir. Kayıt anında anonim kimliği gerçek kullanıcı kimliğiyle birleştirmeyi (identify) unutmak, huniyi ortadan ikiye böler.

6. Veri ambarı tek doğruluk kaynağı olsun

BigQuery ya da Snowflake gibi bir ambarda modellenen veri, Reverse ETL araçlarıyla CRM'e ve reklam kitlelerine geri yazılabilir. Geliştirici açısından kritik nokta, bu senkronizasyonların da kod gibi yönetilmesidir: SQL modelleri versiyon kontrolünde, test edilmiş ve sahibi belli olmalı.

Kapanış

Sunucu taraflı izleme bir etiket yöneticisi ayarı değil, küçük bir veri ürünüdür. Olay sözlüğü, hash normalizasyonu, tekilleştirme ve gözlemlenebilirlik doğru kurulduğunda pazarlama ile finansın gördüğü sayılar birbirine yaklaşır.

Mimarinin tamamını, GA4 ve PostHog karşılaştırmasını ve Composable CDP yaklaşımını kaynak yazıda okuyabilirsiniz: Modern Pazarlama ve Büyüme Analitiği: GA4, PostHog ve CDP Veri Mimarisi