Soru genelde şöyle geliyor: sGTM mi kuralım, Data Manager mı? İkisi aynı boşluğu doldurmadığı için sorunun kendisi hatalı. sGTM ölçüm anını sunucuya taşıyor, Data Manager ölçümün hiç göremediği kaydı sonradan yazıyor. Doğru soru hangisinin kurulacağı değil, hangi verinin hangi yoldan gideceği.
sGTM tarafını daha önce iki yazıda ele almıştım: kurulum ve tag yapılandırması ile hosting seçimi. Data Manager tarafını da bu ay üç yazıda topladım: hedef haritası, ek veri kaynağı davranışı ve API uygulaması. Bu yazı ikisinin arasındaki çizgiyi çekiyor.
Aynı Kaybı Kapatmıyorlar
Katmanları ayıran şey, verinin nereden geldiği.
| Boyut | sGTM | Data Manager |
|---|---|---|
| Hedef yüzeyi | Satıcıdan bağımsız: Google, Meta CAPI, TikTok, kendi uç noktan | Yalnızca Google ürünleri |
| Tetikleyici | Tarayıcı ya da uygulama olayı, gerçek zamanlı | Backend kaydı, toplu, olaydan sonra |
| Neyi kurtarır | Cookie ömrü, tarayıcı kısıtları, istemci tarafı engelleme | Tag’in hiç göremediği kayıt: telefon, mağaza, CRM, iade |
| Kimlik yüzeyi | Cookie, click ID, first-party depolama | transaction_id, hash’lenmiş kullanıcı verisi, kayıttaki click ID |
| Değer güncelleme | Yok, olay anında bilinen değer yazılır | Var, eşleşen satırda kalıcı olarak geçersiz kılar |
| Consent | Consent Mode sinyali, olay anında | Satır düzeyi alan ya da hesap düzeyi varsayılan |
| Ritim | Olay anında | Panelde en fazla günlük, API’de çağıranın belirlediği sıklık |
| Maliyet kalemi | Sunucu ve bakım | Veri hattı ve zamanlama |
İlk satır karşılaştırmanın çerçevesini de belirliyor. Data Manager, Google ürünlerine yazan bir ingestion katmanı: Google Ads, Display & Video 360, Campaign Manager 360, Search Ads 360, Google Analytics ve Ad Manager. Meta, TikTok, LinkedIn ya da e-posta platformu bu listede yok. Dokümantasyonun kendi tanımı da bunu söylüyor: birinci taraf veriyi birden fazla Google reklam ürününe göndermeye yarayan birleşik bir ingestion API’si.1 sGTM ise hedef konusunda bağımsız: hazır tag template’leri, topluluk şablonları ve kendi yazdığın şablonlarla herhangi bir uç noktaya sunucudan sunucuya istek gönderebiliyor.
Bunun pratik sonucu şu: Google dışında da reklam veren bir yapıda Data Manager, ölçüm mimarisinin yalnızca bir kolunu çözüyor. Meta tarafındaki dönüşüm API’si, TikTok tarafındaki karşılığı ve varsa kendi veri ambarına yazma ihtiyacı hâlâ ayrı ayrı ele alınmak zorunda. sGTM bu noktada tek bir olay akışını çoğaltıp birden fazla hedefe dağıtan yer oluyor.
Tabloda en çok atlanan ikinci satır değer güncelleme. Tag bir dönüşümü yazdıktan sonra o değere dönüp dokunamıyor. Yüklenen kayıt ise eşleşen satırda tag değerini kalıcı olarak geçersiz kılıyor.2 İade, kısmi iade ve sipariş sonrası düzeltme yalnızca ikinci yoldan raporlanabiliyor.
Diğer taraftan Data Manager’ın ritmi gerçek zamanlı değil. Panel connector’ında import sıklığı en fazla günlük.3 API tarafında bu sınır yok ama yükleme yine olay sonrası bir işlem. Teklif algoritmasının olay anında ihtiyaç duyduğu sinyali sGTM taşıyor.
Bağ Tek Yönlü Kuruluyor
İki katman arasındaki asıl ilişki teknik ve tek yönlü: yükleme yaparken kullanılacak ilişkilendirme kimliği çoğunlukla tag tarafında yakalanıyor.
Ek veri kaynağı yüklemesinde zorunlu alanlar transaction ID ve dönüşüm zamanı, üstüne en az bir ilişkilendirme kimliği gerekiyor: hash’lenmiş kullanıcı verisi ya da gclid, gbraid, wbraid gibi tıklama kimlikleri.2 Bu tıklama kimliğinin sipariş kaydına düşmesi kendiliğinden olmuyor; first-party depolamada saklanıp ödeme akışında sipariş kaydına yazılması gerekiyor.
Ölçtüğüm bir hesapta first-party cookie ile click ID yakalama pratikte yüzde doksan civarında bir üst sınıra oturuyordu ve pencere genişledikçe birkaç puan düşüyordu; ayrıntısını satır seviyesinde birleştirme yazısında ele aldım. Buradaki pratik sonuç şu: click ID hiç yakalanmamışsa yüklemede geriye yalnızca hash’lenmiş kullanıcı verisi kalıyor, yani eşleşme malzemesi baştan daralıyor.
Ters yönde de bir katkı var ama daha zayıf: Data Manager tarafındaki değer güncellemesi, tag’in yazdığı hatalı ya da eksik tutarı düzeltebiliyor. Bu, sGTM kurulumundaki bir eksiği kapatmıyor, yalnızca sonucunu düzeltiyor.
Dört Senaryo, Dört Farklı Cevap
Yalnızca sGTM yeterli olabilir. Dijital ürün satan, iadesi olmayan ya da ihmal edilebilir olan, satışı tamamen web üzerinde tamamlanan yapı. Burada tag’in göremediği kayıt neredeyse yok, değer de olay anında kesin. Yükleme katmanı eklemek bakım yükü getirir, karşılığında yeni bilgi getirmez.
Yalnızca Data Manager anlamlı olabilir. Satışın ağırlığı offline tarafta olan yapı: telefonla alınan sipariş, bayi üzerinden kapanan satış, mağaza satışı. Web trafiği reklam tarafında bir rol oynuyor ama dönüşümün kendisi başka yerde tamamlanıyor. Burada sGTM’in kattığı şey sınırlı kalıyor, çünkü asıl ölçülecek olay tarayıcıda gerçekleşmiyor. Web tarafında bir form ya da arama başlatma varsa sGTM yine işe yarıyor, ama kararın ağırlığını yükleme katmanı taşıyor.
İkisi birlikte gerekiyor. E-ticaret, iade döngüsü olan, çok kanallı satış yapan yapı. Tag anlık dönüşümü ve teklif sinyalini taşıyor, yükleme katmanı iadeyi, iptali, telefon siparişini ve tag’in kaçırdığı satın almaları tamamlıyor. Bu grup, senaryolar arasında en kalabalık olanı.
Google dışında reklam veriliyorsa denklem değişiyor. Meta, TikTok ya da başka bir platform bütçenin anlamlı bir kısmını alıyorsa sGTM tarafı zaten kurulmak zorunda, çünkü Data Manager o platformlara veri göndermiyor. Bu durumda soru “hangisi” olmaktan çıkıp “Google tarafını ayrıca yükleme katmanıyla güçlendirecek miyim” haline geliyor.
Karar cümlesi iki soruya indirgenebiliyor. Birincisi: dönüşümün gerçekleştiği yer ile kesinleştiği yer aynı mı. Aynıysa tek katman yetiyor, farklıysa iki katman gerekiyor. İkincisi: yalnızca Google’a mı reklam veriliyor. Cevap hayırsa sGTM zaten denklemin içinde.
sGTM Olmadan Data Manager’a Geçmenin Maliyeti
Sıra sorusunun cevabı da buradan çıkıyor. Yükleme katmanını önce kurup kimlik yakalamayı sonraya bırakmak, geçmişe dönük olarak telafi edilemeyen bir kayıp üretiyor: geçmiş siparişlerde click ID yoksa sonradan eklenemiyor, çünkü o değer yalnızca tıklama anında mevcuttu.
Bu yüzden önerilen sıra kimlik tarafından başlıyor.
- Click ID’nin first-party depolamaya yazılması ve ödeme akışında sipariş kaydına taşınması.
transaction_iddeğerinin tag ile backend tarafında birebir aynı biçimde üretilmesi.- Yükleme katmanının devreye alınması, ilk on dört günün teklif yerine doğrulama için kullanılması.4
- Diagnostics çıktısının izlenmeye başlanması.
İlk iki madde sGTM tarafına, son ikisi Data Manager tarafına ait. Sıra bozulduğunda kaybedilen şey ölçüm değil, geçmiş.
Katman Ayrımının Consent Tarafındaki Karşılığı
İki yol consent’i farklı noktada okuyor. sGTM tarafında sinyal olay anında geliyor ve Consent Mode durumuna göre davranış değişiyor. Data Manager tarafında ise consent ya satır düzeyinde alan olarak gönderiliyor ya da hesap düzeyindeki varsayılan devreye giriyor.3
Bu fark operasyonel bir sonuç üretiyor: backend kaydında consent durumu tutulmuyorsa, yükleme hesap varsayılanına düşüyor ve o varsayılanın ne olduğu panelde ayrı bir ayar. Yani sGTM tarafında titizlikle yönetilen consent, yükleme tarafında farkında olunmadan farklı bir kurala tabi olabiliyor. İki katmanı birlikte kuran bir yapıda kontrol edilecek ilk ayarlardan biri bu.
Özet Karar
| Durum | Öneri |
|---|---|
| Dönüşüm web’de gerçekleşiyor ve kesinleşiyor | sGTM, yükleme katmanı opsiyonel |
| Dönüşüm web dışında gerçekleşiyor | Data Manager, sGTM ikincil |
| Dönüşüm web’de başlıyor, başka yerde kesinleşiyor | İkisi birlikte, sıra kimlik yakalamadan başlar |
| İade ve kısmi iade hacmi var | Data Manager zorunlu, değer güncellemesi başka yolla yapılamıyor |
| Google dışı platformlara da reklam veriliyor | sGTM zorunlu, Data Manager yalnızca Google kolunu güçlendirir |
İki katmanı birlikte kuran yapılarda en sık atlanan şey sıra: kimlik yakalama kurulmadan yapılan yükleme, geçmiş siparişlerde telafi edilemeyen bir eşleşme kaybı bırakıyor. Mevcut kurulumu bu sıraya göre okumak, hangi işin önce yapılacağını netleştiriyor.
İnceleme Talep EtFootnotes
- Data Manager API (Google for Developers). Tanım birebir: “A unified ingestion API for data partners, agencies and advertisers to send first-party data to multiple Google advertising products.” ↩
- Boost your tag with additional data sources (Google Ads Data Manager Yardım). Değer davranışı birebir: “Your additional data source becomes the source of truth for conversion value. When a transaction_id matches an existing tag event, the Conversion Value from your upload will permanently overwrite the value originally recorded by the tag.” Zorunlu alanlar transaction ID ve dönüşüm tarihi ile saati, bunun yanında en az bir ilişkilendirme kimliği: hash’lenmiş kullanıcı verisi ya da GCLID, GBRAID, WBRAID. ↩ ↩2
- Manage your connections (Google Ads Data Manager Yardım). Panel tarafında import sıklığının en fazla günlük olduğu ve verinin çalıştırmadan önce tazelenmesi gerektiği yazılı. Aynı sayfa içe aktarılan ve yüklenen veri için hesap düzeyinde varsayılan consent ayarını, bağlantı ve yükleme düzeyindeki değerlerin bu varsayılanı geçersiz kıldığını tanımlıyor. ↩ ↩2
- Fix diagnostic alerts for multi-source conversions (Google Ads Data Manager Yardım). Deneme dönemi ilk offline yükleme alındığında başlıyor; bu süre boyunca veri raporlamaya giriyor, teklife girmiyor ve sürenin sonunda çözülmemiş alarm olsa bile otomatik olarak teklife dahil oluyor. ↩
- 01 Kapsam asimetrik: Data Manager yalnızca Google ürünlerine yazıyor, sGTM ise tag template'i olan ya da yazılabilen her hedefe. Meta, TikTok ya da kendi uç noktana veri gidecekse bu iş Data Manager ile yapılamıyor.
- 02 İki katman farklı kaybı kapatıyor. sGTM tarayıcı kısıtlarından ve cookie ömründen doğan kaybı azaltıyor; Data Manager tag'in hiç göremediği kaydı taşıyor: telefon siparişi, mağaza satışı, CRM'de kapanan lead, iade sonrası düzeltme.
- 03 Değer güncelleme yalnızca Data Manager tarafında var. Tag olay anında ne biliyorsa onu yazıyor ve sonradan değiştiremiyor; yüklenen kayıt ise eşleşen satırda tag değerini kalıcı olarak geçersiz kılıyor.
- 04 Bağ tek yönlü kurulur: sGTM'in sakladığı click ID, backend yüklemesinde ilişkilendirme kimliği olarak kullanılıyor. Click ID hiç yakalanmamışsa geriye yalnızca hash'lenmiş kullanıcı verisi kalıyor ve eşleşme oranı düşüyor.
- 05 Senaryolardan yalnızca birinde ikisi de zorunlu. Dijital ürün ve iadesiz akışta sGTM tek başına yetebiliyor, offline ağırlıklı satışta Data Manager öne çıkıyor, e-ticaret ve iade döngüsü olan yapıda ikisi birlikte gerekiyor; Google dışına reklam veriliyorsa sGTM zaten kaçınılmaz.
+ sGTM kurduysam Data Manager'a ihtiyacım kalır mı?
Kalır, çünkü sGTM yalnızca tarayıcıya ya da uygulamaya ulaşan olayları taşıyor. Telefonla alınan sipariş, mağazada tamamlanan satış, CRM'de haftalar sonra kapanan lead ve iade sonrası değer düzeltmesi hiçbir tag'in göremediği kayıtlar. Ayrıca tag olay anında yazdığı değeri sonradan değiştiremiyor; yüklenen kayıt ise eşleşen satırda değeri kalıcı olarak güncelleyebiliyor. sGTM sinyal kalitesini yükseltiyor, Data Manager kapsamı genişletiyor.
+ Data Manager varsa sGTM kurmaya değer mi?
Değer, çünkü Data Manager panel tarafında en fazla günlük çalışıyor ve gerçek zamanlı sinyalin yerini tutmuyor. Daha önemlisi yükleme sırasında kullanılacak ilişkilendirme kimliği çoğunlukla sGTM tarafında yakalanıyor: first-party depolamada tutulan click ID olmadan geriye yalnızca hash'lenmiş kullanıcı verisi kalıyor. Yükleme yapısını kurmadan önce click ID yakalamayı kurmak, sonradan yapılacak her yüklemenin eşleşme oranını yükseltiyor.
+ İkisi aynı dönüşümü iki kez saydırır mı?
Tekilleştirme kurallarına uyulduğu sürece hayır. Ek veri kaynağı bir dönüşüm eylemine bağlandığında eşleştirme transaction_id üzerinden ve yalnızca o dönüşüm eyleminin içinde yapılıyor. Risk, mevcut dönüşüm eylemine bağlamak yerine yeni bir eylem açıp ikisini aynı hedef kümesinde aktif bırakmakta; o durumda tek işlem iki kez sayılabiliyor. Yani çift sayım riski katmanların birlikte kullanılmasından değil, dönüşüm eylemi kurgusundan doğuyor.
+ Hangi sırayla kurmak gerekiyor?
Önce kimlik yakalama, sonra yükleme. Click ID'nin first-party depolamaya yazılması ve sipariş kaydına taşınması kurulmadan yapılan yükleme, elindeki eşleşme malzemesini baştan sınırlıyor. Kimlik tarafı çalıştıktan sonra backend yüklemesi devreye alınıyor ve ilk on dört gün teklife girmediği için o pencere doğrulama için kullanılıyor.
+ sGTM'in maliyeti Data Manager'da yok mu?
Sunucu maliyeti yok, çünkü Data Manager tarafında çalıştırılan bir container yok; panel connector'ı ya da API çağrısı kullanılıyor. Ama maliyet sıfır değil: veri hattının kurulması, alan eşlemesi, zamanlama ve yükleme sonrası diagnostics takibi ekip tarafında iş çıkarıyor. Fark, maliyetin altyapıdan veri mühendisliğine kayması.