Sayılarla ne demek?
Aynı satın alma hem tarayıcıdaki pikselden hem sunucudan gönderildiğinde platformun önünde iki kayıt olur. Bunların aynı olay olduğunu anlamasının tek yolu, ikisinin de aynı kimliği taşımasıdır.
Kimliğin işi bu kadar basit ama hata payı yok. Tarayıcıda bir değer, sunucuda başka bir değer üretilirse sistem iki farklı satın alma görür ve ikisini de sayar.
Bu maddede kimliğin nasıl üretileceği ele alınıyor; platformun eşleşen kayıtları nasıl birleştirdiği ise tekilleştirme başlığının konusu.
Nasıl üretilmeli?
| Yöntem | Değerlendirme |
|---|---|
| Sipariş numarası | Satın almada en güvenilir |
| Sunucuda üretilip sayfaya aktarılan değer | Genel çözüm |
| Tarayıcıda rastgele üretilen değer | Sunucu bilemez, çalışmaz |
| Zaman damgası | Çakışabilir, güvenilmez |
Üçüncü satır en sık yapılan hata. Kimlik yalnızca tarayıcıda üretildiğinde sunucu aynı değeri bilemiyor; iki taraf farklı kimlik gönderiyor ve eşleşme hiç kurulmuyor.
Nasıl kurulur?
- Tek kaynaktan üretin. Değeri sunucu belirlesin.
- İki tarafa aynısını verin. Piksel ve sunucu aynı değeri göndersin.
- Olay adını da eşleyin. Kimlik tek başına yetmez.
- Her olay için benzersiz tutun. Tekrar kullanmayın.
- Test ekranında doğrulayın. Birleştiğini görün.
Uygulamada ne oluyor?
En sık hata, kimliğin iki tarafta ayrı ayrı üretilmesi. Kurulum yapılmış görünüyor ama platform her satın almayı iki kez sayıyor ve raporlar şişiyor.
İkinci gözlem, kimliğin hiç gönderilmemesi. Sunucu tarafı entegrasyon ekleniyor ama kimlik alanı boş bırakılıyor; tekilleştirme için hiçbir dayanak kalmıyor.
Üçüncüsü, aynı kimliğin farklı olaylarda kullanılması. Sepete ekleme ve satın alma aynı değeri taşıdığında platform bunları yanlışlıkla birleştirebiliyor.
Dördüncüsü, olay adının iki tarafta farklı yazılması. Kimlik aynı ama bir tarafta "Purchase", diğerinde "purchase" gidiyor; eşleşme kurulmuyor.
Beşincisi, sipariş numarasının sayfaya taşınmaması. Sunucu siparişi biliyor ama teşekkür sayfasındaki piksel bu numarayı göremiyor; ortak bir kimlik kurmak imkansız hale geliyor.
Altıncısı, sayfa yenilendiğinde yeni kimlik üretilmesi. Kullanıcı teşekkür sayfasını yenilediğinde farklı bir değer gidiyor ve aynı sipariş tekrar sayılıyor.
Yedincisi, kimlik alanına kişisel veri konması. E-posta adresi benzersiz olduğu için kimlik olarak kullanılıyor; bu hem gereksiz hem kural dışı.
Sekizincisi, eşleşme oranının hiç kontrol edilmemesi. Platformlar kaç olayın başarıyla birleştiğini gösteriyor; bu oran izlenmediğinde kurulumun çalışıp çalışmadığı bilinmiyor.
Dokuzuncusu, gönderim zamanları arasındaki farkın büyümesi. Sunucu olayı çok geç gönderildiğinde bazı platformlar eşleşme penceresini aşıyor ve kayıtlar ayrı kalıyor.
Onuncusu, farklı platformlar için farklı kimlik mantığı kurulması. Meta, TikTok ve analitik için ayrı ayrı çözümler geliştirildiğinde bakım zorlaşıyor; tek bir kimlik hepsinde kullanılabilir.
On birincisi, satın alma dışındaki olayların unutulması. Sepete ekleme ve ödeme başlatma da iki taraftan gidiyorsa onların da kimliği olmalı; yalnızca satın almada kurulan eşleşme, ara adımları şişik bırakıyor.
On ikincisi, kurulumun yalnızca geliştiriciye bırakılması. Kimlik mantığı yazılı değilse site güncellemesinde değer üreten kod değişiyor ve eşleşme kimse fark etmeden bozuluyor; bu yüzden aylık kontrol listesinin bir maddesi olmalı.
Neyi çözmez?
Olay kimliği, hiç gönderilmemiş olayı geri getirmez. İki kaydı birleştirir; kayıp kaydı tamamlamaz.
Sıkça sorulan sorular
Kimliği nerede üretmeliyim?
Sunucuda. Tarayıcıda üretilen değeri sunucu bilemez.
Satın almada ne kullanmalıyım?
Sipariş numarası en güvenilir seçenek; hem benzersiz hem iki tarafın da bildiği bir değer.
Çalıştığını nasıl anlarım?
Platformun eşleşme oranını gösteren ekranından. Oran düşükse kimlikler tutmuyor.
Bu kavramın bütün resim içindeki yerini Dönüşüm Takibi ve Ölçümleme Rehberi içinde ayrıntılı anlattım.
GA4, GTM, Meta Pixel, CAPI, Google Ads dönüşüm, TikTok Pixel ve event doğrulama ile sağlam ölçümleme altyapısı.
