Sunucu taraflı dönüşüm takibi artık şart
Tarayıcı tarafı takip yıllardır olay kaybediyor. Reklam engelleyiciler, Safari’nin Intelligent Tracking Prevention’ı, Firefox’un varsayılan korumaları ve reddedilen çerez izni, dönüşüm olaylarını reklam platformuna ulaşmadan siliyor. Teklif verme algoritması bu durumda geriye kalan dönüşümlere göre ayarlanıyor; bunlar da çoğunlukla gizlilik ayarları gevşek kişilerden geldiği için örnek hem küçülüyor hem çarpıklaşıyor.
Sunucunun gönderdiği
Meta’nın Conversions API’si ve Google’ın Data Manager / Enhanced Conversions’ı ile sunucu taraflı takip, aynı olayları ajansın denetlediği bir sunucudan gönderir; olaylar tarayıcı pikseliyle eşleştirilir ve tekilleştirilir. Olaylar yalnız izin veren ziyaretçiler için gönderilir. Bu ziyaretçilerin olayları, reklam engelleyici ya da Safari’nin ITP’si tarayıcı pikselini durdursa da ulaşır.
Sunucu kopyası, aynı olay adını ve zaman damgasını taşıyan ikinci bir mesajdır: tarayıcı kopyasıyla paylaşılan bir olay kimliği (event ID), e-posta veya telefon gibi hash'lenmiş tanımlayıcılar, açılış URL'siyle gelen tıklama tanımlayıcısı, bir de sipariş tutarı ve para birimi. Bunların çoğu bir etiketleme meselesi değildir. Tıklama tanımlayıcısı bir kez, ilk sayfa görüntülemesinde gelir; dönüşüm ise daha sonra gerçekleşebilir, örneğin bir formdan, bir telefon görüşmesinden ya da elle verilen bir onaydan sonra. Bu tanımlayıcının, sonunda dönüşüme dönüşecek kaydın üzerinde saklanması gerekir.
Tıklama kimliğini talep kaydında bir sütunda saklıyoruz; talep iki hafta sonra dönüşüme dönse de kimlik yerinde durur. Her dönüşüm, yeniden gönderilebilen ve reklam platformunun raporlarıyla karşılaştırılabilen bir satır olur; sonraki her hata ayıklama adımı buna dayanır. Eşleşme kalitesi olaya göre değişir: teklif talebi ya da ödeme e-posta adresi ve telefon numarasıyla gelir, anonim bir ürün görüntülemesi ise neredeyse hiçbir şey getirmez.
Tekilleştirme nerede bozulur
Her iki kopya da platforma ulaşır ve platformun bunları ortak olay kimliğiyle tek bir kayda indirmesi beklenir. O kimlik yanlışsa, iki kopya iki dönüşüm olarak sayılır. Raporlanan dönüşümler şişer, edinme başına maliyet olduğundan daha iyi görünür ve bidding var olmayan bir sayıya doğru optimize eder. Bu arıza, hiç sunucu taraflı tracking olmamasından daha kötüdür; çünkü herkesin inanmak istediği yönde bozulur.
Bu yüzden kimlik bir kez, sunucuda üretilir ve sayfayla birlikte tarayıcıya verilir. İkinci tuzak yeniden denemelerdir: reklam platformuna yapılan çağrılar zaman aşımına uğrar ve yeniden deneme aynı olay kimliğini kullanmalıdır, çünkü yeni bir kimlik dönüşümü ikiler. Gönderim idempotenttir ve kayıt, başarılı bir gönderimin yapılıp yapılmadığını tutar.
İki taraf aynı parametreleri de göndermelidir. Göndermezlerse olay sayısı doğru kalırken eşleşme kalitesi düşebilir ve bu kolayca gözden kaçar.
Onay ve neyin yazıya döküldüğü
Sunucu taraflı takip bazen rızayı dolanmanın bir yolu diye satılıyor. İzin vermeyen ziyaretçiler için olay göndermek GDPR’a aykırıdır ve bunu kurmuyoruz. Sunucunun çerez bandı yoktur; rıza kararı yalnız tarayıcıda tutulursa sunucu, reddettiklerini hiç öğrenmediği için bu ziyaretçilerin olaylarını da gönderir.
Bu yüzden rıza kararı her olay kaydında bir alan olarak saklanır ve sunucu bir şey göndermeden önce o alanı okur. Bunların hiçbiri kurulmadan önce her olay için şunları yazıya döküyoruz:
olayın adı ve onu tetikleyen tam kullanıcı eylemi
gönderilen parametreler ve bunların hangilerinin kişisel veri olduğu
eşleştirmede kullanılan tanımlayıcılar ve nasıl hash'lendikleri
ham olay satırının silinmeden önce ne kadar saklandığı
O belge kapsamın kendisidir. Sabit fiyat ancak teslim edilecek iş bu kadar net yazıldığında işler; aynı belge entegrasyonun sonradan incelenmesini de sağlar.
Yayına aldıktan sonra
Ajans için etki, müşterinin zaten izlediği rakamlarda görünür. Raporlanan dönüşümler gerçek sayıya yaklaşır; teklif verme daha dolu, ama hiçbir zaman eksiksiz olmayan bir veriyle çalıştığı için edinme başına maliyet genellikle düşer.
Teslim edemeyeceğimiz şey, geri kazanımın temiz bir ölçümüdür. Tarayıcının kaybettiği olaylar hiç kaydedilmedi, yani bir taban yok; öncesi-sonrası karşılaştırmasını da yeniden başlayan öğrenme süreci ve eksik olanların yerini zaten tutan modellenmiş dönüşümler bozar. Artan raporlanmış dönüşümler entegrasyonun çalıştığını gösterir. Daha önce ne kadar talebin görünmez olduğunu ölçmez.
Lansmandan sonra bozulan bir entegrasyon kolayca gözden kaçar, çünkü tarayıcı pikseli rakam göndermeye devam eder. Bu yüzden tarayıcı ve sunucu olay sayılarını karşılaştırıp farkları işaretliyoruz; API sürüm değişiklikleri de önceden planlanır. Lansmandan sonra bunu kimin yapacağı kapsamda kararlaştırılır.
Sorumluluk da kayar: karma (hash) alınmış olsun ya da olmasın, müşteri tanımlayıcıları müşteri tarafındaki bir veritabanında saklanır ve oradan gönderilir; bu da sözleşmede yer almalıdır.
Bu tür işleri nasıl kapsamlayıp fiyatladığımız hizmetler sayfasında.
