Çoğu e-pin satıcısı Google Analytics 4 kurulumunu "ölçüm kodunu head'e yapıştırdım, iş bitti" sanır. Sonra ay sonunda panelindeki ciro ile GA4'te gördüğü ciro arasında yüzde kırklık bir fark bulur ve bunu "Analytics zaten tam doğru saymaz" diye geçiştirir. Oysa o fark rastlantı değil; bir ölçüm mimarisi hatasının doğrudan sonucudur ve reklam veren her satıcının kârını sessizce yiyen şey tam olarak budur.
Gerçek şu: dijital ürün satışı, fiziksel e-ticaretten tamamen farklı bir ölçüm davranışına sahiptir. Sipariş saniyeler içinde tamamlanır, teslimat anlıktır, iade neredeyse yoktur ama iptal ve bakiye yüklemesi vardır. Bu yüzden standart e-ticaret şablonuyla kurulan GA4, senin iş modelinde yanlış hikâye anlatır. Doğru kurulan bir e-pin satış scripti, GA4'e ham sayfa görüntüleme değil, iş anlamı taşıyan olaylar gönderir. Aşağıda o düzeni parça parça açıyorum.
Neden ölçüm kodunu yapıştırmak hiçbir işe yaramıyor?
GA4'ün temel ölçüm kodu sana yalnızca trafik hacmi verir: kaç kişi geldi, hangi sayfaya baktı, ne kadar kaldı. Bu veriler e-pin işinde neredeyse değersizdir, çünkü senin işinde kritik olan şey trafik değil bakiye yükleme davranışıdır. Kullanıcı siteye girer, bakiye yükler, sonra günlerce o bakiyeden alışveriş yapar. Ölçüm kodunun tek başına gördüğü şey ise "birisi geldi ve gitti"dir. Cironun nereden doğduğunu asla söylemez. Bu yüzden ciddi bir e-pin yazılımı kurgusunda GA4, ödeme motoruna ve sipariş tablosuna bağlanır; sadece tarayıcıya değil.
Hangi olayları göndermelisin, hangilerini asla göndermemelisin?
En sık yapılan hata, her tıklamayı olay olarak göndermektir. GA4 olay ve parametre limitleri vardır; gereksiz olay gönderdiğinde önemli olanlar kalabalıkta kaybolur. Doğru düzen dar ve anlamlıdır: view_item (ürün detay), add_to_cart veya doğrudan begin_checkout, ödeme sağlayıcı yönlendirmesi için add_payment_info, bakiye yükleme için özel bir bakiye_yukle olayı ve nihayet purchase. Bakiyeden yapılan alışverişte purchase yeniden gönderilirse aynı para iki kez sayılır. İyi kurgulanmış bir dijital ürün satış scripti bu iki akışı ayırır: para sisteme bir kez girer, bir kez ölçülür.
| Olay | Ne zaman tetiklenir | Zorunlu parametre | Sık hata |
|---|---|---|---|
| view_item | Ürün detay açıldığında | item_id, item_name, price | Kategori adı boş bırakılır |
| begin_checkout | Ödeme adımına geçişte | value, currency, items | Kur TRY yerine boş gider |
| add_payment_info | Sağlayıcı seçildiğinde | payment_type | Hiç kurulmaz, hunide boşluk oluşur |
| bakiye_yukle | Yükleme onaylandığında | value, method | purchase olarak gönderilir, ciro şişer |
| purchase | Sipariş başarıyla kapandığında | transaction_id, value | Geri dönüş sayfası yenilenince tekrarlanır |
| refund | İptal/iade işlendiğinde | transaction_id | Hiç gönderilmez, ciro şişik kalır |
Purchase olayı neden iki kere sayılıyor ve bu nasıl durdurulur?
Ödeme sağlayıcısından dönen kullanıcı teşekkür sayfasına düşer. O sayfayı yenilerse, geri tuşuna basıp tekrar girerse ya da linki paylaşırsa purchase olayı yeniden ateşlenir. GA4 varsayılan olarak bunu engellemez. Çözüm sunucu tarafındadır: sipariş kaydına bir olay gönderildi bayrağı yazılır ve olay yalnızca bu bayrak boşken üretilir. İkinci çözüm, transaction_id'yi rastgele değil sipariş numarasıyla birebir aynı tutmaktır; böylece mükerrer kayıtlar raporlamada tekilleştirilebilir. Bu iki önlemi almayan her e-pin scripti kurulumu, reklam platformuna şişirilmiş ciro öğretir ve algoritmayı yanlış kitleye iter.
GA4 veri kaybının kaynakları
- Reklam engelleyici ve tarayıcı kısıtları 45%
- Ödeme yönlendirmesinde kopan oturum 25%
- Yanlış veya eksik olay parametresi 20%
- Cihaz değiştiren kullanıcı 10%
Sunucu taraflı ölçüm gerçekten gerekli mi?
Kısa cevap: reklam veriyorsan evet. Tarayıcı taraflı ölçüm, reklam engelleyiciler ve çerez kısıtlarıyla kayıp verir. GA4'ün Measurement Protocol arayüzü, satın alma olayını doğrudan senin sunucundan göndermene izin verir. Bunun anlamı şudur: ödeme gerçekten onaylandığında, kullanıcının tarayıcısı ne yaparsa yapsın olay GA4'e ulaşır. Bir e-pin satış yazılımı için bu, ölçümün tarayıcıya değil paranın kendisine bağlanması demektir. Ayrıca sahte purchase gönderimi riskini de ortadan kaldırır; çünkü olayı üreten yer artık kullanıcının makinesi değil, senin ödeme doğrulama katmanındır.
Ciro rakamının tek sahibi sipariş tablon olsun. GA4 o tablodan beslensin, onunla yarışmasın. Aralarında fark çıktığında düzelteceğin yer her zaman ölçüm katmanıdır, panel değil.
Kullanıcı kimliğini bağlamazsan hangi satışları göremezsin?
Dijital ürün alıcısı çoğu zaman Instagram reklamını telefondan görür, akşam bilgisayardan üye olur ve ertesi gün tekrar telefondan alışveriş yapar. Tarayıcı tabanlı ölçüm bunu üç ayrı kişi sayar. GA4'te user_id parametresi tam olarak bu sorunu çözmek için vardır. Üyelik sistemine sahip her kurulumda, kullanıcı giriş yaptığı anda hash'lenmiş bir kimlik GA4'e verilmelidir. Böylece reklamı gören kişi ile parayı ödeyen kişi tek profilde birleşir ve ilk temas kaynağı doğru şekilde etiketlenir. Bu ayarı yapan satıcılar, daha önce "doğrudan trafik" sanılan cironun aslında ücretli kanaldan geldiğini fark eder.
Kurulumun doğru olduğunu nasıl kanıtlarsın?
Kurulum bitti demek, çalışıyor demek değildir. Doğrulamanın üç kademesi vardır: GA4 DebugView üzerinde olayın anlık düşmesi, gerçek zamanlı raporda parametrelerin dolu görünmesi ve yirmi dört saat sonra sipariş tablosuyla ciro karşılaştırması. Üçüncü adım atlanırsa hata aylarca sürer. Aşağıdaki kontrol listesini kurulumdan sonra bir kez, ardından her ödeme sağlayıcı değişikliğinde tekrar uygula.
| Kontrol | Nasıl bakılır | Kabul ölçütü |
|---|---|---|
| Olay isimleri standart mı | DebugView akışı | Yazım hatası ve Türkçe karakter yok |
| Para birimi gidiyor mu | Olay parametreleri | currency alanı TRY dolu |
| Mükerrer purchase var mı | transaction_id tekilliği | Aynı numara tek kayıt |
| Ciro eşleşiyor mu | Panel raporu ile karşılaştır | Sapma %5 altında |
| Bakiye ayrı mı ölçülüyor | Özel olay raporu | Ciroya iki kez yazılmıyor |
| İç trafik hariç mi | Veri filtreleri | Yönetici IP'leri dışlanmış |
| Sunucu olayı aktif mi | Ödeme onay logu | Her onayda tek gönderim |
Ölçümü sonradan yamamak yerine hazır gelen bir altyapıyla başla
Pinova, e-pin ve dijital ürün satan işletmeler için olay katmanı, sipariş doğrulama ve raporlama uyumu düşünülerek geliştirilmiş bir satış yönetim yazılımıdır. Özellik listesini inceleyebilir, paketleri karşılaştırabilirsin.
GA4 kurulumu için geliştirici bilgisi şart mı?
Temel ölçüm kodu için hayır. Ancak satın alma ve bakiye olaylarının sipariş kaydına bağlanması için yazılımın bu olayları üretebiliyor olması gerekir. Hazır olay altyapısı sunan bir kurulumda işin büyük kısmı ayar ekranından yapılır.
Ciro farkı ne kadar olursa normal sayılır?
Yüzde beşe kadar sapma teknik olarak kabul edilebilir. Bunun üzerindeki her fark mükerrer olay, eksik iade kaydı veya kopan ödeme dönüşü anlamına gelir ve mutlaka araştırılmalıdır.
Bakiye yüklemesini ciro olarak saymalı mıyım?
Reklam optimizasyonu için bakiye yüklemesi anlamlı bir dönüşümdür, ancak satış cirosuyla aynı hesaba yazılmamalıdır. Ayrı bir olay olarak tanımlar, raporda ayrı sütunda izlersin.
Sunucu taraflı ölçüm tek başına yeterli mi?
Satın alma için yeterlidir ama gezinme davranışını göremezsin. En sağlıklı yapı ikisinin birlikte çalıştığı melez kurulumdur: davranış tarayıcıdan, para sunucudan ölçülür.
Ölçüm, sonradan eklenen bir eklenti değil; satış altyapısının bir parçasıdır. Olay şemasını, sipariş doğrulamasını ve raporlama uyumunu baştan düşünen bir sistemde GA4 entegrasyonu yarım günlük iştir; düşünmeyen bir kurulumda ise aylarca süren bir tahmin oyununa dönüşür. Bu farkı kendi gözünle görmek istersen canlı demo üzerinden sipariş akışını ve panel raporlarını inceleyip, kendi ölçüm planını bu yapı üstünde kurgulayabilirsin.