Çoğu e-pin satıcısı GA4 kurulumunu ölçme kodunu siteye yapıştırmak sanıyor. Ölçüm kodu head'de duruyor, GA4 panelinde kullanıcı sayısı akıyor, hatta gerçek zamanlı raporda o an sitede kaç kişi olduğunu görebiliyorsun. Buradan da 'kurulum tamam' sonucuna varıyorsun. Oysa o kod tek başına sana sadece trafik söyler; hangi ürünün hangi kanaldan kâr getirdiğini söylemez. Reklam bütçesi de tam bu boşluktan akıp gider.
Gerçek şu: GA4 e-ticaret ölçümü bir kod parçası değil, bir olay zinciridir. Zincirin tek halkası eksikse tablonun tamamı yanlış okunur. E-pin işinde bu eksik halka neredeyse her zaman aynı yerdedir: iframe içinde tamamlanan ya da sağlayıcıya yönlenip geri dönen ödeme adımı. Bu yazıda bir e-pin satış scripti üzerinde zincirin tamamını, doğru parametrelerle ve sunucu taraflı doğrulamayla nasıl kurduğunu anlatıyorum.
GA4 e-ticaret zinciri neden tek kod parçasıyla kurulmuyor?
GA4, alışveriş davranışını ayrı ayrı adlandırılmış olaylarla modeller: ürün görüntüleme, sepete ekleme, ödemeye başlama ve satın alma. Her olay, içine gömülen items dizisiyle hangi ürünün konuşulduğunu söyler. Bu dizinin içindeki ad, kategori, fiyat ve adet alanları tutarlı değilse GA4 raporu üretmeye devam eder ama rapor yanlış olur. En kötü senaryo da budur: sistem sessizce çalışır, sen yanlış veriye güvenerek bütçe dağıtırsın.
E-pin işinde bir ek zorluk var. Ürünler fiziksel değil, sepette bekleme süresi çok kısa, kategori adları tedarikçiye göre değişiyor ve aynı ürün farklı kupürlerde listeleniyor. Dolayısıyla dijital ürün satış scripti tarafında olay göndermeden önce ürün kimliğini standartlaştırman gerekir. Aksi halde GA4'te aynı oyunun kodu beş farklı isimle görünür, hiçbiri anlamlı hacme ulaşmaz ve raporda 'other' satırı şişer.
Hangi olayı hangi anda tetiklemelisin?
Sıralama, GA4'ün huni raporlarını doğru çizebilmesi için önemlidir. Ürün detay sayfası açıldığında view_item, kupür veya adet seçilip sepete eklendiğinde add_to_cart, ödeme yöntemi ekranına geçildiğinde begin_checkout, yöntem seçildiğinde add_payment_info ve sipariş gerçekten kapandığında purchase gönderilir. Kritik nokta şu: purchase olayı 'kullanıcı ödeme butonuna bastı' anında değil, ödemenin sağlayıcı tarafından onaylandığı anda gönderilmelidir.
Bunu kaçıran işletmelerde GA4 cirosu her zaman gerçek cironun üstünde çıkar, çünkü tamamlanmayan ödemeler de satın alma sayılır. Reklam platformları da bu şişmiş sinyale göre optimize eder ve bütçen dönüşmeyen kitleye akar. Sağlam bir e-pin yazılımında olay, sipariş durumu veritabanında 'ödendi' olarak işaretlendikten sonra tetiklenir.
| Olay | Tetikleme anı | Zorunlu parametreler | Sık yapılan hata |
|---|---|---|---|
| view_item | Ürün detay sayfası yüklenirken | currency, value, items | Kategori alanının boş bırakılması |
| add_to_cart | Kupür ve adet seçilip sepete eklenince | currency, value, items.quantity | Adet değişiminde olayın yeniden gönderilmemesi |
| begin_checkout | Ödeme adımı ekrana geldiğinde | currency, value, items | Sepet boşken sayfa yenilenince tekrar gönderim |
| add_payment_info | Ödeme yöntemi seçildiğinde | payment_type, value | Yöntem adının her seferinde farklı yazılması |
| purchase | Ödeme onayı veritabanına işlendiğinde | transaction_id, value, currency, items | transaction_id yerine rastgele değer kullanmak |
| refund | İade veya iptal işlendiğinde | transaction_id | İadenin hiç bildirilmemesi |
İframe içindeki ödeme dönüşünü nasıl doğru yakalıyorsun?
E-pin satışında ödeme çoğu zaman ya bir iframe içinde ya da sağlayıcının kendi alan adında tamamlanır. Kullanıcı oradan sitene döndüğünde tarayıcı yeni bir oturum başlatabilir, yönlendirme zinciri kaynak bilgisini silebilir ve purchase olayı ya hiç gönderilmez ya da 'referral' kaynağıyla gönderilir. İkinci durum daha tehlikelidir: satış kaydedilir ama hangi reklamdan geldiği kaybolur; reklam raporun temiz görünür, kanal raporun çöp olur.
Çözüm iki parçalı. Birincisi, ödeme sağlayıcının alan adını GA4 yönetim tarafında istenmeyen yönlendirenler listesine eklemek. İkincisi, dönüş sayfasında olayı istemciden değil, sunucu tarafında sipariş kaydına bağlı olarak göndermek. Ödeme bildirimi sunucuna düştüğü anda sipariş kaydındaki oturum kimliğiyle birlikte olayı iletirsen, kullanıcı tarayıcıyı kapatsa bile satın alma doğru kaynağa yazılır.
GA4 kurulumunda en sık eksik kalan olaylar
- purchase (ödeme dönüşü kaynaklı) 45%
- add_to_cart 25%
- view_item 20%
- refund 10%
Mükerrer satın alma kaydını hangi mekanizma engelliyor?
Kullanıcı ödeme onay sayfasını yenilerse, geri tuşuna basıp tekrar gelirse ya da sağlayıcı bildirimi iki kez gönderirse aynı sipariş iki kez sayılabilir. GA4 aynı transaction_id ile gelen tekrar kayıtları belirli koşullarda yakalar ama buna güvenmek doğru değil. Doğru yaklaşım, epin yazılım tarafında sipariş kaydına bir 'analitik gönderildi' bayrağı koymaktır. Bayrak set edilmişse olay bir daha üretilmez.
Bu küçük bayrak, aylık raporlarda yüzde onlara varan şişmeyi engeller. Özellikle yüksek trafikli kampanya günlerinde, iki kez sayılan siparişler ortalama sepet ve dönüşüm oranını birlikte bozar; sen de bir sonraki kampanyayı yanlış varsayımla kurgularsın. Kimliği siparişin kendi numarası olarak kullan, asla zaman damgası veya rastgele üretilmiş bir dize olarak değil.
Hangi özel parametreler e-pin işine gerçekten yarıyor?
Standart e-ticaret parametreleri gerekli ama yeterli değil. E-pin işine özel üç bilgi raporlamayı bambaşka bir seviyeye taşır: teslimat tipi (otomatik veya elle), tedarikçi kaynağı ve ödeme yöntemi. Bu üçünü olaylara özel parametre olarak eklersen, GA4'te 'hangi kanaldan gelen müşteri hangi ödeme yöntemiyle hangi teslimat tipini alıyor' sorusunu tek raporda yanıtlarsın. Elle teslimat oranının yüksek olduğu kaynaklar, aslında destek maliyetini artıran kaynaklardır.
Özel parametreleri gönderdikten sonra GA4 yönetim panelinde tanımlamayı unutma; tanımlanmayan parametre veri toplar ama raporda boyut olarak görünmez. Bu, kurulum yapan hemen herkesin bir kez yaşadığı tuzaktır. Tanımlama sonrası veri geriye dönük işlenmez, yani ne kadar geç tanımlarsan o kadar veri kaybedersin.
| # | Kontrol maddesi | Nasıl doğrularsın | Beklenen sonuç |
|---|---|---|---|
| 1 | Ölçüm kimliği tek ve doğru | Sayfa kaynağında tek G- kimliği ara | Çift kurulum yok |
| 2 | Beş temel olay tetikleniyor | DebugView ile test siparişi geç | Zincir sırayla görünüyor |
| 3 | purchase sunucu onayına bağlı | Ödemeyi yarıda bırak, olay gelmemeli | Sahte satın alma yok |
| 4 | Ödeme sağlayıcı hariç tutuldu | Yönetim, veri akışı ayarlarını aç | Yönlendiren listesinde kayıtlı |
| 5 | Mükerrer koruma bayrağı aktif | Onay sayfasını yenile | İkinci olay üretilmiyor |
| 6 | Özel boyutlar tanımlı | Özel tanımlar ekranını kontrol et | Raporda boyut olarak seçilebilir |
| 7 | İade olayı bağlandı | Bir test iadesi işle | Ciro raporu düzeltiliyor |
Kurulumdan sonra bir hafta boyunca GA4 cirosunu panelinin gerçek cirosuyla karşılaştır. Sapma yüzde beşin altındaysa zincir sağlamdır; üstündeyse önce purchase olayının tetikleme anına bak, sorun neredeyse her zaman oradadır.
Kurulum bittikten sonra hangi üç raporu kuruyorsun?
Birinci rapor kanal bazlı kârlılık: kaynak/aracı kırılımında ciro, sipariş sayısı ve ortalama sepet. İkinci rapor ürün performansı: hangi oyun ve hangi kupürün sepete eklenip satın alınmadığı. Üçüncü rapor huni: view_item'dan purchase'a kadar adım adım düşüş. Bu üçü, reklam bütçesinin nereye gideceğini tartışmasız hale getirir.
Bu raporları kurduğunda ilk fark edeceğin şey genelde şaşırtıcıdır: en çok trafik getiren kanal, en çok kâr getiren kanal olmaz. Yüksek hacimli ama düşük marjlı ürünlere trafik çeken kampanyalar ciroyu büyütür, kârı küçültür. Panelinin özellikler tarafındaki olay altyapısı bu ayrımı görmeni sağladığı anda bütçe dağıtımın kökten değişir.
Olay zinciri hazır kurulu gelen paneli dene
Pinova, e-ticaret olaylarını sipariş durumuna bağlı olarak üreten, mükerrer korumalı ve özel parametre destekli bir e-pin satış yazılımıdır. Fiyat ve lisans detaylarına göz at.
GA4 kurulumu için etiket yöneticisi şart mı?
Şart değil. Olayları doğrudan panel kodundan göndermek, e-pin gibi sipariş durumuna bağlı akışlarda daha güvenilirdir. Etiket yöneticisi pazarlama ekibi birden fazla araç yönetiyorsa avantaj sağlar.
purchase olayı neden gerçek cirodan yüksek çıkıyor?
Neredeyse her zaman olayın ödeme onayı yerine buton tıklamasına bağlanmasından ya da onay sayfası yenilendiğinde tekrar gönderilmesinden kaynaklanır. Sipariş kaydına bayrak koyarak çözülür.
İade olayını göndermezsem ne olur?
GA4 cirosu şişmiş kalır ve reklam platformları yanlış değere göre optimize eder. İade hacmi yüzde beşi geçen işletmelerde bu fark bütçe kararlarını doğrudan bozar.
Özel parametreleri sonradan ekleyebilir miyim?
Ekleyebilirsin ama veri geriye dönük işlenmez. Tanımı yaptığın günden sonrası raporlanır, öncesi kaybedilir; bu yüzden kurulumun ilk gününde tanımlamak en doğrusudur.
Ölçüm doğru kurulduğunda reklam yönetimi tahmin işi olmaktan çıkar; hangi kuruşun hangi kodu sattığını görürsün. Olay zincirinin panel içinden nasıl yönetildiğini, hangi parametrelerin hazır geldiğini ve test siparişinde akışın nasıl göründüğünü canlı demo üzerinde kendi gözünle inceleyebilir, kendi kurulumunda eksik kalan halkayı oradaki akışla karşılaştırarak bulabilirsin.