Raporun destekleyeceği iş kararını yazın
İş kararına bağlı ölçümleme kurulumu için ilk soru hangi grafiği istiyoruz değil, hangi kararı vereceğiz olmalıdır. Ürün sayfasındaki ilgiyi, kabul edilmiş teklifi ve tamamlanmış satışı ayrı sorularla ele alın. Her sorunun iş sahibini belirleyin. Raporun hangi koşulda aksiyon doğuracağını yazmak, anlamı belirsiz olay sayılarından daha yararlıdır.
Örneğin teklif talebi artarken satışın kabul ettiği talepler azalabilir. Form kabulü talep miktarını anlatır; satış niteliği kaynak CRM durumuyla doğrulanır. İki soruyu tek dönüşüm toplamında eritmeyin. Dönem, kapsam ve hariç tutulan kayıtları birlikte belirtin. Örnek yalnızca bir planlama durumudur; herhangi bir Prix müşterisinin sonucu olarak sunulmaz.
Her karar için gerekli gözlem düzeyini seçin. Ürün grubu veya talep türü yeterliyse kişi ayrıntısı eklemeyin. Plan tablosuna karar sorusu, iş sahibi, kaynak ve beklenen kullanım yazın. Bir raporun sahibi veya kullanım kararı yoksa o ölçüyü kurmadan önce gerekliliğini yeniden değerlendirin.
Karar
Hangi ürün grubuna veya talep aşamasına müdahale edileceğini açık bir soruyla belirtin.
Kaynak
Satış için sipariş, talep kabulü için sunucu, satış niteliği için CRM durumunu tanımlayın.
Kullanım
Raporu okuyacak kişiyi ve bulguya karşı beklenen aksiyonu plan satırına ekleyin.
Tıklama ile doğrulanmış sonucu ayırın
Dönüşüm ölçümünün teknik tasarımı tıklama ile doğrulanmış sonucu ayırmalıdır. Bir ziyaretçi gönder düğmesine basıp doğrulama hatası alabilir; ağ isteği başarısız olabilir; sunucu isteği kabul edebilir. Bu durumlar farklıdır. Başarı olayını yalnızca düğme tıklamasına bağlamak, iş sisteminde oluşmayan talepleri başarılı gösterme riski taşır.
Form için kabul koşulunu yazın: backend isteği gerçekten kabul ettiğinde kullanıcıya gösterilen durum ile ölçüm sonucu uyumlu olmalıdır. Aynı kabulün sayfa yenilemesi veya yeniden görüntülenmesi yeni başvuru sayılmasın. Reddedilen alan, iletişim kesintisi ve kabul sonrası tekrar görüntüleme için ayrı kontrollü senaryolar planlayın. İsteğin kabul kanıtını e-posta teslim kanıtından ayrı tutun; iki sonucun sahibi ve doğrulama kaydı farklı olabilir.
Ara etkileşimler yine yararlı olabilir. Hizmet ayrıntısı açılması veya ürün incelemesi, karar yolunu anlatan davranışlardır; tamamlanmış satışla aynı değere sahip değildir. Olay sözlüğünde etkileşim, kabul edilmiş sonuç ve kaynakta sonraki iş durumu arasındaki farkı koruyun. Böylece raporu okuyan ekip bir tıklamayı müşteriye dönüşmüş kişi diye yorumlamaz.
OKUMADAN SONRAKİ ADIMA
Karardan başlayan bir ölçüm planı hazırlayalım
Yanıtlamak istediğiniz rapor sorularını ve kişisel verileri ayıklanmış olay sözlüğünü paylaşın. Kaynak, kabul testi ve bakım sorumluluğunu birlikte düzenleyelim.
Olay ve parametre sözlüğünü oluşturun
Ölçümleme uygulamasına devredilecek sözlükte olay adı kadar tetikleyici, parametre anlamı ve izin kapsamı da bulunmalıdır. Aynı alanın iki sayfada farklı anlamlara gelmesini önleyin. Parametre sözlüğünü örnek değer ve kabul koşuluyla yazın; yalnızca alan isimlerinden oluşan bir liste, uygulayıcının doğru kaynağı seçmesini sağlamaz.
Sabit seçeneklerden gelen talep türü gibi sınıfları serbest metinle doldurmayın. Beklenen seçenek dışındaki değerin nasıl işleneceğini belirtin. Birim, sayı biçimi, boş değer ve eksik alan kuralları ayrı olsun. Yeni bir ürün kategorisi veya form seçeneği eklendiğinde sözlüğün hangi sahibine haber verileceğini devir adımına ekleyin.
Olay adını veya teknik anahtarı değiştirmeden önce etkilenen raporları belirleyin. Eski ve yeni tanımlar karşılaştırılamıyorsa süreklilik varmış gibi bir grafik üretmeyin. Sözlüğe sürüm açıklaması ve gerçek değişiklik kaydı eklenebilir; geçmişte var olmayan ölçümün tarihini geriye taşımayın. Beklenen sonucu kaynaktan türetmek sözlüğün temel kabul ilkesidir.
| Plan alanı | Yazılacak bilgi | Kabul sorusu |
|---|---|---|
| Tetikleyici | Kaynak sistemdeki kesin durum | Bu durum gerçekten oluştu mu? |
| Parametre | Anlam, biçim ve izin verilen değer | Aynı alan her yerde aynı şeyi mi anlatıyor? |
| Rapor | İş sorusu ve okuyacak sorumlu | Sonuç hangi kararı destekliyor? |
E-ticaret işlemi ve iadeyi test edin
E-ticaret ölçümleme kapsamı, yalnızca satın alma olayının görünmesiyle tamamlanmaz. Ürün alanlarını, değeri, para birimini ve işlem kimliğini aynı kaynak siparişle karşılaştırın. Varyantlı, birden fazla adetli ve indirimli kontrollü siparişleri inceleme planına ekleyin. Her olayın hangi kaynak satırını anlattığı belli olsun; yalnızca ürün adının benzemesi satır eşleşmesinin kabulü değildir.
İşlem kimliği aynı siparişin tekrarını ayırmaya yardımcı olur; bütün satışlara aynı kimlik verilmemelidir. Teşekkür sayfası yenilendiğinde aynı satın alma tekrar yeni sonuç gibi davranmamalıdır. Değerin vergi, kargo ve indirim kapsamını ayrıca tanımlayın. Kaynak siparişle tutar uyuşmuyorsa yalnızca panelin toplamına bakarak kontrolü geçti saymayın.
İade için ayrı bir senaryo yazın. Tam ve kısmi iadenin hangi siparişe, ürüne ve tutara bağlandığı belli olmalıdır. İade kaydını satın alma kaydını silmekle eşitlemeyin. Kaynakta onaylanan iade ile olay yükünü karşılaştıracak kanıt hazırlayın. İptal edilmiş ödeme veya hiç tamamlanmamış checkout, iade edilmiş satışın aynısı değildir.
İzin, kişisel veri ve rapor kapsamını kontrol edin
İzin kapsamına göre ölçümleme tasarlanırken kişisel veri denetimi bütün alanları kapsamalıdır. Parametre sözlüğünde iş için gereken alanları ve izin kapsamını belirtin. E-posta, telefon ve kontrolsüz serbest metni olay parametrelerine koymayın. URL, sayfa başlığı ve hata mesajında aynı bilgilerin yanlışlıkla görünmesini de ayrıca inceleyin; hassas örnek değerleri paylaşım dosyasına taşımayın.
İzin durumu ile gözlenebilir rapor kapsamını birlikte açıklayın. Ölçülemeyen kişiler veya filtrelenen işlemler varken raporu işletmenin eksiksiz müşteri listesi gibi kullanmayın. Teknik DebugView gözlemi, raporun aynı tanımı işlediğini tek başına göstermez. Test ortamı, filtreler, beklenen işleme ve rapor hazır olma durumu ayrı kabul alanlarıdır.
Ads ile GA4 toplamları ayrıştığında önce dönem, dönüşüm tanımı, atıf yaklaşımı ve kapsamı karşılaştırın. Fark tek başına bozuk kurulum kanıtı değildir. Açıklanamayan ayrışmayı kaynak olay kanıtıyla araştırın. Uzlaşma kaydında kullanılan zaman dilimi, dahil edilen olaylar ve kapsam dışı işlemler görünsün; inceleyen kişi aynı filtrelerle karşılaştırmayı yeniden kurabilsin.
Ölçüm planını bakım sahibine teslim edin
Ölçüm planının uygulama devri sonunda geliştirici yalnızca olay listesini değil kabul beklentisini de almalıdır. Her satırda karar, kaynak, tetikleyici, parametreler, izin durumu, kontrollü test ve rapor kullanımı bulunsun. İş sahibi anlamı onaylasın; teknik sorumlu gözlenebilir davranışı doğrulasın. Bu iki onay birbirinin yerine geçmez.
Bakım kaydında yeni form, ödeme değişikliği, ürün şeması ve izin yönetimi güncellemesi gibi yeniden inceleme nedenlerini yazın. Raporu kullanan ekip olay sözlüğünden haberdar olsun. Teknik anahtar değiştiğinde rapor sahibi eski ölçünün devam ettiğini sanmamalıdır. Devir sırasında açık bulgular, sorumlu ve sonraki kontrol adımıyla birlikte taşınmalıdır.
Planın ilk sürümü bütün etkileşimleri kapsamak zorunda değildir. Karar için gerekli az sayıda doğrulanabilir olayla başlayıp kullanımını değerlendirin. Sonraki genişleme gerçek bir rapor sorusuna dayanmalıdır. Yeni olay eklenirken kaynak tanımı, kabul senaryosu, raporda kullanım amacı ve bakım sahibi birlikte güncellensin. Eski tanımla yeni tanımın karışmaması için değişiklik kaydında geçişin kapsamını açıklayın.
Karardan başlayan bir ölçüm planı hazırlayalım
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Her tıklamayı dönüşüm saymalı mıyız?
Hayır. Tıklamalar yolculuğu anlamak için ölçülebilir ama satış veya kabul edilmiş taleple aynı sonuç değildir. Önce iş kararını ve kaynak koşulunu tanımlayın; kritik sonuçları ara etkileşimlerden açıkça ayırın.
Form gönderimini ne zaman başarılı sayarız?
Sunucu talebi gerçekten kabul ettiğinde ve kullanıcıdaki durum bu kabulü doğru yansıttığında başarılı başvuru oluşur. Düğme tıklaması, doğrulama hatası veya iletişim kesintisi aynı sonuç değildir. Yeniden görüntüleme de yeni talep yaratmamalıdır.
GA4 ile Google Ads neden aynı sayıyı vermeyebilir?
Dönem, dönüşüm tanımı, atıf yaklaşımı, filtre ve izin kapsamı farklı olabilir. Farkı tek başına kurulum arızası saymayın. Karşılaştırma koşullarını eşleştirin, sonra açıklanamayan durumları kaynak kaydı ve olay kanıtıyla araştırın.
E-posta adresini olay parametresine ekleyebilir miyiz?
Hayır. E-posta, telefon ve kişiyi tanıtan serbest metni Analytics parametrelerine göndermeyin. URL ve başlıkları da inceleyin. İşletme iletişim verisini uygun kaynak sistemde tutmakla anonim süreç ölçümünü ayrı tasarlayın.
DebugView onayı yeterli mi?
Hayır. DebugView kontrollü olayın gözlenmesini destekler; rapor tanımı ve kullanıma hazır olduğunu tek başına kanıtlamaz. Kaynak doğruluğu, izin, filtreler ve raporda beklenen yorum için ayrı kabul adımları gerekir.
KAPSAMI BİRLİKTE BELİRLEYELİM
Karardan başlayan bir ölçüm planı hazırlayalım
Yanıtlamak istediğiniz rapor sorularını ve kişisel verileri ayıklanmış olay sözlüğünü paylaşın. Kaynak, kabul testi ve bakım sorumluluğunu birlikte düzenleyelim.
Ölçüm planını konuşalım