Sipariş kaydı ile reklam tıklaması eşleştirildi, ortak anahtar seçildi, satırlar birleşti. Sıradaki adım bu kaydı Google Ads tarafına geri yazmak. Buradaki yaygın beklenti şu: yüklenen veri, tag’in topladığı verinin yanına eklenen ikinci bir kaynaktır. Davranış öyle değil: ek veri kaynağı, bağlandığı dönüşüm eyleminin içinde değer konusunda tek yetkili kaynak haline geliyor.1
Bu ayrım kurulum sırasında görünmüyor, faturası sonra çıkıyor. Aşağıdaki davranışların hepsi resmi dokümantasyonda yazılı ve hepsi kurulum ekranında sorulmayan sorulara ait.
Ağustos serisinde önce iki panelin sayılarını ortak zemine indirmeyi, sonra satır seviyesinde birleştirmeyi ve join anahtarı seçimini ele aldım. Hangi kaydın hangi hesap tipine yazılacağı sorusu ise Data Manager hedef haritası yazısında duruyor. Bu yazı, eşleştirilmiş kaydın geri yazıldığı andaki davranışları anlatıyor.
Önce Uygunluk: Her Dönüşüm Eylemi Bağlanamıyor
Ek veri kaynağı yalnızca tag ya da Google Tag Manager ile elle kurulmuş web sitesi dönüşüm eylemlerine bağlanabiliyor. Google Analytics’ten içe aktarılan dönüşümler ve URL tabanlı dönüşüm eylemleri kapsam dışı.1
Kapsam dışı kalan bu iki tip yaygın olduğu için şart pratikte epey hesap eliyor. GA4 key event’lerini Ads’e aktararak kurulmuş bir yapıda önce dönüşüm eyleminin kendisini tag tarafına taşımak gerekiyor, yani iş ek kaynak bağlamadan önce başlıyor.
Yeni Dönüşüm Eylemi Açmak Çift Sayım Riski Üretiyor
Kurulum sırasında en cazip görünen seçenek, mevcut dönüşümü bozmamak için ayrı bir dönüşüm eylemi açmak. Doküman bunu açıkça riskli sayıyor ve gerekçesi mekanik: tekilleştirme yalnızca tek bir dönüşüm eyleminin içinde, tag ile ek kaynak arasında yapılıyor. Farklı iki dönüşüm eylemi arasında tekilleştirme yok.1
Sonuç şu: yeni eylem ile eskisi aynı kampanyanın hedef kümesinde birlikte aktifse tek bir işlem iki kez sayılıyor. Önerilen yol ek kaynağı mevcut dönüşüm eylemine bağlamak. Ayrı eylem açmak gerekiyorsa eskisinin hedef kümesinden çıkarılması şart.
Yüklenen Değer Tag’in Değerini Geçersiz Kılıyor
Eşleştirme transaction_id üzerinden yapılıyor ve sonuç üç senaryoya ayrılıyor.
| Senaryo | Alan | Sonuç |
|---|---|---|
transaction_id tag olayıyla eşleşiyor | Dönüşüm değeri ve para birimi | Yüklenen değer tag değerini geçersiz kılıyor, kalıcı olarak |
transaction_id tag olayıyla eşleşiyor | Diğer alanlar, örneğin GCLID | Yok sayılıyor, tag’in kaydettiği değerler kalıyor |
transaction_id hiçbir olayla eşleşmiyor | Gönderilen tüm veri | Yeni dönüşüm olayı oluşturuluyor, gönderilen kimliklerle ilişkilendiriliyor |
Değer tarafında üç ayrı davranış birbirine karışıyor ve üçü de rapora yansıyor: sıfır geçerli bir değer, yani tam iade için kullanılıyor. Boş bırakmak “bu kaydı güncelleme” anlamına geliyor. Sayısal her girdi ise doğrudan raporlamaya ve değer bazlı teklif stratejilerine giriyor.1
Buradan çıkan pratik kural, iade edilmiş siparişlerin yüklemede nasıl temsil edileceğine kurulumdan önce karar vermek. İade satırını hiç göndermemek ile sıfır değerle göndermek aynı şey değil; ilki tag’in yazdığı tutarı olduğu gibi bırakıyor, ikincisi o siparişin katkısını sıfırlıyor.
Para Birimi Çevrilmiyor
Yüklenen değerlerin tag ile aynı biçimde ve aynı para birimi cinsinden olması gerekiyor. Sistem birim çevrimi yapmıyor: tag lira cinsinden raporlarken kuruş cinsinden yükleme yapılması durumunda değer yüz katına çıkıyor.1
Bu hatanın sinsi tarafı, alarmın eşiğinde. Diagnostics tarafında Review your uploaded conversion values uyarısı ancak iki gün içinde tag ile ek kaynak arasında yüzde binden fazla, yani on kattan büyük bir fark oluştuğunda çıkıyor.2 Yüz kat fark bu eşiği aştığı için görünür oluyor. Eşik böyle tanımlandığından çıkan sonuç şu: daha küçük birim hataları, örneğin vergi dahil ve hariç tutarların karışması, alarm üretmeden raporda birikiyor.
Eşleşme Oranı: Yüzde On Eşiği ve Biçim Kontrolü
İki gün içinde tag ile ek kaynak arasındaki transaction_id eşleşmesi yüzde onun altında kalırsa Your conversions may be overcounted alarmı çıkıyor.2 Alarm veri kaybını değil, iki tarafın aynı kimliği farklı yazdığını işaret ediyor.
Kontrol listesi kısa ve dokümanda tek tek sayılıyor:
| Fark türü | Örnek |
|---|---|
| Ön ek veya son ek | order-12345 ve 12345 |
| Büyük küçük harf | abc-123 ve ABC-123 |
| Veri tipi | 12345 ve 12345.0 |
| Baştaki sıfırlar | 00123 ve 123 |
| Yer tutucu değer | undefined, order_id |
Biçim tarafı temizse ikinci bakılacak yer kapsam. Düşük örtüşme oranı, tag’in transaction_id’yi yalnızca aralıklı toplamasından da kaynaklanabiliyor. Dokümanın gösterdiği yaygın kök neden, dönüşüm sayfalarının bir bölümündeki hatalı etiketleme mantığı. Kimliğin her tag gönderiminde taşınıyor olması gerekiyor.2
Aynı alarm bağlantı düzeyindeki diagnostics tarafında da görünüyor, yani sorun hem dönüşüm tarafında hem veri kaynağı tarafında raporlanıyor.3
On Dört Günlük Pencere: Düzeltme Süresi Tam Olarak Bu
Teklife giren, yani panelde Primary olarak işaretlenmiş bir dönüşüm eylemine ek kaynak bağlandığında on dört günlük bir deneme dönemi başlıyor ve süre ilk offline yüklemenin alındığı anda işlemeye başlıyor. Bu dönemde ek kaynak verisi raporlamada, örtüşme tahminlerinde ve diagnostics çıktısında görünüyor, teklife girmiyor. Değer güncellemesi de bu sürede kapalı, yani tag’in yazdığı tutar raporlamada geçersiz kılınmıyor. Mevcut tag dönüşümleri normal biçimde teklifte kalmaya devam ediyor.2
Sürenin sonunda ek kaynak verisi otomatik olarak teklife dahil oluyor. Doküman bu noktada net: diagnostics’te çözülmemiş alarm bulunması bu geçişi engellemiyor.2
Yani on dört gün bir bekleme süresi değil, düzeltme penceresi. Bu pencerede yapılması gereken iş, eşleşme oranını ve değer farkını ölçüp biçim hatalarını kapatmak. Pencere kaçırıldığında hatalı veri raporda kalmakla kalmıyor, teklif stratejisine girmeye başlıyor.
Alarmları Okumak
Diagnostics çıktısı dört seviyeye ayrılıyor ve seviyeler platformdan bağımsız olarak aynı anlamı taşıyor.2
| Seviye | Anlamı |
|---|---|
Excellent | Kurulum aktif, performansı etkileyen bir belirti yok |
Good | Aktif, ama en az bir iyileştirme önerisi var, örneğin tek bir kimlik gönderiliyor |
Needs attention | Aktif ve veri alıyor, performansı etkileyen bir sorun var |
Urgent | Acil sorun: kaynak kesilmiş, eşleşme yok ya da on kat değer farkı var |
İki alarm ayrıca dikkat istiyor. Birincisi tag’in veri göndermeyi kesmesi: daha önce veri gönderen bir tag’in kırk sekiz saat sessiz kalması acil sayılıyor, multi-source kurulumlarında bu pencere yedi gün.2 İkincisi tag’de transaction_id’nin eksik ya da geçersiz olması. Bu da tekilleştirmeyi doğrudan çalışmaz hale getiriyor.
Bağlantı tarafındaki diagnostics ise ayrı bir yerde duruyor ve orada “acil” durumun somut tanımı var: daha önce çalışan bir bağlantının kırk sekiz saattir çalışmaması ve verinin sıfıra düşmesi.3
Kaynak Seçimi ve Yükleme Ritmi
Doküman ek veri kaynağı için üç somut beklenti sıralıyor.1
- Kaynak, ilgili işlemlerin tam ve yetkili kaydı olmalı; e-ticaret arka ucu ya da CRM gibi. Başka bir tag tabanlı analiz sisteminden alınan dışa aktarım uygun değil, çünkü aynı sinyal kaybını taşıyor.
- Yükleme dönüşüm olayından sonra mümkün olan en kısa sürede, tercihen yirmi dört saat içinde yapılmalı.
- Değerler tag ile aynı biçimde ve aynı birimde olmalı.
Birinci madde çoğu kurulumda atlanıyor. GA4’ten alınan bir dışa aktarımı ek kaynak olarak yüklemek, tag’in kaçırdığı dönüşümleri geri getirmiyor; Dokümanın uyarısı da bu yönde: GA4 de aynı sinyal kaybını taşıdığı için eksik verinin kopyası yükleniyor.1 Ek kaynağın anlamı, ödeme tarafında kesin olarak bilinen siparişin ölçüm katmanından bağımsız olarak taşınması.
Kurulum Sonrası İlk İki Hafta İçin Kontrol Listesi
- Dönüşüm eylemi tag ya da GTM ile elle kurulmuş bir web sitesi dönüşümü mü, doğrula.
- Ek kaynak mevcut dönüşüm eylemine mi bağlandı, yoksa yeni bir eylem mi açıldı. Yeni eylem açıldıysa eskisini hedef kümesinden çıkar.
- İlk yüklemeden sonra iki gün bekleyip eşleşme oranını oku, yüzde onun altındaysa biçim listesini sırayla geç.
- Tag ile ek kaynağın değer birimlerini tek bir siparişte karşılaştır, on kat eşiğinin altındaki sapmalar alarm üretmiyor.
- İade politikasını yükleme tarafında nasıl temsil edeceğine karar ver: sıfır değer mi, satırı hiç göndermemek mi.
- On dördüncü günden önce diagnostics’i temizle, çünkü sürenin sonunda veri alarmlardan bağımsız olarak teklife giriyor.
Buraya kadarki her şey panel üzerinden yapılabiliyor. Yüklemenin programatik tarafı, yani kimlik doğrulama kurulumu, hash ve normalizasyon kuralları, opsiyonel şifreleme ve yükleme sonrası diagnostics okuma API uygulama yazısının konusu.
Yükleme başladıktan sonra yapılan düzeltmeler on dört günlük pencereye sıkışıyor. Dönüşüm eyleminin uygunluğunu, kimlik biçimini ve değer birimini önceden kontrol etmek bu pencereyi düzeltmeye değil doğrulamaya ayırmayı sağlıyor.
İnceleme Talep EtFootnotes
- Boost your tag with additional data sources (Google Ads Data Manager Yardım). Uygunluk şartı, çift sayım uyarısı, eşleştirme tablosu ve kaynak seçimi beklentileri bu sayfada. 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 ↩3 ↩4 ↩5 ↩6 ↩7
- Fix diagnostic alerts for multi-source conversions (Google Ads Data Manager Yardım). Değer farkı alarmının eşiği iki gün içinde yüzde binden fazla, yani on kat. Eşleşme alarmı iki gün içinde yüzde onun altında eşleşme. Biçim farkı listesi ve kapsam kontrolü aynı sayfada. Deneme dönemi maddeleri de burada: süre ilk offline yükleme alındığında başlıyor, bu sürede veri raporlamaya girip teklife girmiyor ve sürenin sonunda “regardless of any diagnostic alerts” ifadesiyle otomatik olarak teklife dahil oluyor. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
- Troubleshoot connection issues (Google Ads Data Manager Yardım). Bağlantı kalitesi durumları ve acil durumun tanımı: daha önce çalışan bir bağlantının son kırk sekiz saatte çalışmaması ve verinin sıfıra düşmesi. Aynı sayfa eşleşme oranı alarmını bağlantı tarafında da listeliyor ve kimlik bilgisi, biçim, eksik kolon gibi diğer tanıları veriyor. ↩ ↩2
- 01 Yüklenen conversion value, eşleşen satırda tag'in yazdığı değeri kalıcı olarak geçersiz kılıyor. Sıfır geçerli bir değer (tam iade), boş bırakmak ise güncelleme yapma anlamına geliyor. Aradaki farkı bilmeden yapılan yükleme raporu ve value-based bidding'i birlikte etkiliyor.
- 02 Para birimi otomatik çevrilmiyor. Tag lira raporlarken kuruş cinsinden yükleme yapılırsa değer yüz katına çıkıyor; diagnostics bunu ancak on kat farkta alarma dönüştürüyor, altındaki sapmalar sessiz kalıyor.
- 03 Tekilleştirme yalnızca tek bir dönüşüm eyleminin içinde çalışıyor. Yeni bir dönüşüm eylemi açıp eskisiyle birlikte aynı hedef kümesine koymak, tek siparişin iki kez sayılması demek.
- 04 İki günde yüzde on altında transaction_id eşleşmesi alarm üretiyor. Sorunun kaynağı çoğunlukla biçim farkı ya da tag tarafında kimliğin her ping'de gönderilmemesi, veri kaybı değil.
- 05 İlk on dört gün teklife girmiyor ve bu sürede değer güncellemesi de kapalı. Sürenin sonunda alarmlar çözülmese bile veri otomatik olarak teklife dahil oluyor, yani düzeltme penceresi kaçırıldığında hatalı veri doğrudan bütçeyi etkilemeye başlıyor.
+ Yüklenen dönüşüm değeri tag'in yazdığı değeri değiştiriyor mu?
Evet, eşleşen satırlarda değiştiriyor ve bu kalıcı. Ek veri kaynağı, bağlandığı dönüşüm eylemi içinde değer konusunda yetkili kaynak sayılıyor. Değer ve para birimi dışındaki alanlar için durum tersine: transaction_id eşleştiğinde GCLID gibi diğer alanlar yok sayılıyor, tag'in kaydettiği değerler kalıyor. Eşleşme bulunmayan satırlar ise yeni bir dönüşüm olayı olarak oluşturuluyor ve gönderilen kimliklerle ilişkilendirilmeye çalışılıyor. Tek istisna kurulumun ilk on dört günü: bu sürede değer güncellemesi devre dışı.
+ Boş değer ile sıfır değer arasındaki fark ne?
Sıfır geçerli bir değer ve tam iade gibi durumlar için kullanılıyor, yani o satırın değerini sıfıra çekiyor. Bir kaydın değerine hiç dokunulmaması isteniyorsa alan boş bırakılıyor. Sayısal her girdi doğrudan raporlamaya ve değer bazlı teklif stratejilerine yansıdığı için, iade edilmiş siparişleri sıfırla göndermek ile hiç göndermemek farklı sonuçlar üretiyor.
+ Ayrı bir dönüşüm eylemi açmak mı daha güvenli?
Hayır, tersine risk yaratıyor. Tekilleştirme yalnızca tek bir dönüşüm eyleminin içinde, tag ile ek kaynak arasında çalışıyor. İki farklı dönüşüm eylemi aynı kampanyanın hedeflerinde birlikte aktifse tek bir işlem iki kez sayılabiliyor. Google'ın önerisi ek kaynağı mevcut dönüşüm eylemine bağlamak. Yeni bir eylem açılacaksa eskisinin aynı hedef kümesinden çıkarılması gerekiyor.
+ Eşleşme oranı düşük çıkıyorsa nereye bakılmalı?
Önce biçime. Ön ek ya da son ek farkı, büyük küçük harf farkı, sayının ondalıklı yazılması, baştaki sıfırların kaybolması ve yer tutucu değerlerin sızması en sık görülen beş neden. Bunlar temizse ikinci bakılacak yer kapsam: tag transaction_id'yi her gönderimde taşıyor mu. Düşük örtüşmenin yaygın kök nedeni, dönüşüm sayfalarının bir kısmındaki hatalı etiketleme mantığı yüzünden kimliğin aralıklı toplanması.
+ On dört günlük deneme süresi ne zaman başlıyor?
Her dönüşüm eylemi için ilk offline yükleme alındığında başlıyor. Bu süre boyunca ek kaynaktan gelen veri raporlamada, örtüşme tahminlerinde ve diagnostics çıktısında görünüyor ama teklife girmiyor; mevcut tag dönüşümleri normal şekilde teklifte kalmaya devam ediyor. Süre dolduğunda ek kaynak verisi otomatik olarak teklife dahil oluyor, diagnostics'te çözülmemiş alarm bulunması bunu engellemiyor.