Birinci taraf ölçüme geçiş ve sunucudan beslenen pazarlama hunisi

Önce ve sonra

Ne devraldım

İşe tüm dijital varlıkların ölçüm altyapısını kontrol ederek başladım. Google Analytics ve ölçüm pikselleri kuruluydu, eski bir Tag Manager duruyordu. Sorun şuydu: aynı dönüşüm birden fazla yerden sayılıyordu ve doğru dönüşümler takip edilmiyordu. Aynı dönüşüm Tag Manager’dan ayrı, Analytics içinden ayrı, Meta için ayrı eklenmişti. İlk iki haftam yalnızca neyin neyi saydığını çözmekle geçti. Sonra ölçüm kurulumlarının tamamını sıfırdan yaptım.

İki şey giderek sorun hâline gelmeye başladı

• İlçe sorusuna cevabım yoktu. Şirketin sorusu hiçbir zaman “Türkiye’den kaç başvuru geldi” olmadı. Soru şuydu: Pendik’ten kaç başvuru geldi ve Pendik için ne kadar harcadık? Reklam panelleri bu soruya net bir cevap vermiyor. Pendik için açtığım bir kampanya, platformun konum genişletmeleri yüzünden Üsküdar’dan başvuru getirebiliyordu. Ben de dönem dönem harcama ve başvuru dosyalarını elle eşleştirerek tablo kuruyordum.
• Veri bizim değildi. Ölçüm, üçüncü taraf araçların tarayıcıda topladığı veriye dayanıyordu. iOS kısıtları ve reklam engelleyiciler o veriyi her yıl biraz daha eksiltiyor. Eksik veriyle hem rapor yazıyordum hem de reklam algoritmalarını besliyordum.

Karar: veriler bizim tarafımızda toplanacak ve sunucu taraflı ölçüme geçilecek

2025’in sonunda geçiş kararını verdim ve şirket içinde konuyu çözmek için çeşitli öneriler oluşturduk. İki gerekçem vardı. Birincisi algoritmaları beslemekti. Sinyal Meta Conversions API’ye, Google’a ve TikTok’a sunucudan giderse tarayıcıdaki kayıplar aradan çıkıyor ve optimizasyon daha sağlam veriyle çalışıyor. İkincisi, ilçe raporunu her ay elle kurmaktan kurtulmaktı. Birinci taraf ölçümün bir getirisi daha var: veri kendi altyapımızda birikiyor. Kullanıcının hangi kampanyadan geldiği bilgisi de tarayıcıda kalmıyor, başvuru kaydının üstüne yazılıyor.

Kurulumu KVKK ve GDPR’a uygun şekilde yaptık. Sunucu taraflı ölçüm, kanundan kaçmanın yolu değil. Veriyi kanuna uygun ve eksiksiz toplamanın yolu.

Kurulan sistem

Birinci taraf izleme için Hardal’ı kurduk. Hardal, veriyi tarayıcıdan değil sunucudan toplayan bir izleme platformu. Kurulum üç parçadan oluşuyordu: verinin toplandığı yer, temizlenip harcamayla birleştirildiği yer ve okunduğu pano.

Toplama

Sitedeki olaylar Hardal üzerinden sunucu taraflı kaydediliyordu: sayfa görüntülemesi, başvuru formunun açılması, formun yarıda bırakılması ve başvurunun tamamlanması. Her olay, ziyaretçinin hangi kaynaktan, hangi kampanyadan ve hangi reklam setinden geldiği bilgisini de taşıyordu. Başvuru tamamlandığında bu bilgi başvuru kaydının üstüne yazılıyordu. Reklam tıklamasının kimliği (gclid, fbc) ve kullanıcının formda verdiği il ve ilçe de aynı kayıtta duruyordu.

Kullanıcı forma ulaştığı andan itibaren, geldiği kaynak satış ekibinin listesine düşene kadar onun yakasını bırakmıyordu. Veri, yazılım ekibinin kurduğu bir otomasyon akışıyla BigQuery’ye düşüyordu.

Temizleme ve birleştirme

Ham tablo beş saatte bir çalışan bir sorguyla işleniyordu. Bozuk karakterler ve Türkçe harf farkları düzeltiliyordu. Aynı kaynağın farklı yazımları tek bir ada indiriliyordu. Kampanya adı eksik gelen kayıtlar Google’ın kampanya listesinden tamamlanıyordu.

