Ölçmek istediğin iş sonucunu tanımla
“Dönüşüm takibi kurulsun” talebi tek başına yeterli değildir. Bir dönüşüm, form gönderimi de olabilir, doğrulanmış sipariş de. Önce kendi işinde başarı saydığın sonucu ve ara adımları yaz. Böylece geliştirici hangi düğmeye basıldığını kaydettiğini değil, işletmenin hangi olayını temsil ettiğini bilir.
Bu sayfadaki plan üç modelle başlar: e-ticaret, randevulu işletme ve teklif/hizmet satışı. Bir işletmede birden fazla model bulunabilir. Örneğin ürün satarken ücretli kurulum randevusu da veriyorsan aynı müşterinin siparişini ve randevusunu ilişkilendir; bunları iki bağımsız ürün satışı gibi toplama.
Planı hazırlarken önce sonuca, sonra geriye doğru ara aşamalara bak. Hangi kayıt gerçek satış tutarını doğruluyor? İade nerede tutuluyor? İlk talep ile son işlem nasıl eşleşiyor? Yanıtları yoksa daha çok olay adı eklemek sorunu çözmez. Eksik kaynağı ve sorumlu kişiyi açıkça belirt.
İş modeline göre olayları seç
| Model | Başlangıç ve ara adımlar | Doğrulanacak sonuç | Sonradan gelen düzeltme |
|---|---|---|---|
| E-ticaret | Ürün inceleme, sepete ekleme, ödeme başlangıcı | Tanımlı koşulu karşılayan sipariş | İptal, kısmi veya tam iade |
| Randevu | Talep, uygunluk, rezervasyon | Gerçekleşen hizmet ve ayrı ödeme kaydı | Tarih değişikliği, gelmeme, iptal, iade |
| Teklif / hizmet | Talep, ihtiyaç değerlendirme, teklif | Kabul, gerçekleşen iş ve tahsilatın tanımlı aşamaları | Kapsam değişikliği, kayıp, iptal, bedel düzeltmesi |
Tablodaki adlar iş aşamalarını anlatır. Bunların tamamının her analitik veya reklam sisteminde hazır olay olarak bulunduğu varsayılmamalıdır. İç kayıt modelini oluşturduktan sonra gerekiyorsa platform alanlarına eşleştir. Kullanmadığın aşamayı sırf raporda sütun açılsın diye hayali olarak üretme.
GA4 e-ticaret dokümanı satın alma için purchase, iade için refund olaylarını ve işlem alanlarını açıklar. GA4 olay referansı ilk talep, nitelikli talep ve müşteriye dönüşmeyi de ayırır. Bunlar genel platform belgeleridir; belirli bir Madset entegrasyonunun kurulu veya aktif olduğu anlamına gelmez.
Her olaya açık bir gerçekleşme koşulu yaz
Bir olay için kısa bir sözleşme hazırla: adı, gerçekleşme koşulu, yetkili veri kaynağı, ilgili kayıt kimliği ve tekrar sayılmama kuralı. “Ödeme düğmesine basıldı” ile “ödeme doğrulandı” aynı olay değildir. Benzer şekilde takvim ekranının açılması randevu oluştuğunu, teklifin görüntülenmesi kabul edildiğini göstermez.
| Önerilen iç olay | Gerçekleşme koşulu | Dayanak |
|---|---|---|
| talep_acildi | Yeni ihtiyaç için tekil kayıt oluştu | Talep kaydı |
| talep_niteliklendi | Tanımlı uygunluk ölçütleri karşılandı | Değerlendirme kaydı ve sürümü |
| randevu_olustu | Belirli zaman için rezervasyon doğrulandı | Takvim / rezervasyon kaydı |
| hizmet_gerceklesti | İşin gerçekleştiği yetkili kayıtta doğrulandı | Operasyon kaydı |
| satis_dogrulandi | İşletmenin yazılı satış koşulu karşılandı | Sipariş veya finans kaydı |
| iade_kaydedildi | İlk satışa bağlı iade doğrulandı | İade kimliği ve ilgili satış |
Olayın tutarını da tanımla. Bir teklifin önerilen bedeli gerçekleşmiş satış geliri değildir. Kapora ile kalan tahsilatı ayrı ödeme hareketleri olarak saklayabilirsin; toplam sipariş bedelini her ödeme hareketinde yeniden gelir sayma. Ödeme alındı, iş gerçekleşti ve satış kaydı açıldı durumlarının ilişkisini geliştiriciye somut örnekle anlat.
Kimlik ve zaman alanlarını kur
Talep, sipariş, randevu ve iade için değişmeyen kimlikler kullan. Aynı müşterinin bütün işlemlerini tek kimliğe sıkıştırmak yerine müşteriyle işlem arasındaki ilişkiyi koru. Bir kişi iki ayrı sipariş verdiğinde iki sipariş olmalı; bir sipariş farklı sistemlerde görünüyorsa aynı işleme bağlanabilmelidir.
Asgari teknik kayıtta olay kimliği, kaynak sistem, ilgili iş kaydı, gerçekleşme zamanı, sisteme alınma zamanı ve tanım sürümü bulunsun. Parasal olaylarda tutar ve para birimi birlikte saklansın. Kampanya veya kaynak bilgisi mevcutsa ayrıca ilişkilendir; yoksa “kaynak bilinmiyor” durumunu kullan. Eksik kaynağa en son gördüğün reklamın adını atama.
Gerçekleşme zamanı ile işleme alınma zamanını ayırmak geç gelen kayıtları açıklamayı kolaylaştırır. Geçmişte oluşan bir satış bugün sisteme geldiğinde bugünün yeni satışına dönüşmemeli. Saat dilimini de belirt; farklı sistemlerin aynı günü farklı sınırlarla raporlaması günlük karşılaştırmayı bozabilir.
Tekrar kaydı durum değişikliğinden ayır
Aynı olay ağ sorunu nedeniyle yeniden gönderildiğinde ikinci bir satış üretmemeli. Bunun için kaynak olay kimliğiyle iş kayıt kimliğini birlikte kullanarak tekrar işleme kuralı belirle. Kimliğin farklı işletmelerde çakışmasını önlemek için işletme veya mağaza kapsamını da anahtarın parçası yap.
Her tekrar görünen kayıt kopya değildir. Aynı randevunun tarihi değişmiş, aynı siparişe kısmi iade gelmiş veya aynı talep yeniden değerlendirilmiş olabilir. Yeni durumu ayrı zamanlı değişiklik olarak sakla; ilk işlemi iz bırakmadan silme. Hangi olayın mevcut kaydı güncellediğini, hangisinin gerçekten yeni işlem oluşturduğunu yaz.
İlk canlı gönderimden önce normal işlem, tekrar gönderim, geç gelen kayıt, iptal ve kısmi iade senaryolarını dene. GA4 kullanıyorsan e-ticaret doğrulama rehberi olay ve parametreleri DebugView içinde incelemeyi önerir. İşletme kaydındaki adet ve tutarı da ayrıca karşılaştır; yalnız olayın ekranda görünmesi doğruluğunu kanıtlamaz.
Oranları aynı gruptan hesapla
Aşama oranının payı ve paydası aynı talep grubuna ait olmalı. Varsayımsal olarak aynı başlangıç dönemindeki 60 talepten 36'sı uygun, bunların 24'ü randevulu ve bu randevuların 18'i gerçekleşmiş olsun. Uygunluk oranı yüzde 60, uygun talepten randevuya geçiş yaklaşık yüzde 66,67, randevudan gerçekleşmeye geçiş yüzde 75'tir.
Son oranı değerlendirirken 24 randevunun tamamının planlanan zamanının gelmiş olması gerekir. Gelecek haftaya kayıtlı randevuyu bugün gelmedi diye sayma. Aynı nedenle yeni teklifleri henüz cevaplanmamışken kaybedildi olarak kodlama. Takip süresini işinin sonuçlanma ve düzeltme kayıtlarına göre belirle; sabit bir gün sayısını her modele uygulama.
Raporunda olgunlaşmış, takip süresi dolmamış ve sonucu eksik kayıtları ayrı göster. Oran oluşturmak için yeterli payda yoksa “hesaplanamıyor” yaz. Kaynak sisteme erişilememesini sıfır satış gibi sunma. Böylece küçük sayıların yanında ölçümün hangi kısmına güvenebileceğini de görürsün.
İadeyi ilk satışa bağla
Varsayımsal olarak 1.000 TL net ürün tutarıyla kaydedilen bir siparişe 200 TL kısmi iade gelirse aynı tabandaki net gelir 800 TL olur. İadeyi ilk satışla ilişkilendir; negatif tutarlı yeni bir müşteri gibi sayma. İlk gelir kaydı ile düzeltmeyi ayrı tutarak 800 TL'ye nasıl ulaştığını gösterebilirsin.
Maliyet tarafını otomatik olarak aynı oranda azaltma. Ürün geri alınmış olabilir fakat taşıma veya ödeme giderinin bir kısmı kalmış olabilir. Gelir ve gider düzeltmeleri kendi kanıtlarına dayanmalı. Ayrıca sipariş adedi ile net satış tutarı farklı göstergelerdir; kısmi iade bir siparişin varlığını ortadan kaldırmaz.
Gereksiz kişisel veriyi analitiğe taşıma
Müşteri hizmeti kaydıyla analitik olayın bilgi ihtiyacı aynı değildir. Google Analytics PII rehberi kişisel e-posta, telefon gibi bilgilerin ve bunları taşıyan URL veya kampanya parametrelerinin gönderilmemesi gerektiğini açıklar. Ham mesajı, müşteri adını veya telefonunu olay adı ve etiketinin içine koyma.
Planın teknik gereksinimlerini alan bazında yaz: hangi bilgi iç operasyonda kalacak, hangi sınırlı gösterge rapora gidecek? Rastgele bir kimlik kullanmak erişim ve saklama ihtiyacını ortadan kaldırmaz. Ayrıntılı müşteri kaydına erişimi görevle sınırla; analitik raporda karar için gereken toplu sonucu tercih et. İzin durumunu da uygulamanın ilgili veri akışına taşımasını planla.
Planın tamamlandığını nasıl anlarsın?
Bir geliştirici veya ekip arkadaşı, örnek bir işlemi senin açıklaman olmadan doğru sınıflandırabiliyorsa tanımın kullanılabilir hale gelmiştir. Bir sipariş, aynı siparişin tekrar bildirimi, kısmi iade ve kaynağı bilinmeyen talep için beklenen çıktıyı yaz. Test sonucunu beklenen adet ve tutarla karşılaştır.
Ölçüm planı şablonuna her olayın koşulunu, kaynağını ve kontrolünü ekle. Mesajla başlayan işlerde talep-satış ilişkisini kur. Planı devreye aldıktan sonra ilk kayıtları operasyonla birlikte incele; şema değişikliklerini sürümleyerek geçmiş ve yeni tanımların karışmasını önle.
