Dönüşüm takibi kurulum rehberi

Dönüşüm takibi kurulumu, işletmenin başarı saydığı işlemleri doğru anda ve doğru tanımla kaydetme işidir. Etiketin sayfada bulunması yeterli değildir. Başarısız form, tekrar yüklenen teşekkür sayfası veya iki kez gönderilen satın alma olayı raporu bozabilir. Bu rehber ölçüm planından test ve bakıma kadar uygulanabilir bir sıra sunar.

Kurulumun amacı bütün hareketleri toplamak değil, karar vermek için gerekli veriyi güvenilir biçimde üretmektir. Kullanıcı tercihleri ve veri kapsamı baştan düşünülür. İşletmenin gerçek kayıtlarıyla analitik verinin neyi temsil ettiği ayrılır. Ölçüm eksikliğinin ticari etkisi dönüşüm takibi yazısında açıklanır.

1. İş hedeflerini olaylardan önce tanımlayın

Satın alma, uygun teklif talebi veya randevu gibi ana hedefler yazılır. Bunların hangi aşamada gerçekleşmiş sayılacağı belirlenir. Form düğmesine basmak ile başvurunun kaydedilmesi aynı değildir. Telefon tıklaması ile görüşme veya satış da ayrı aşamalardır.

Satış ekibiyle ortak tanımlar oluşturulur. Başvuru, uygun başvuru, teklif ve kazanılan iş gibi durumlar netleştirilir. Ölçüm planının yalnızca teknik isimlerden oluşmaması gerekir. Her olayın işletme açısından anlamı ve kullanılacağı karar açıklanmalıdır.

2. Mevcut etiket envanterini çıkarın

Site kodu, etiket yöneticisi, eklenti ve panel ayarları incelenir. Aynı araç birden fazla yoldan kurulmuş olabilir. Hangi hesap veya mülke veri gittiği kaydedilir. Eski ajans veya test hesabına ait kimlikler kontrol edilir.

Bir etiketi kaldırmadan önce amacını ve bağımlılıklarını öğrenin. Görünürde kullanılmayan kod belirli bir kampanya veya rapor için gerekli olabilir. Buna karşılık aynı dönüşümün iki yoldan gönderilmesi tekrar sayımı oluşturabilir. Envanter, sadeleştirme ve test planının temelidir.

3. Ölçüm planı tablosunu hazırlayın

Olay adı, iş tanımı, tetiklenme koşulu, parametreler, veri hedefi ve sorumlu kişi yazılır. Başarı ile yardımcı davranışlar ayrılır. Örneğin form başlangıcı teşhis için, başarılı kayıt ana sonuç için kullanılabilir. Her olayın neden gerekli olduğu açıklanır.

Planın kapsamı yönetilebilir tutulur. Kullanılmayacak onlarca olay eklemek bakım yükünü artırır. Önce temel kullanıcı görevleri güvenilir ölçülür. Sonraki ihtiyaçlar veriyle ortaya çıktığında plan genişletilebilir. Event maddesi olay ve parametre ilişkisini açıklar.

4. Hesap ve veri akışlarını doğrulayın

GA4 mülkü, web veri akışı ve reklam hesabı ilişkileri kontrol edilir. İşletme uygun yönetici erişimine sahip olmalıdır. Test ve canlı ortamların verilerinin nasıl ayrıldığı belirlenir. Yanlış kimlik üzerinden çalışan etiket fark edilmeden uzun süre veri kaybı yaşanabilir.

Zaman dilimi ve raporlama para birimi gibi ayarlar kaydedilir. Farklı sistemler karşılaştırılırken bu ayrımlar düşünülür. Kurulum erişimleri tek kişinin kişisel hesabına bağımlı bırakılmaz. Değişiklik yapabilecek kişiler ve yayın yetkileri düzenlenir.

5. Kullanıcı tercihlerine göre davranışı tasarlayın

Çerez tercihi öncesinde, kabulden sonra ve reddetmeden sonra hangi etiketlerin nasıl çalışacağı belirlenir. Görsel banner ile teknik davranış tutarlı olmalıdır. Reddetme seçeneği bulunup aynı verinin değişmeden gönderilmesi doğru bir kurulum kabul edilmez.

Sunucu taraflı yöntem kullanmak bu değerlendirmeyi ortadan kaldırmaz. Google'ın sunucu tarafında izin davranışı açıklaması tercih sinyallerinin veri akışındaki rolünü gösterir. İşletmenin veri işleme düzeni ve uygun hukuki değerlendirme teknik planla birlikte ele alınır.

6. Başarı sinyalini uygulamadan alın