Ardından Google ve Meta’nın harcama, gösterim ve tıklama verisi kendi arayüzlerinden çekilip reklam seti ve gün bazında aynı tabloya bağlanıyordu.

Yanlış anlaşılmasın, her şey otomatik değildi. Her kampanya için üç şeyi bir eşleme (mapping) tablosunda ben tanımlıyordum: hangi il ve ilçeyi hedeflediği, personel tarafına mı işletme tarafına mı ait olduğu ve hangi platformda döndüğü. Yeni kampanya açıldığında bu tabloya bir satır ekliyordum ve kampanya panoda doğru ilçenin altında görünüyordu.

Pano: pazarlama hunisi (marketing funnel)

Data Studio’daki panoda personel başvurusu ve işletme başvurusu iki ayrı huni olarak izleniyordu. İkisinde de adımlar aynıydı:

1. Gösterim, tıklama ve harcama. Reklam platformundan geliyordu. Reklamın kaç kişiye ulaştığını ve kaça mal olduğunu gösteriyordu.
2. Sayfa görüntüleme. Tıklayanın siteye gerçekten ulaşıp ulaşmadığını gösteriyordu. Reklam panelinin saydığı tıklama ile sitenin gördüğü ziyaret arasındaki fark burada görülebiliyordu.
3. Form sayfası görüntüleme. Siteye gelenlerin ne kadarının başvuru formunu açtığını gösteriyordu.
4. Form terki. Formu doldurmaya başlayıp bırakanların sayısını, formun ortalama yüzde kaçının doldurulduğunu ve bırakılmadan önce son doldurulan alanı gösteriyordu.
5. Başvuru. Formu tamamlayanların sayısıydı. Başvuru başına maliyet (CPL, cost per lead) de buradan çıkıyordu. Hesap, reklam panelinin değil sitenin saydığı başvuruya göre yapılıyordu.

Olayın özünde şu var: harcama reklam panelinden, davranış siteden geliyordu ve pano ikisini reklam seti ve gün bazında aynı satıra koyuyordu. Bütün adımlar kampanya, reklam seti, platform, il, ilçe, gün ve hafta kırılımında filtrelenebiliyordu. “Pendik için açtığımız kampanyaya geçen hafta ne harcadık, kaç kişi forma ulaştı, kaçı yarıda bıraktı, kaçı başvurdu” sorusu artık tek ekranda cevaplanıyordu. Her ay elle kurduğum tablonun yerini kendi kendine güncellenen bu pano aldı.

Form terki verisi kararları da değiştirdi. Mart başında işletme formunda bir değişiklik yaptık: az hacim seçen işletmeye, formu göndermeden önce fiyat gösterilmeye başlandı. Amacımız, fiyatı baştan kabul etmeyecek başvurunun satış ekibine hiç gitmemesiydi. Değişiklikten önce formu sonuna kadar doldurup bırakan kimse yoktu. Sonrasında bu kişiler görünmeye başladı ve hepsi formun son adımında kalmıştı. Beklediğimiz örüntü tam olarak buydu. Tarayıcı tabanlı kurulumda formun hangi alanda bırakıldığını gösteren bir veri yoktu.

Altyapı oturduktan sonra çıkan ikinci problem

Mart 2026’da başka bir sorun büyüdü. İşletme başvurusu toplamak için açtığımız kampanyalara, sahada çalışmak isteyen personel adayları başvuruyordu. İşletme başvurusuna karışan personel başvurusu Ocak ayında tek haneliyken Mart’ta yüzü aşmıştı. Formun içine uyarı yazdık, kreatifte koca harflerle işletme dedik, yine de durmadı.

Sorun metinde değildi. İşletme formunun kendi dönüşüm olayı vardı. O forma personel adayları da giriyordu ve olayı onlar da tetikliyordu. Meta’nın gördüğü şey olayın tetiklendiğiydi. Dolduranın gerçekten işletme olup olmadığı sinyalin içinde yoktu. Algoritma formu dolduran herkesi iyi müşteri sayıyor ve aday profiline benzeyen kişilere reklam göstermeye devam ediyordu. Bütçe arttıkça kirlilik de artıyordu.

