E-pin Scripti GA4 Entegrasyonu: Reklam Bütçenin Nereye Buharlaştığını Gizleyen Eksik Olayı Bu Akşam Kendi Panelinde Nasıl Yakalarsın?

Ç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.

İ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.

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.

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.

Ö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.