Çoğu e-pin satıcısı GA4 kodunu siteye yapıştırdığı an işin bittiğini düşünür. Realtime ekranında birkaç nokta hareket eder, tarayıcı sekmesinde bir sayı yanıp söner, "ölçüm artık çalışıyor" diyerek rahatlar ve bir daha o paneli açmaz. Oysa kurulan şey çoğu zaman sadece bir ziyaretçi sayacıdır; bir e-pin scriptinin gerçekten ürettiği satış hareketini hiç görmeyen, kör bir defter. Script dataLayer'a tek satır bile yazmıyorsa GA4 senin için sadece "biri geldi, biri gitti" diyen boş bir günlük tutuyordur; hangi oyunun koduna bakıldığını, hangi bakiye tutarının seçildiğini, ödemenin nerede terk edildiğini bilmez. Sen panelde satışları sayarken, Google'ın algoritması aynı siteyi neredeyse boş sanır. Bu, özellikle yoğun kampanya dönemlerinde ciddi bir kör nokta yaratır çünkü hangi reklamın gerçekten sipariş getirdiğini ayırt edemezsin.
Asıl mesele şu: Google'ın otomatik topladığı tarayıcı verisi ile bir e-pin satış scriptinin ürettiği parasal gerçek aynı şey değil. Panelinde bugün beş yüz teslimat görürken GA4'te doksan dönüşüm görünüyorsa, sorun reklam bütçende değil; kurduğun olay şemasında. Örneğin günde yüz sipariş alan bir sitede GA4 sadece otuzunu görüyorsa, kayıp yetmiş siparişin nerede koptuğunu bulmadan hiçbir pazarlama kararı sağlıklı olamaz. Bu yazıda bir e-pin yazılımı için GA4'ün hangi olayları hangi anda, hangi parametrelerle görmesi gerektiğini, sektördeki kurulumların neden çoğunlukla eksik ya da hatalı kaldığını adım adım açıyoruz; hem script tarafında hem panel tarafında nelerin değişmesi gerektiğini göreceksin.
Çoğu E-pin Sitesi GA4'ü Kurar Ama Asıl Olayı Hiç Görmez
GA4, varsayılan olarak sayfa görüntüleme, kaydırma oranı ve dış bağlantı tıklaması gibi genel etkileşimleri kendi başına toplar; bunun için ek bir şey yapmana gerek yoktur. Ama bir e-pin satış scripti için gerçek hikaye bu genel etkileşimlerin hiçbirinde geçmez; hikaye ürün seçiminde, bakiye yüklemesinde, ödeme yönteminin belirlenmesinde ve kod tesliminde geçer. Örneğin bir kullanıcı yüz liralık bir bakiye seçip ödeme ekranına geçtiğinde, bu adım script tarafında ayrı bir sinyal olarak işaretlenmezse, o kullanıcı ödemeyi tamamlamadan ayrıldığında hiçbir iz kalmaz; sen sadece "bir ziyaret oldu" bilgisine sahip olursun. Aynı durum yüzlerce kullanıcı için tekrarlandığında, hangi adımda büyük kopma olduğunu asla öğrenemezsin. Bu zincirin eksik halkası, özellikle mobil ödeme akışlarında daha da belirgin hale gelir çünkü kullanıcı uygulama içinden çıkıp tekrar girdiğinde oturum verisi parçalanır. "Kurulum yaptım" demek ile "doğru şemayı kurdum" demek arasında büyük bir fark var; birincisi sana sadece trafik gösterir, ikincisi sana parayı ve parayı kaybettiğin yeri gösterir. Pinova'nın bu noktalardaki otomatik olay desteğine nasıl baktığını görmek istersen özellikler sayfasına göz atabilirsin; bir e-pin satış yazılımının bu halkaları tek tek işaretleyip işaretlemediği, kurulumun kalitesini doğrudan belirler.
"Purchase" Olayı Tek Başına Neden Yalan Söyler?
Standart e-ticaret mantığında "purchase" olayı tek ve net bir anı temsil eder: ödeme onaylandı, iş bitti, para kasaya girdi. Ama e-pin tarafında işler daha katmanlı; bakiye ile ödeme yapılması, kısmi iade, stok hatası sonrası iptal, sağlayıcı tarafında manuel onay bekleyen teslimat gibi ara durumlar devreye giriyor. Örneğin bir sağlayıcı ödemeyi reddettiğinde kullanıcı tekrar deneyip başarılı olabilir; bu durumda tek bir purchase olayı görürsün ama aradaki başarısız denemeyi fark edemezsin, oysa o deneme ödeme yönteminin sorunlu olduğunu gösteren net bir sinyaldir. Sadece purchase olayına güvenen bir e-pin satış yazılımı kurulumu, başarısız denemeleri sessizce yutar ve sana yapay, şişirilmiş bir başarı tablosu sunar. Gerçekte izlemen gereken şey tek bir olay değil, baştan sona uzanan bir olay zinciridir ve bu zincirin her halkası ayrı ayrı okunabilmelidir; aksi halde satış arttı mı düştü mü sorusuna bile net cevap veremezsin.
| Olay Adı | Tetiklenme Anı | Zorunlu Parametreler | Neden Kritik |
|---|---|---|---|
| view_item | Ürün/kod detayı açıldığında | item_id, item_name, item_category, value | İlgi gören ürünleri ayırt eder |
| select_item | Listeden ürün seçildiğinde | item_list_name, item_id | Hangi vitrinin sattığını gösterir |
| begin_checkout | Ödeme ekranı açıldığında | value, currency, items | Sepet terkini ölçer |
| add_payment_info | Ödeme yöntemi seçildiğinde | payment_type | Yöntem bazlı terk oranını açığa çıkarır |
| purchase | Ödeme sağlayıcıdan onay geldiğinde | transaction_id, value, currency, items | Mükerrer sayımı önler, gelirle eşleşir |
E-pin Scriptinde Hangi Olaylar Zorunlu, Hangileri Süs?
Çekirdek huniyi oluşturan beş olay olmadan "ölçüyorum" demek pratikte anlamsızdır: ürün görüntüleme, ürün seçimi, ödemeye başlama, ödeme bilgisi girme ve satın alma. Bunların dışında eklenen "favorilere ekleme" veya "sosyal paylaşım" gibi olaylar görsel olarak güzel durur ama satış kararını doğrudan etkilemez, süs kalır. Örneğin binde bir dönüşüm oranına sahip bir e-pin sitesinde, eğer sadece purchase olayını izliyorsan düşüşün sepette mi yoksa ödeme ekranında mı olduğunu hiç bilemezsin; beş olaylık huni bu farkı net biçimde ortaya çıkarır. Bir dijital ürün satış scripti kurarken önceliğin huniyi eksiksiz tamamlamak olmalı; önce zorunlu beşliyi doğru parametrelerle kur, ancak ondan sonra isteğe bağlı olayları ekle. Tersini yapan satıcılar, gösterişli ama kararsız bir rapor elde eder; huninin neresinde kaybettiğini bilmeden sadece toplam satışı izlemiş olur, bu da reklam optimizasyonunu kör bir tahmine çevirir.
Kurulumu Yanlış Olan E-pin Sitelerinde Veri Nerede Kayboluyor?
- Checkout adımında kayıp 45%
- Ödeme onayında kayıp 25%
- Teslimat sonrası kayıp 20%
- Diğer nedenler 10%
Parametre Şeması: Google'ın İstediği ile Senin İhtiyacın Farklı
GA4'ün standart e-ticaret şeması item_id, item_name, item_category gibi genel alanlar bekler ve bu alanları doldurmak teknik olarak kolaydır. Ama bir e-pin yazılımı için bu genel alanlar tek başına yeterli değildir: hangi oyun, hangi bölge sunucusu, hangi bakiye türü, teslimatın anlık mı yoksa manuel onaylı mı olduğu bilgisi olmadan rapor kör kalır; aynı kategori altında toplanan on farklı oyun birbirinden ayrılamaz. Çözüm, standart alanları doldururken yanlarına GA4'ün zaten desteklediği item_category2 ve item_variant gibi ikincil alanları kendi iş mantığına göre doldurmak. Bu sayede aynı "purchase" olayı içinde hem Google'ın beklediği genel şema hem de senin günlük karar almak için ihtiyaç duyduğun detay bir arada taşınır; haftalık rapor alırken hangi oyunun hangi bölgede daha çok sattığını tek ekrandan görürsün. Bu detay seviyesi özellikle sezonsal kampanyalarda işe yarar; hangi bölge sunucusunun hangi dönemde öne çıktığını görmek, stok ve kampanya planlamasını tahminden çıkarıp veriye dayandırır. Fiyat sayfasından da görebileceğin gibi, bu seviyede bir şema kurulumu ek bir maliyet gerektirmez, sadece doğru planlamayı gerektirir.
| Kontrol | Açıklama |
|---|---|
| dataLayer tek noktadan mı yükleniyor | Script her sayfada aynı sırayla çalışmalı, çift yükleme mükerrer olay yaratır |
| transaction_id benzersiz mi | Sayfa yenilemesinde purchase olayı tekrar tetiklenmemeli |
| currency alanı sabit mi | TL ile USD karışırsa gelir toplamı anlamsızlaşır |
| Olay sunucu tarafında mı doğrulanıyor | Sadece sayfa yüklenince tetiklenen olay reklam engelleyicilerde kaybolur |
| Test satışları filtreleniyor mu | Demo/test işlemleri gerçek rapora sızmamalı |
Script Tarafı mı, Panel Tarafı mı: Olayı Nereden Tetiklemelisin?
En sık yapılan hata, "purchase" olayını sadece teşekkür sayfası yüklendiğinde tetiklemek. Kullanıcı sayfayı yenilerse olay bir kez daha sayılır; sekmeyi erken kapatırsa hiç sayılmaz; reklam engelleyici kullanıyorsa script hiç çalışmaz. Daha sağlam yöntem, olayı ödeme sağlayıcıdan gelen onay webhook'una bağlı olarak panel tarafında tetiklemek ve oradan Measurement Protocol üzerinden GA4'e göndermek. Böylece bir e-pin satış yazılımı, kullanıcının tarayıcı davranışından bağımsız, sadece gerçek parasal onaya dayalı bir kayıt üretir; müşteri sayfayı kapatsa da işlem sunucuda onaylandığı anda doğru veri GA4'e ulaşır. Bu yaklaşım aynı zamanda tarayıcı eklentilerinin veya gizlilik ayarlarının scripti engellediği durumlarda da işe yarar, çünkü panel tarafı tetikleme tarayıcıdan bağımsız çalışır. Script tarafı tetikleme huninin üst kısmı, yani görüntüleme ve sepet adımları için uygundur; ama parayla ilgili son adımın sorumluluğu panelde olmalı, çünkü orası tarayıcıdan çok daha güvenilir bir kaynaktır.
Her purchase olayına sipariş numaranı transaction_id olarak bağla. GA4 aynı transaction_id'yi tekrar gördüğünde geliri bir kez sayar; sayfa yenilense de, kullanıcı geri tuşuna bassa da rakamların şişmez.
Veri Tutmayan Bir GA4 Kurulumunun Belirtileri
Bazı belirtiler kurulumun bozuk olduğunu doğrudan söyler: panel ile GA4 arasında gelir farkı yüzde yirmiyi geçiyorsa, aynı gün içinde dönüşüm sayısı gerçek sipariş sayısından fazlaysa, veya hiç satış yapılmayan bir saat diliminde "purchase" olayı görünüyorsa, şema bir yerde kırık demektir. Benzer şekilde mobil tarayıcıdan gelen siparişlerin masaüstü oranına göre aşırı düşük görünmesi de genelde bir olay kaybı belirtisidir, cihaz farkı değil. Bu tür tutarsızlıkları haftalık değil günlük kontrol etmek, sorunu büyümeden yakalamanı sağlar. Bu belirtileri görmezden gelen bir e-pin scripti sahibi, aslında günlük kararlarını hayali verilerle alıyor demektir; hangi kampanyanın durdurulacağı, hangi oyuna stok ayrılacağı, hangi saatte destek ekibinin güçlendirileceği, hepsi bu rakamlara bakılarak belirlenir. Reklam bütçesini kapatıp açmak, kampanya metnini değiştirmek, yeni bir bölge sunucusuna yatırım yapmak; bunların hepsi önce doğru ölçümle anlam kazanır, aksi halde rastgele kararlar vermiş olursun.
Doğru Şema, Doğru Karar
Pinova, e-pin satış sürecindeki her adımı panelde net tutar; GA4 şemanı kurarken karşılaştıracağın gerçek veriye buradan ulaşırsın.
E-pin satışını GA4'te tek "purchase" olayı olarak mı tanımlamalıyım?
Hayır. Purchase olayı huninin sonudur ama view_item, select_item, begin_checkout ve add_payment_info olayları olmadan sadece sonucu görürsün, nerede kaybettiğini göremezsin.
Pinova ile GA4 entegrasyonu script tarafında mı yoksa panelde mi kurulur?
İkisi birlikte çalışır: görüntüleme ve sepet olayları script tarafında, ödeme onayına bağlı purchase olayı ise panelden webhook üzerinden tetiklenerek daha güvenilir bir kayıt oluşturur.
Çoklu oyun ve kategori satan bir sitede item_category nasıl doldurulmalı?
Ana kategoriyi item_category'e, oyun veya platform adını item_category2 ya da item_variant alanına yazarak hem genel hem detaylı raporlama alabilirsin.
GA4'te mükerrer purchase olayı sorunu nasıl önlenir?
Her siparişe benzersiz bir transaction_id atayarak önlenir; GA4 aynı kimliği tekrar gördüğünde geliri bir kez sayar.
Teoride doğru görünen her şema, kendi trafiğinde ve kendi ödeme sağlayıcı kombinasyonunda farklı davranabilir. En güvenli yol, bu olay zincirini kendi dijital ürün satış yazılımı kurulumunda canlı olarak görmek: canlı demo üzerinden Pinova'nın panel tarafında hangi veriyi nasıl eşleştirdiğini inceleyebilir, kendi GA4 şemanı buna göre adım adım kurabilirsin. Bu adımı atlamadan önce kurduğun her olayı gerçek bir sipariş üzerinden tek tek doğrulamanı öneririz; küçük bir fark bile haftalar içinde yanlış bir reklam stratejisine dönüşebilir.