Çözüm sinyalin kendisini değiştirmekti ve iki yerden geldi.

• Sayfada. İşletme başvuru sayfasına, personel adaylarını kendi formlarına götüren bir yönlendirme koyduk. Eskiden işletme formunu doldurup kirliliği yaratan kişiler artık doğru forma gidiyordu.
• Sinyalde. Reklam platformlarına artık form dolduran herkes gitmiyordu. Satış ekibi bir başvuruyu bölge ekibine yönlendirdiğinde, ziyaret planladığında ya da sözleşme imzaladığında bu sonuç geri gidiyordu. Google’a çevrimdışı dönüşüm olarak, yani reklam platformuna sonradan bildirilen gerçek sonuç olarak gidiyordu. Meta’ya da nitelikli başvuru sinyali olarak gidiyordu. Eşleşmeyi, başvuru kaydındaki reklam tıklaması kimliği ve iletişim bilgisi sağlıyordu.

Personel adayı olarak işaretlenen başvurular bu sinyalin dışında kaldı.

Not: Bu kurgu yanlış başvurunun kendisini sıfırlamıyor. Yanlış formu dolduran biri her zaman çıkabilir. Değişen şey, algoritmanın neyi hedef saydığı.

Yolda ne bozuldu

Dashboard bir ara parayı katlayarak saydı. Mart 2026’da bazı kampanyaların panodaki harcaması gerçeğinden yüksek, başvuru sayısı ise düşük görünüyordu. BigQuery’de satır satır iz sürdüm.

Aynı reklam seti ve aynı gün için birden fazla satır üretiliyordu. Harcama her satıra yeniden bağlanıyor, başvurular ise satırlar arasında bölünüyordu. Bazı kampanyalarda fark üç katına çıkıyordu. Sorgunun mantığına göre bunun olmaması gerekiyordu ve ilk itiraz da bu yöndeydi.

Aynı örüntüyü hem Google hem Meta kampanyalarında sorgu çıktılarıyla gösterdim. Düzeltme geldi ve tek satıra düştüğünü yine sorguyla doğruladım. Pazarlamacının SQL bilmesi burada işe yaradı, çünkü kendi panomdaki rakamın nereden geldiğini kendim gösterebildim.

Performance Max dönüşüm şişiriyordu. Google’ın görüntüleme sonrası saydığı dönüşümler, gerçek başvurunun yaklaşık 2,8 katına çıkıyordu. Bunu sunucudan gelen gerçek başvuru sayısıyla kıyaslayarak gördüm. Çözüm bir önceki bölümdeki gibi oldu: algoritmaya yalnızca onaylanmış başvuruyu beslemek.

Sonuç

• İlçe kırılımında harcama ve başvuru tek panoda toplandı. Rapor artık elle kurulmuyordu.
• Kaynak bilgisi başvuru kaydına yazıldı. Reklam ile başvuru arasındaki bağ tahmin olmaktan çıktı.
• Google, Meta ve TikTok sunucudan beslendi. Google ve Meta’da algoritmalar form dolduran için değil, satışın onayladığı başvuru için optimize oldu.
• Form terki ölçülür oldu. Formun nerede bırakıldığı görülebildiği için sayfa değişiklikleri tahminle değil veriyle yapıldı.
• Sistemin taşıdığı hacim: aylık binlerle ifade edilen personel başvurusu ve yüzlerle ifade edilen işletme başvurusu.

Not: neyin ölçüldüğü, neyin ölçülmediği

Başvurunun hangi kampanyadan geldiği gerçek veridir, kaynaktan başvuru kaydına taşınır.

Başvuranın il ve ilçesi de gerçektir, çünkü kullanıcı onu formda kendisi yazar. Panodaki ilçe kırılımı ise kampanyanın hedeflediği ilçeye göredir ve bu eşlemeyi ben yapıyordum. Pendik için açılan bir kampanya Üsküdar’dan başvuru getirdiğinde, pano bu başvuruyu Pendik’in altında gösteriyordu. Reklamın gerçekte hangi coğrafyada gösterildiğini ise reklam ağının bildirdiği kadar biliyoruz.