Form için en güvenilir başlangıç noktası, uygulamanın kaydın başarıyla oluştuğunu bildirmesidir. Sadece düğme tıklaması doğrulama hatalarını ayıramaz. Başarı yanıtında uygun olay oluşturulabilir. Kayıt başarısızsa başarı olayı gönderilmemelidir.

Teşekkür sayfası kullanılıyorsa doğrudan açılma ve yenileme durumları düşünülür. Aynı işlem tekrar sayılmamalıdır. Tek kullanımlık başarı bilgisi veya uygun işlem kimliği gibi yöntemler altyapıya göre uygulanabilir. Çözüm gerçek iş akışına dayanmalıdır.

7. Satın alma verilerini tanımlayın

İşlem kimliği, değer ve para birimi doğru gönderilmelidir. Değerin hangi toplam olduğu açıklanır. İndirim, kargo ve vergi tanımı raporlar arasında tutarlı tutulur. Ürün satırları gerekiyorsa kimlik, adet ve fiyat alanları kontrol edilir.

Başarısız ödeme satın alma değildir. Ödeme sonucu sunucuda doğrulanmadan olay göndermek yanlış veri oluşturabilir. Aynı siparişin tekrar bildirilmesi veya teşekkür sayfasının yenilenmesi test edilir. Sanal POS ve ölçüm akışı doğru başarı noktasında birleşmelidir.

8. Kişisel veriyi gereksiz parametrelere koymayın

Ad, telefon veya e-posta gibi bilgiler genel olay alanlarına ve URL parametrelerine gelişigüzel eklenmez. Formun kimliği ile kullanıcının kimliği farklı ihtiyaçlardır. Hangi verinin gerekli olduğu sorgulanır. Loglar ve hata raporları da kontrol kapsamındadır.

Google Analytics'in kişisel bilgi gönderimini önleme açıklaması veri tasarımında resmi referanstır. Otomatik maskeleme özelliği bulunsa bile yanlış veri göndermeyi baştan önlemek gerekir. Araç kullanımı, işletmenin kendi veri sorumluluğunun yerine geçmez.

9. Etiket yöneticisi kurallarını sade tutun

Etiket yöneticisi kullanılıyorsa adlandırma ve sürüm açıklamaları düzenlenir. Tetikleyicinin hangi gerçek davranışa karşılık geldiği anlaşılır olmalıdır. Çok genel tıklama kuralları yanlış öğeleri yakalayabilir.

Önizleme ortamında olay sırası ve parametreler incelenir. Aynı olayın kaç kez çalıştığı kontrol edilir. Yayın öncesinde değişiklik listesi gözden geçirilir. Eski etiketler kaldırılacaksa geri dönüş planı bulunur. Merkezi yönetim, kontrolsüz değişiklik yapmak anlamına gelmez.

10. Reklam dönüşümlerini amaçlarına göre ayırın

Google Ads gibi sistemlerde ana optimizasyon hedefi ile yardımcı gözlem olayları farklı düzenlenir. Sayfa görüntüleme, form başlangıcı ve satın almayı aynı başarı gibi toplamak iş hedefini belirsizleştirir. Hesap ve kampanya düzeyinde hangi hedefin kullanıldığı kontrol edilir.

Google'ın dönüşüm kurulum dokümanı veri kaynağı ve hedef ayarlarını açıklar. GA4 üzerinden içe aktarma ile doğrudan etiket kullanımı birlikte varsa tekrar sayımına dikkat edilir. Aynı işlemi iki ayrı ana hedef gibi değerlendirmek raporu ve optimizasyonu bozabilir.

11. UTM adlandırma standardı oluşturun

Kaynak, araç ve kampanya adları tutarlı seçilir. Büyük harf, boşluk ve farklı yazımlar aynı kanalın raporda parçalanmasına neden olabilir. Ekiplerin kullanacağı kısa bir tablo hazırlanır. Kampanya bağlantıları yayın öncesi açılarak kontrol edilir.

UTM parametreleri kişisel bilgi taşımamalıdır. İç bağlantılara rastgele kampanya etiketi eklemek kaynak değerlendirmesini karıştırabilir. Etiketler uygun dış bağlantılarda kullanılır. Parametrelerin form kaydında tutulması isteniyorsa veri kapsamı ve saklama düzeni ayrıca planlanır.

12. Atıf ve pencere ayarlarını kaydedin

Reklam etkileşimiyle dönüşüm arasında zaman olabilir. Dönüşüm penceresi ve atıf modeli raporlanan katkıyı etkiler. İki sistemin farklı sayılar vermesi her zaman kurulum hatası değildir.

Karşılaştırmada tarih aralığı, zaman dilimi ve olay tanımı eşleştirilir. Yeni dönemde henüz gerçekleşmemiş sonraki dönüşümler olabilir. Ayarlar değiştiğinde raporda not düşülür. Ölçüm modelinin kusursuz nedensellik kanıtı olmadığı unutulmamalıdır.

