Bir Event, On Hedef: Server-Side Veri Yönlendirme Neden Bu Kadar Karmaşık?

Aynı Satın Alma, Kaç Farklı Sisteme Bildirmek Gerekiyor?

Bir e-ticaret sitesinde kullanıcı siparişi tamamladı. Bu bilgi kaç yere gitmeli?

• Google Ads'e (dönüşüm bildirimi, teklif optimizasyonu için)
• Meta'ya (Pixel veya CAPI üzerinden, kampanya optimizasyonu için)
• GA4'e (analitik, kullanıcı davranışı için)
• TikTok, LinkedIn veya Pinterest'e (kullanlandığına göre)
• CRM'e (müşteri kaydı oluşturmak için)
• Email platformuna (onboarding akışını tetiklemek için)
• İç analitik sistemine veya data warehouse'a (raporlama için)

Yedi farklı hedef. Bazı şirketlerde bu sayı on ikiye, on beşe çıkıyor.

Her hedefin farklı beklentileri var: farklı veri formatı, farklı kimlik doğrulama yöntemi, farklı şema, farklı deduplication mantığı, farklı consent gereksinimleri.

Peki tüm bunları aynı anda, tutarlı biçimde, her seferinde doğru kurgulamak ne kadar zor? İşte bu yazı o soruyu yanıtlamak için.

---

Sorun: "Event Spaghetti"

Birçok şirkette dönüşüm takibi şöyle gelişir:

İlk yıl bir ajans Google Ads kurulumunu yapıyor. Dönüşüm etiketini GTM'e ekliyor. Bir süre sonra Meta Pixel ekleniyor. Sonra GA4 geliştirilmesi için başka bir ekip devreye giriyor. Bir yıl sonra TikTok Pixel ekleniyor. İki yıl sonra email platformu için form doldurma event'i ekleniyor.

Her ekleme birbirinden habersiz yapılmış. GTM container'da onlarca etiket, yarısı aktif yarısı deaktifte. Aynı dönüşüm birden fazla kez sayılıyor. Bazı eventler sadece belirli tarayıcılarda çalışıyor. Consent olmadan veri gönderiliyor.

Teknik terim yok, sektör jargonu yok — buna basitçe "event spaghetti" denilebilir. Karışık, kopuk, tutarsız bir event altyapısı.

Bu durum o kadar yaygın ki, yeni bir müşteriyle çalışmaya başladığımızda ilk adımımız neredeyse her zaman mevcut durumun haritasını çıkarmak oluyor. Ve harita her seferinde beklenenden daha karmaşık çıkıyor.

---

Neden Düzeltmek Bu Kadar Zor?

Sorun teknik değil, yapısal. Birkaç farklı katmanda birden birikmiş.

Sorumluluk dağılımı: Reklam ekibi kendi platformunu yönetiyor, analitik ekibi GA4'ü, veri ekibi warehouse'u, ürün ekibi uygulamayı. Kimse tam resmi görmüyor. Herkes kendi parçasını "düzgün" çalıştırıyor ama bütün tutarsız.

Birikmiş teknik borç: Yıllar içinde eklenen her etiket bir öncekini etkiliyor. Birini değiştirdiğinizde başka bir şeyin bozulduğunu ancak sonradan fark ediyorsunuz.

Platform farklılıkları: Meta'nın CAPI'si hashed email istiyor. Google Enhanced Conversions farklı bir format bekliyor. TikTok Events API'si başka bir şema kullanıyor. Her platform için event'i yeniden biçimlendirmek gerekiyor.

Consent karmaşası: GDPR ve KVKK kapsamında, kullanıcının rızası olmadan hangi platformlara hangi veriyi gönderebileceğiniz net olmalı. Ama çoğu sistemde consent durumu ile event gönderimi birbirinden kopuk işliyor.

---

Server-Side Mimari: Çözüm mü, Yeni Bir Karmaşıklık mı?

Server-side tracking son birkaç yılda standart hale geldi. Mantığı sade: event'i kullanıcının tarayıcısından değil, sizin sunucunuzdan gönderiyorsunuz. Tarayıcı kısıtlamalarını aşıyor, reklam engelleyicilerden etkilenmiyor, veri kalitesi artıyor.

Ama server-side sadece bir "daha iyi tarayıcı takibi" değil. Doğru kurgulandığında mimarinin tam merkezine oturuyor:

Kullanıcı Eylemi (web / uygulama / mağaza)
           ↓
    Merkezi Event Toplama
           ↓
   [Dönüşüm Katmanı]
   ├── Consent kontrolü
   ├── Kimlik çözümleme
   ├── Deduplication (event_id atama)
   └── Platform formatına dönüştürme
           ↓
   ┌───────────────────────┐
   │ Meta CAPI             │
   │ Google Enhanced Conv. │
   │ GA4 Measurement Prot. │
   │ TikTok Events API     │
   │ CRM / Email           │
   │ Data Warehouse        │
   └───────────────────────┘

Bu mimaride her platform için ayrı ayrı etiket yazmak yerine, tek bir event toplanıyor ve ortak bir katmandan her platforma uygun biçimde dağıtılıyor.

Teoride harika. Pratikte dikkat edilmesi gereken birkaç kritik nokta var.

---

Kritik Nokta 1: Deduplication ve Event ID Yönetimi

Aynı dönüşümü hem browser'dan hem de server'dan gönderiyorsanız — ki bu geçiş döneminde yaygın bir yaklaşım — çift sayım riski var.

Meta bunu şöyle çözüyor: hem browser Pixel'den hem de CAPI'den gelen event'lere aynı event_id değeri verildiğinde, Meta bu ikisini tek bir dönüşüm olarak sayıyor. Google benzer bir mekanizma kullanıyor.

Ama bu event_id değeri tutarlı, benzersiz ve her platform için doğru formatta iletilmek zorunda. Üretim ortamında bu basit görünen gereksinim, farklı sistemlerin farklı UUID formatları kullandığı, zaman damgalarının uyuşmadığı veya aynı sipariş için farklı ID'lerin üretildiği durumlarda gerçek bir sorun haline geliyor.

Deduplication test edilmeden canlıya alınan her server-side kurulum, bir süre sonra reklam platformlarında şişirilmiş dönüşüm rakamları üretiyor. Ve bu fark genellikle hemen fark edilmiyor.

---

Kritik Nokta 2: Consent Akışının Server Katmanına Taşınması

Server-side tracking bir güvenlik şalteri değil. Kullanıcı izin vermemişse, verinin sunucudan gönderilmesi de yasal sorumluluğu ortadan kaldırmıyor.

2026'da doğru kurgu şu şekilde çalışmalı:

Kullanıcının consent durumu — hangi kategoriye izin verdi, hangi kategoriye vermedi — event'e birlikte taşınmalı. Server katmanındaki yönlendirici, bu consent durumuna bakarak hangi platforma event göndereceğine karar vermeli.

Örnek: Kullanıcı "analitik çerezler" için izin verdi ama "pazarlama çerezleri" için vermedi. Bu durumda GA4'e event gönderilebilir ama Meta CAPI'ye gönderilemez.

Bu mantığın çalışması için:

1. CMP (Consent Management Platform) consent durumunu doğru biçimde üretiyor olmalı
2. Bu consent sinyali event ile birlikte server katmanına taşınmalı
3. Server katmanı her platform için consent kontrolünü uygulamalı

Bu zincirden herhangi bir halka eksikse, "server-side geçtik, sorun yok" demek doğru değil.

---

Kritik Nokta 3: Hashed First-Party Data ve Eşleşme Kalitesi

Meta CAPI ve Google Enhanced Conversions'ın temel değeri, reklam platformlarının kullanıcıyı kendi veri tabanlarında eşleştirmesine olanak tanımak. Bunun için hashed (karma) birinci taraf veri gönderiliyor: SHA-256 ile şifrelenmiş email adresi, telefon numarası veya ad-soyad kombinasyonu.

Eşleşme oranı (match rate veya Event Match Quality) ne kadar yüksekse, platform o kadar doğru optimizasyon yapıyor.

Bu oranı etkileyen faktörler:

• Kaç alanda veri gönderiliyor? (sadece email mi, aynı zamanda telefon ve adres de var mı?)
• Veri normalleştirilmiş mi? (küçük harf, boşluksuz, ülke kodu dahil telefon formatı)
• Hashing doğru uygulanmış mı? (SHA-256, hex çıktısı)
• Kullanıcının platform hesabındaki veriyle ne kadar örtüşüyor?

2026'da Meta Events Manager üzerinden EMQ (Event Match Quality) skoru takip edilebiliyor. Düşük skor, kampanya optimizasyonunu doğrudan etkiliyor. Ama çoğu şirket bu skoru hiç kontrol etmeden aylarca kötü veri kalitesiyle çalışıyor.

---

Çevrimdışı-Çevrimiçi Birleştirme: En Zor Halka

Şimdiye kadar anlattığımız her şey çevrimiçi ortamı kapsıyordu. Ama birçok şirket için dönüşümün bir kısmı — bazen büyük bir kısmı — çevrimdışında gerçekleşiyor.