13. Tarayıcı ve sunucu olaylarını eşleştirin

Meta CAPI veya başka sunucu entegrasyonu kullanılıyorsa aynı işlemin iki kanaldan gelmesi düşünülür. Olay kimlikleri ve tekrar önleme yöntemi güncel entegrasyon dokümanına göre kurulur. Her gönderim yeni işlem değildir.

Sunucu yanıtının başarılı olması, gönderilen olayın iş açısından doğru olduğunu göstermez. Test siparişi gerçek kayıtla karşılaştırılır. Değer, zaman ve kimlik alanları incelenir. Erişim anahtarları gizli tutulur; kullanıcıya veya açık loglara taşınmaz. Sunucu taraflı takip ek bakım sorumluluğu getirir.

14. Başarılı ve başarısız senaryoları test edin

Form doğru doldurulur ve kayıt sistemde doğrulanır. Ardından eksik alan, geçersiz biçim ve sunucu hatası denenir. Başarı olayı yalnızca uygun durumda çalışmalıdır. Çift tıklama, sayfa yenileme ve geri gelme gibi tekrar senaryoları ayrıca kontrol edilir.

E-ticarette farklı ödeme yöntemleri ve iptal dönüşleri test edilir. Mobil ve masaüstü akışları ayrı denenir. Çerez tercihleri değiştirilerek beklenen etiket davranışı doğrulanır. Test kayıtları rapordan uygun biçimde ayrılır. Her senaryonun beklenen ve gerçekleşen sonucu saklanır.

15. İşletme kayıtlarıyla uzlaştırın

Form veya sipariş veri tabanındaki kayıtlar ölçüm verisiyle karşılaştırılır. Birebir eşitlik her koşulda beklenmeyebilir; tercih ve cihaz farkları gibi sınırlar vardır. Ancak büyük veya ani farklar araştırılmalıdır. Önce tanım ve dönem eşleştirilir.

Hizmet işletmesinde CRM durumları eklenir. Uygun olmayan başvuruların nedenleri kaydedilir. Böylece reklamın getirdiği sayıyla satış ekibinin gördüğü kalite ilişkilendirilir. Huni yaklaşımı web ve satış aşamalarını birlikte düşünmeye yardım eder.

16. Bakım ve uyarı düzenini kurun

Site güncellemesi, form değişikliği veya yeni ödeme yöntemi ölçümü etkileyebilir. Bu tür değişikliklerden sonra temel testler tekrarlanır. Olayların aniden sıfırlanması veya katlanması inceleme gerektirir. Her artış başarı olarak kutlanmadan önce veri doğruluğu kontrol edilir.

Ölçüm planının güncel sürümü ve değişiklik geçmişi saklanır. Sorumlu kişi ve kontrol sıklığı belirlenir. Ajans veya ekip değiştiğinde bilgi kaybolmamalıdır. Kurulum teslimi, olay listesi kadar test kanıtlarını ve bilinen sınırları da içermelidir.

Örnek test tablosu

Tablo kullanılan altyapıya göre genişletilir. Amaç belirli olay adlarını ezberlemek değil, gerçek işlem ile raporun aynı anlamı taşımasını sağlamaktır. Hata durumlarını test etmeyen bir kurulum, yalnızca en kolay senaryonun çalıştığını göstermiş olur.

Örnek teşhis: Başvurular neden iki kat görünüyor?

Varsayımsal bir sitede veri tabanında on başvuru bulunurken raporda yirmi olay görülsün. İlk kontrol, aynı etiketin hem site kodunda hem etiket yöneticisinde kurulup kurulmadığıdır. İkinci kontrol başarı yanıtı ve teşekkür sayfasının aynı olayı ayrı ayrı gönderip göndermediğidir. Sonra yenileme ve çift tıklama senaryoları denenir.

Bu durumda reklamı değiştirmeden önce ölçüm düzeltilmelidir. Yanlış sayım, sonuç başına maliyeti olduğundan düşük gösterir. Düzeltme tarihi kaydedilir; önceki ve sonraki dönem aynı tanıma sahipmiş gibi karşılaştırılmaz. İşletmeye rapordaki değişimin gerçek talep düşüşü değil, sayım düzeltmesi olabileceği açıklanır.

Doğru ölçüm bütün belirsizliği ortadan kaldırmaz. Ancak hangi sayının neyi temsil ettiğini açık hale getirir. Bu açıklık, bütçe ve içerik kararlarının daha sağlam verilmesini sağlar. Kurulumun değeri çok sayıda etiket eklemekten değil, güvenilir ve kullanılabilir veri üretmekten gelir.