Kullanıcı sitede araştırıyor, mağazada satın alıyor. Ya da çevrimiçi form dolduruyor, satış ekibinden arama alıyor, telefonda anlaşıyor. Ya da online reklam görüyor, üç gün sonra fiziksel mağazaya gidip ürünü alıyor.

Bu dönüşümler ölçülmediğinde:

• Kampanyalar mağazaya trafik gönderdiğini bilmiyor, dijital kanal için yatırım yetersiz görünüyor
• ROAS hesapları sadece çevrimiçi dönüşümleri yansıtıyor, gerçek değer gözden kaçıyor
• Hangi dijital temas noktasının satışı etkilediği bilinmiyor

Bu boşluğu kapatmanın teknik yolu, çevrimiçi ve çevrimdışı veriyi ortak bir kimlik üzerinden birleştirmek.

GA4 Measurement Protocol ve Google Ads Offline Conversion

Google'ın sunduğu yol şu:

Kullanıcı siteyi ziyaret ettiğinde, GA4 tarafından bir client_id (veya sisteminizde user_id) üretiliyor. Bu kimlik o oturuma ait.

Fiziksel mağazada satış gerçekleştiğinde — kasa sisteminden, CRM'den veya satış ekibinin kullandığı uygulamadan — bu kimlik kayıt altındaysa, GA4 Measurement Protocol üzerinden çevrimdışı dönüşüm bildirimi yapılabiliyor. GA4, çevrimiçi oturumu bu satışla ilişkilendiriyor.

Google Ads tarafında ise "Offline Conversion Import" veya Enhanced Conversions for Leads yöntemiyle aynı dönüşüm, teklif optimizasyonuna dahil edilebiliyor.

Bu entegrasyonun çalışması için bir şart var: müşterinin çevrimiçi kimliği ile çevrimdışı işlem arasında bir köprü olmalı. Bu köprü genellikle şunlardan biri:

• Loyalty kart numarası: Hem çevrimiçi hem mağazada kullanılan ortak kimlik
• Email adresi: Online kayıtta ve kasada alınan, hashed olarak eşleştirilen
• Telefon numarası: Benzer mantıkla
• Sipariş veya teklif ID'si: B2B'de sık kullanılan, CRM'de oluşturulan

Bu köprü yoksa entegrasyon teknik olarak mümkün ama anlamlı olmayan sonuçlar üretiyor. Dolayısıyla offline conversion projesine başlamadan önce "ortak kimliği nasıl oluşturacağız?" sorusu yanıtlanmış olmalı.

---

Sektörel Zorluklar: Herkesin Problemi Aynı Değil

Bu konuyu farklı sektörlerde karşılaştığımızda sorunun biçimi değişiyor.

Perakende ve e-ticaret: Çevrimiçi ve fiziksel kanal iç içe geçmiş. "Click & collect" alışveriş modeli, mağaza stok sorgulama, kasa entegrasyonu — bunların hepsi ayrı sistemler ve aralarında veri köprüsü kurulmuş olması şart. Loyalty programı varsa çözüm kolaylaşıyor; yoksa ortak kimlik sorunuyla başa baş kalınıyor.

Otomotiv ve dayanıklı tüketim: Satın alma kararı uzun sürüyor. Kullanıcı reklam görüyor, bayi ziyareti yapıyor, aylar sonra satın alıyor. Dijital temas ile nihai satış arasındaki zaman aralığı standart attribution pencerelerini aşıyor. Çözüm: CRM'i veri merkezine bağlamak, her müşteri temas noktasını kayıt altına almak, uzun attribution pencereleriyle çalışmak.

Finans ve sigorta: Kullanıcı formu dolduruyor ama dönüşüm aylar sonra poliçe imzalandığında gerçekleşiyor. Lead → müşteri dönüşümünü dijital kanala atfetmek için CRM entegrasyonu zorunlu. Aynı zamanda gizlilik gereksinimleri en yüksek bu sektörde — hangi verinin reklam platformuna gönderildiği BDDK ve KVKK kapsamında yakından takip ediliyor.

B2B ve SaaS: Satın alan kişi ile kullanıcı çoğunlukla farklı. Bir şirketten birden fazla kişi araştırma yapıyor, karar farklı biri tarafından veriliyor. Kişi bazlı identity stitching yetmiyor; hesap (account) bazlı birleştirme gerekiyor. Üstelik satış döngüsü aylar alabiliyor — standart 90 günlük attribution pencereleri bu senaryolarda yetersiz kalıyor.

---

Mevcut Tablonuzu Değerlendirmek: Ne Sorulmalı?

Bu noktada hangi şirketin nerede durduğunu anlamak için doğru soruları sormak gerekiyor. Çoğunlukla teknik ekiplerle yaptığımız keşif görüşmelerinde şu sorular netlik sağlıyor:

Mevcut durum:

• Hangi platformlara dönüşüm bildirimi yapılıyor ve bu bildirimler nasıl gerçekleşiyor (browser etiket, server-side, her ikisi)?
• Aynı dönüşüm birden fazla kez sayılıyor mu? Bunu kontrol eden bir mekanizma var mı?
• GTM container'ınızda kaç aktif etiket var? En son ne zaman temizlik yapıldı?

Veri kalitesi:

• Meta EMQ skorunuz nedir? Son üç ayda değişti mi?
• Google Ads'teki dönüşüm aksiyonlarından kaçı "primary conversion" olarak işaretlenmiş?
• GA4'teki dönüşüm rakamı ile Google Ads'teki rakam arasında fark var mı? Bu fark açıklanabiliyor mu?

Çevrimdışı bağlantı:

• Mağaza satışlarınız var mı? Bu satışlar herhangi bir dijital kanalla ilişkilendiriliyor mu?
• CRM'inizde, müşteriyle ilk dijital temas noktasına ait bir kayıt var mı?
• Satış ekibi bir CRM kullanıyor mu ve bu CRM hangi sistemlerle entegre?

Gizlilik ve consent:

• Consent Mode aktif mi? Default state doğru ayarlanmış mı?
• Kullanıcı pazarlama reklam izni vermediğinde, sunucudan Meta veya Google'a event gönderiliyor mu?

Bu soruların yanıtları çoğu zaman şirketlerin beklediğinden farklı bir tablo ortaya koyuyor.

---

Neler Yapılabilir: Adım Adım Bir Yol

Her şirkette başlangıç noktası farklı ama genel olarak sıralama şöyle oluşuyor:

1. Mevcut durumu haritalama: GTM container denetimi, aktif event'lerin listesi, her platformda hangi dönüşümlerin sayıldığı, olası çift sayım noktaları. Bu adım olmadan hiçbir müdahale güvenilir değil.

2. Dönüşüm tanımlarını sabitleme: Hangi aksiyonlar "dönüşüm" sayılacak, bunların her platformdaki karşılığı ne, primary ve secondary dönüşüm ayrımı nasıl yapılacak. Teknik ekip + pazarlama ekibinin ortak kararı gerekiyor.

3. Server-side katmanı kurma veya güçlendirme: Ortak bir event toplama ve dağıtım katmanı. Her platforma event göndermeden önce consent kontrolü, kimlik eşleştirme ve format dönüşümü bu katmanda yapılıyor.

4. Deduplication ve event_id yönetimi: Tüm platformlara gönderilen event'lerin tutarlı, benzersiz ID'lerle işaretlenmesi. Test ve doğrulama süreci olmadan bu adım tamamlanmış sayılmaz.

5. Çevrimdışı entegrasyon: Varsa CRM bağlantısı, Measurement Protocol veya Google Ads Offline Import kurulumu, ortak kimlik altyapısı. Bu adım genellikle teknik değil; CRM'i kim yönetiyor, satış süreci nasıl işliyor, mağaza verisi nerede tutuluyor gibi organizasyonel sorularla başlıyor.

6. Ölçüm ve sürdürme: EMQ skoru takibi, düzenli GTM denetimi, consent uyumluluğunun periyodik kontrolü. Sistem bir kez kurulup bırakılamaz; yaşayan bir yapı.

---

Doğru Başlangıç Noktası: Keşif

Bu yazıda anlattığımız her konuda çözüm farklı. Perakendecinin sorunu finans şirketinin sorunuyla aynı değil. B2B SaaS'ın attribution karmaşıklığı, e-ticaret sitesinkinden tamamen farklı.

Bu nedenle önce neyi çözeceğinizi anlamak için zaman ayırmak gerekiyor. Teknoloji seçimi ikinci adım; birinci adım mevcut tablonun dürüst bir değerlendirmesi.

Hangi event'leriniz eksik gönderiliyor? Hangi platformlarda veri kalitesi düşük? Çevrimdışı satışlarınızın ne kadarı dijital kampanyalardan etkileniyor ama ölçülemiyor? Bu soruların yanıtlarını birlikte bulmak, yanlış araca yatırım yapmadan önce doğru problemi belirlemenin tek yolu.

---

Event Altyapınızı Değerlendirmek İster misiniz?

Mevcut durumunuzu — hangi platformlara nasıl event gönderiliyor, veri kalitesi nasıl, çevrimdışı entegrasyon var mı — gözden geçiriyoruz. Dönüşüm tanımlarından server-side mimariye, offline-online bağlantıya kadar end-to-end bir harita çıkarıyoruz.

Bir keşif görüşmesi için bize ulaşın.