İleri analitik ve GA4 danışmanlığı: veriyi en iyi karar vericiniz yapın.

İleri analitik ve GA4 danışmanlığı, bizim işin merkezinde duran hizmet. Reklam yönetimi doğru ölçüm üzerine kurulmadığında, ne kadar iyi yapılırsa yapılsın yanlış yöne gidiyor. Bu yüzden hangi hizmetle başlarsak başlayalım ilk iş verinin doğruluğunu kontrol etmek oluyor.

Bu sayfada ölçüm altyapısını hangi parçalarda kurduğumuzu, GA4’ün bilinmesi gereken sınırlarını, en sık hangi hataları bulduğumuzu ve kanal verilerini nasıl tek bir modelde birleştirdiğimizi anlattık. Tüm pazarlama hizmetlerimiz için ana sayfaya, bu başlığın bütününü görmek için veri ve analitik çözümleri sayfasına bakabilir, kurulumun adımlarını GA4 ve Google Tag Manager kurulumu yazısından okuyabilirsiniz. Doğrudan başlamak için ücretsiz performans analizi.

Neden ölçümle başlıyoruz

Reklam platformlarının panelleri birbiriyle çelişen rakamlar gösterir. Meta bir satışı kendi üzerine yazar, Google aynı satışı kendi üzerine yazar, analitik üçüncü bir rakam gösterir, muhasebe dördüncü bir rakam söyler. Bu dört sayı arasındaki farkı açıklayamayan bir kurulumda bütçe dağıtmak mümkün değil.

Fark yalnızca raporlama sorunu da değil. Reklam algoritmaları kime gösterileceğini gelen dönüşüm sinyalinden öğreniyor. Sinyal eksik ya da yanlışsa, algoritma yanlış öğreniyor ve bunun bedeli bütçe büyüdükçe artıyor. Yani bozuk ölçüm, sadece yanlış rapor değil, yanlış optimizasyon üretiyor.

Bir düşüş gördüğümüzde ilk sorduğumuz soru her zaman aynı: gerçekten mi düştü, yoksa ölçemiyor muyuz? Bu soruyu sormayan ekipler, ölçüm kesintilerini performans sorunu sanıp aylarca yanlış yerde çözüm arıyor.

Kurulumu dört parçada ele alıyoruz

Olay mimarisi

Hangi kullanıcı davranışının ölçüleceği baştan tanımlanıyor: ürün görüntüleme, sepete ekleme, ödeme adımları, satın alma, form gönderimi, telefon araması. Her olayın hangi parametrelerle geleceği yazılı hale getiriliyor. Bu belge olmadan kurulan ölçüm, birkaç ay sonra kimsenin ne anlama geldiğini bilmediği olay isimleriyle doluyor.

İsimlendirme standardı da bu aşamada belirleniyor. Aynı davranışın farklı yerlerde farklı isimlerle gönderilmesi, sonradan birleştirme aşamasında en çok vakit kaybettiren sorunlardan biri.

Etiket yönetimi

Etiketlerin tek bir yerden yönetilmesi ve tema koduna dağılmaması gerekiyor. Aynı olayın hem tema kodundan hem etiket yöneticisinden tetiklendiği kurulumlar, ciroyu iki katına çıkaran en yaygın hata kaynağı. Devraldığımız hesaplarda ilk kontrol ettiğimiz şey bu.

Etiket yöneticisinde ayrıca sürüm disiplini kuruyoruz. Kim, ne zaman, hangi değişikliği yaptı sorusunun cevabı olmadan, ölçümdeki bir kırılmanın sebebini bulmak tahmine kalıyor.

Sunucu taraflı ölçüm

Tarayıcı tarafındaki veri kaybı artık göz ardı edilemeyecek seviyede: reklam engelleyiciler, tarayıcı kısıtlamaları ve çerez onayı reddi verinin bir kısmını götürüyor. Sunucu taraflı gönderim, özellikle Meta tarafında Conversions API ile birlikte, algoritmanın eksik veriyle çalışmasını engelliyor.

Kurulumda dikkat ettiğimiz noktalar: olayların tarayıcı ile sunucu arasında eşleştirilip mükerrer sayılmaması, eşleştirme parametrelerinin yeterli doldurulması ve olay kalitesinin düzenli izlenmesi. Bu kurulum her marka için zorunlu değil ama ölçek büyüdükçe getirisi netleşiyor.

Çerez onayı ve Consent Mode v2

Onay yönetimi yanlış kurulduğunda iki yönlü zarar veriyor: ya toplanmaması gereken veri toplanıyor ya da onay veren kullanıcıların verisi de kayboluyor. En sık gördüğümüz hata, varsayılan durumun yanlış tanımlanması ve onay verildikten sonra sinyalin güncellenmemesi. Sonuç, tüm trafiğin reddedilmiş gibi işlenmesi oluyor ve bu ancak veri katmanına bakıldığında fark ediliyor.

Doğru kurulumda modellenmiş veri devreye giriyor ve onay vermeyen kullanıcıların davranışı istatistiksel olarak tahmin ediliyor. Ancak bu modellenmiş verinin ham veri aktarımında yer almadığını bilmek önemli; iki kaynağı karşılaştırırken bu fark hesaba katılmazsa yanlış sonuç çıkıyor.

Kanal verilerinin birleştirilmesi

Dört parça kurulduktan sonra asıl iş başlıyor: kanal verilerinin tek bir modelde toplanması. Reklam platformları, site analitiği, e-ticaret altyapısı ve varsa CRM verisi düzenli olarak tek bir yere akıtılıyor.

Buradaki kazanç, platformların birbiriyle çelişen iddiaları yerine tek bir tabloya bakarak karar verebilmek. Reklam panelinde iyi görünen bir kampanyanın gerçekte zarar ettirdiği durumlar ancak böyle ortaya çıkıyor. Aynı şekilde, panelde vasat görünen bir kanalın aslında diğer kanallara talep beslediği de burada görünür hale geliyor.

İkinci kazanç erken uyarı. Sitedeki bir ölçüm kesintisi, feed’de kaybolan ürünler ya da yanlış tetiklenen bir dönüşüm olayı, birleşik veriye bakıldığında günler içinde fark ediliyor. Sadece kanal paneline bakan bir ekip aynı sorunu ay sonunda ciro düştüğünde fark ediyor.

Birleştirilmiş verinin karar alınabilir hale getirilmesi ise ayrı bir başlık; panolar, uyarı kurguları ve dönemsel karşılaştırmalar için iş zekâsı sayfasına bakabilirsiniz. Verinin düzenli olarak taşınması tarafı ise ETL ve veri yönetimi başlığı altında.

GA4’ün bilinmesi gereken sınırları

GA4 iyi kurulduğunda güçlü bir araç, ancak ücretsiz sürümünün yapısal sınırları var. Bu sınırlar bilinmediğinde rapordaki bir rakam veri sanılıyor, oysa aracın kısıtından doğan bir çıktı oluyor.

Veri saklama süresi. Kullanıcı ve olay düzeyindeki ayrıntılı veri, ücretsiz sürümde sınırlı bir süre saklanıyor ve varsayılan ayar bu sürenin en kısasında geliyor. Yani bir yıl önceki döneme ayrıntılı kırılımla bakmak, ayar zamanında değiştirilmediyse mümkün olmuyor. Kurulumun ilk gününde düzeltilmesi gereken ayarların başında bu geliyor.

Kardinalite ve “(other)” satırı. Bir boyutun çok fazla farklı değeri olduğunda, GA4 az görülenleri tek bir “(other)” satırında topluyor. Ürün adı, sayfa yolu ya da kampanya adı gibi alanlarda bu satırın kabarması, raporun okunamaz hale gelmesi demek. Çözüm rapordan değil, isimlendirme standardından ve veri ambarına aktarımdan geçiyor.

Örnekleme. Belirli hacmin üzerindeki keşif raporlarında GA4 tüm veri yerine bir örneklem üzerinden hesap yapıyor. Küçük farkları örneklem üzerinden yorumlamak yanlış sonuç üretiyor; bu yüzden karar verilecek rakamları örneklenmemiş kaynaklardan alıyoruz.

Eşik uygulaması. Demografik verinin açık olduğu mülklerde, az sayıda kullanıcı içeren kırılımlar gizlilik gerekçesiyle raporda gösterilmiyor. Rapor boş görünüyor ama veri var; bunu bilmeyen ekipler “ölçüm bozuk” teşhisi koyuyor.

Ham veri aktarımı. GA4’ün veri ambarına aktarımı, arayüzdeki raporlarla birebir aynı sonucu vermiyor. Aradaki en önemli fark, onay vermeyen kullanıcılar için üretilen modellenmiş verinin ham aktarımda yer almaması. İki kaynağı karşılaştırırken bu fark hesaba katılmazsa, aynı dönemde iki farklı doğru rakam elde ediliyor ve hangisinin kullanılacağı tartışması başlıyor.

Bu sınırların çoğunun çözümü aynı yerde: kritik veriyi GA4 arayüzünde tutmak yerine veri ambarına akıtmak ve karar rakamlarını oradan üretmek. Taşıma tarafı için ETL ve veri yönetimi.

Dönüşüm değeri ve gelir doğruluğu

Dönüşümün sayılması yetmiyor; gönderilen değerin doğru olması gerekiyor. Reklam algoritmaları bu değere göre optimize ettiği için, yanlış değer yanlış bütçe dağılımı üretiyor.

Vergi ve kargo. KDV ve kargo bedeli dahil gönderilen bir sipariş değeri, gerçekte kazanmadığınız tutarı algoritmaya gelir olarak bildirmek demek. Bunun somut sonucu, marjı düşük ürünlere daha fazla bütçe akması. Standart kurulumumuzda değeri vergi ve kargo hariç gönderiyoruz.

İndirim ve kupon. Sepette uygulanan indirimin değere yansıtılmaması, cironun sistematik olarak şişmesine yol açıyor. Kupon kullanımının ayrıca ölçülmesi, kampanyaların gerçek maliyetini görmek için de gerekli.

İptal ve iade. Ölçüm siparişte biterse, iade oranı yüksek kategorilerde raporlanan ciro ile tahsil edilen tutar arasında kalıcı bir fark oluşuyor. İadelerin dönemsel olarak geri beslenmesi ya da en azından kategori bazında iade oranının bilinip hedeflerin ona göre kurulması gerekiyor.

Katkı payı. Marjı birbirinden farklı ürünler satan işlerde, ciro üzerinden kurulan hedef yanıltıyor. Mümkün olduğunda ürün maliyetini de veriye dahil edip hedefi katkı payı üzerinden kuruyoruz. İlgili kavramlar: ROAS nedir ve müşteri edinme maliyeti.

Para birimi. Birden fazla para biriminde satış yapan sitelerde dönüşüm değerinin hangi kurdan gönderildiği çoğu zaman kontrol edilmiyor. Tüm siparişler tek para birimindeymiş gibi toplandığında ciro tamamen yanlış çıkıyor ve bu hata aylarca fark edilmeyebiliyor.

Devraldığımız kurulumlarda en sık bulduklarımız

Dönüşümün iki kez sayılması. En yaygın ve en pahalı hata. Ciro iki katına çıkıyor, reklam algoritmaları bu şişik veriye göre optimize ediyor, bütçe kararları yanlış temele oturuyor.

Kanal parametrelerinin kaybolması. Yönlendirmeler sırasında kampanya etiketlerinin düşmesi, ücretli trafiğin doğrudan trafik olarak kaydedilmesine yol açıyor. Kanal performansı olduğundan kötü görünüyor.

Ödeme sağlayıcısının yönlendirme sorunu. Ödeme sayfasına çıkıp geri dönen kullanıcının yeni oturum açması, satışın yanlış kanala yazılmasına sebep oluyor. Yönlendirme alan adının hariç tutulmaması sık rastlanan bir eksik.

Test trafiğinin filtrelenmemesi. İç ekibin ve geliştirme ortamının trafiği veriye karışıyor; küçük hacimli hesaplarda bu fark kayda değer boyutta olabiliyor.

Ölçüm kesintisinin fark edilmemesi. Site güncellemesi sonrası etiketlerin düşmesi, bir eklenti çakışması ya da tema değişikliği verinin bir kısmını sessizce yok ediyor. Ciro düşmüş gibi görünüyor, oysa düşen ölçüm. Bu yüzden ölçüm sağlığını izleyen otomatik uyarılar kuruyoruz.

Nasıl çalışıyoruz

Denetim. Mevcut kurulumun tam röntgeni: olaylar, etiketler, onay kurgusu, kanal ayrımı, hesap ve mülk sahiplikleri. Çıktı yazılı bir belge ve önceliklendirilmiş bir düzeltme listesi.

Tasarım. Olay mimarisi ve isimlendirme standardı belgeye bağlanıyor. Bu adım atlandığında kurulum kısa vadede çalışıyor ama bakımı imkânsız hale geliyor.

Uygulama. Etiket kurulumları, sunucu taraflı yapılandırma ve onay entegrasyonu. Site tarafında geliştirme gerektiren başlıklar ayrı listelenip teknik ekibe iletiliyor.

Doğrulama. Her olayın gerçekten ve yalnızca bir kez tetiklendiği tek tek test ediliyor. Kurulumun bittiğini test raporu söylüyor, kurulumu yapan kişi değil.

İzleme. Ölçüm sağlığı sürekli izleniyor. Olay hacminde ani düşüş, parametre kaybı ya da onay oranında değişim olduğunda uyarı üretiliyor.

Çevrim dışı dönüşümler ve CRM

Satışın sitede bitmediği işlerde ölçümün de sitede bitmemesi gerekiyor. Form dolduran kişinin gerçekten müşteriye dönüşüp dönüşmediği geri beslenmediğinde, algoritma en kolay formu dolduran kişiyi bulmaya yöneliyor.

Hangi olayın geri besleneceği. Formu değil, satış ekibinin nitelikli saydığı görüşmeyi ya da kapanan satışı geri besliyoruz. Hangi aşamanın seçileceği satış döngüsünün uzunluğuna bağlı: çok uzun döngülerde kapanan satışı beklemek, algoritmanın öğrenmesi için fazla geç kalıyor. Bu durumda ara bir aşama seçiliyor.

Kimlik eşleştirme. Site tarafındaki tıklama ile CRM’deki kaydın eşleşmesi gerekiyor. Bu, tıklama kimliğinin form kaydına yazılması ve CRM’de saklanmasıyla yapılıyor. Kurulumun en çok atlanan ve sonradan eklenmesi en zor parçası burası.

Gecikme yönetimi. Çevrim dışı dönüşümler platformlara belirli bir süre içinde gönderilmek zorunda; bu pencere kaçırıldığında veri kabul edilmiyor. Aktarımın günlük ve otomatik çalışması gerekiyor, elle yapılan dışa aktarımlarla yürümüyor.

Değer gönderimi. Kapanan satışın tutarı da gönderildiğinde, algoritma sadece daha çok değil daha değerli müşteri aramaya başlıyor. Uzun döngülü işlerde en büyük fark bu adımda ortaya çıkıyor.

Telefon aramaları. Türkiye’de hizmet işlerinin önemli bir kısmı telefonla ilerliyor. Arama takibi kurulmadığında bu kanal tamamen ölçüm dışında kalıyor ve reklam bütçesi, ölçülebilen ama daha değersiz olan form kanalına kayıyor.

E-ticaret olay mimarisi

E-ticarette ölçümün omurgasını satın alma yolculuğunun adım adım izlenmesi oluşturuyor. Sadece satın alma olayını ölçen bir kurulum, nerede kaybettiğinizi söylemiyor.

Adımların tamamı ölçülür. Ürün listesinin görülmesi, ürünün seçilmesi, ürün sayfasının görüntülenmesi, sepete ekleme, sepetin görüntülenmesi, ödeme adımının başlaması, ödeme bilgisinin girilmesi ve satın alma. Bu zincir kurulduğunda terk noktası tahminle değil ölçümle bulunuyor; dönüşüm oranı optimizasyonu çalışmasının girdisi de bu veri oluyor.

Ürün verisinin her olaya eklenmesi. Ürün kimliği, adı, kategorisi, markası, varyantı, fiyatı ve varsa indirim bilgisi her adımda gönderiliyor. Ürün kimliğinin reklam platformlarındaki feed kimliğiyle aynı olması kritik; farklı olduğunda katalog reklamları ile analitik verisi birbirine bağlanamıyor.

Liste ve konum bilgisi. Ürünün hangi listede ve kaçıncı sırada görüldüğü ölçüldüğünde, kategori sıralamasının ve öneri alanlarının katkısı hesaplanabiliyor. Bu, çoğu kurulumda eksik olan ve kolayca eklenebilen bir katman.

Ödeme yöntemi ve kargo seçimi. Hangi ödeme yönteminde terk oranının yükseldiği, ancak bu parametreler gönderildiğinde görülüyor. Türkiye’de taksit seçeneklerinin dönüşüme etkisi kayda değer olduğu için bu kırılımı standart olarak kuruyoruz.

Kullanıcı kimliği. Üye girişi yapan kullanıcılar için kalıcı bir kimlik gönderildiğinde, cihazlar arası yolculuk birleşiyor ve tekrar satın alma davranışı ölçülebiliyor. Bu kimliğin kişisel veri içermeyen, geri çözülemez bir değer olması gerekiyor.

Atıf: rakamların neden tutmadığı

Ölçüm kurulumu doğru olsa bile kanal panelleri farklı rakamlar göstermeye devam eder, çünkü her biri farklı bir atıf mantığı kullanır. Bunu bir hata sanıp düzeltmeye çalışmak yerine, farkın nereden geldiğini bilerek karar vermek gerekiyor.

Farklı zaman pencereleri. Bir platform tıklamadan sonraki yedi günü, diğeri otuz günü sayıyor olabilir. Aynı satış, biri için kapsam içinde diğeri için dışında kalıyor.

Görüntülemeye dayalı atıf. Bazı platformlar tıklanmamış ama görüntülenmiş reklamları da dönüşüme ortak sayıyor. Bu, katkının olduğundan büyük görünmesine yol açan en yaygın sebep.

Son tıklama önyargısı. Site analitiği genellikle son tıklamayı ödüllendiriyor. Bu model, talep üreten üst huni kanallarını sistematik olarak cezalandırıyor ve marka aramalarını olduğundan başarılı gösteriyor.

Platformlar arası çakışma. Aynı satış birden fazla platform tarafından sahiplenildiğinde, toplam raporlanan ciro gerçek cironun katlarına çıkıyor.

Bizim yaklaşımımız bu farkı gizlemek yerine görünür kılmak. Birleşik tabloda her kanalın kendi iddiası, analitiğin gösterdiği tablo ve sipariş sistemindeki gerçek rakam yan yana duruyor. Bütçe kararı, platformun iddiasına göre değil bu üçlü karşılaştırmaya göre veriliyor. Nihai soru her zaman aynı: bu kanal olmasaydı bu satış gerçekleşir miydi?

Ölçüm sağlığı ve uyarılar

Kurulum bir kez yapılıp bitmiyor. Site her güncellendiğinde, her yeni eklenti kurulduğunda ve her tema değişikliğinde ölçüm bozulabiliyor. Bozulmanın sinsi tarafı, hata mesajı üretmemesi: veri sessizce azalıyor ve bu, performans düşüşü gibi görünüyor.

Bu yüzden ölçümü izleyen otomatik kontroller kuruyoruz. Düzenli baktığımız sinyaller şunlar:

Olay hacmindeki ani değişim. Satın alma ya da form olayının günlük sayısı, beklenen aralığın dışına çıktığında uyarı üretiliyor. Ani düşüş kadar ani artış da inceleniyor; artış çoğu zaman çift sayımın habercisi.

Parametre kaybı. Dönüşüm değeri boş gelen olayların oranı, kampanya parametresi olmayan oturumların payı ve eşleştirme parametrelerinin doluluk oranı. Bunlardaki bozulma, raporlarda görünmeden önce optimizasyonu etkiliyor.

Onay oranı. Çerez onayı veren kullanıcı oranındaki ani değişim, genellikle onay bandı üzerinde yapılan bir değişikliğin habersiz yan etkisi oluyor.

Kaynak tutarlılığı. Analitikteki sipariş sayısı ile e-ticaret altyapısındaki sipariş sayısı arasındaki fark günlük karşılaştırılıyor. Farkın belirli bir bandın dışına çıkması, ölçümde bir şeyin kırıldığını gösteren en güvenilir sinyal.

Yayın öncesi kontrol. Sitede büyük bir güncelleme planlanıyorsa, ölçüm kontrolünü yayın planının bir maddesi haline getiriyoruz. Sonradan fark edilen bir kesintinin verisi geri gelmiyor; kaybedilen gün kalıcı olarak kayıp.

Hangi araçlarla çalışıyoruz

Araç seçimini markanın ölçeğine ve ihtiyacına göre yapıyoruz; her markaya aynı yığını kurmuyoruz.

Ölçüm katmanı. GA4 ve Google Tag Manager standart. Sunucu taraflı kurulum gerektiğinde sunucu tarafı etiket yöneticisi devreye giriyor. Meta tarafında Conversions API, diğer kanallarda karşılık gelen sunucu taraflı arayüzler kullanılıyor.

Onay yönetimi. Consent Mode v2 ile uyumlu bir onay platformu. Buradaki seçim kadar önemli olan, varsayılan durumun doğru tanımlanması ve onay sonrası sinyalin güncellenmesi.

Veri ambarı. Kanal verilerinin toplandığı yer. Markanın kendi hesabında kuruluyor, erişimi siz yönetiyorsunuz. Taşıma ve dönüştürme tarafının detayları ETL ve veri yönetimi sayfasında.

Raporlama. Birleştirilmiş veriyi karar alınabilir hale getiren panolar ve uyarı kurguları. Ayrıntı iş zekâsı sayfasında.

Sık sorulan sorular

GA4 kurulumu ne kadar sürer?

Standart bir e-ticaret kurulumunda temel olay mimarisi ve etiket düzeni iki ile üç hafta arasında tamamlanıyor. Sunucu taraflı ölçüm ve CRM entegrasyonu bunun üzerine ekleniyor. Süreyi uzatan şey genellikle teknik zorluk değil, site tarafındaki geliştirme kaynağına erişim.

Universal Analytics verimiz duruyor, ne olacak?

Eski mülkteki tarihsel veriye erişim kalıcı değil ve iki sistemin ölçüm mantığı zaten farklı olduğu için rakamlar birebir kıyaslanamıyor. Doğru yaklaşım, geçmiş veriyi dışa aktarıp saklamak ve karşılaştırmaları yeni sistemin başlangıç tarihinden itibaren kurmak. Eski ve yeni rakamları yan yana koyup fark üzerinden yorum yapmak yanlış sonuç üretiyor.

Sunucu taraflı ölçüm zorunlu mu?

Zorunlu değil ama ölçek büyüdükçe getirisi artıyor. Küçük bütçelerde tarayıcı taraflı kayıp sınırlı kalırken, harcama büyüdükçe algoritmanın eksik öğrenmesi somut kayba dönüşüyor. Kurulum tek seferlik bir iş, faydası kalıcı.

Verilerimiz nerede saklanıyor?

Veri ambarı markanın kendi hesabında kuruluyor. Erişimi siz yönetiyorsunuz, çalışma bittiğinde veri sizde kalıyor. Ajansın kendi altyapısında tutulan kurulumlar, ayrılık anında geçmiş verinin de kaybedilmesi anlamına geliyor; bu yüzden bu modeli kullanmıyoruz.

Ölçümü siz kurup yönetimi başka ajansta bırakabilir miyiz?

Evet, bu kurgu çalışıyor ve bazı durumlarda tercih ediliyor. Ölçüm ve raporlamanın kanal yönetiminden bağımsız bir tarafta durması, ekibin kendi çalışmasını denetlemesi sorununu ortadan kaldırıyor. Bu durumda kapsamı ve kimin neyden sorumlu olduğunu baştan yazılı hale getiriyoruz.

Rakamlarımız düzelince performans düşmüş gibi görünecek mi?

Büyük ihtimalle evet ve bunu baştan söylüyoruz. Çift sayım giderildiğinde raporlanan ciro düşüyor. Düşen performans değil, ölçümün doğruluğu. Bu yüzden düzeltme öncesi ve sonrası rakamların doğrudan karşılaştırılmaması, kıyasların düzeltme sonrası dönem üzerinden kurulması gerekiyor.

KVKK açısından ölçüm kurulumunda nelere dikkat ediyorsunuz?

Üç başlıkta çalışıyoruz. Birincisi veri minimizasyonu: ölçüm için gerekmeyen kişisel verinin hiç toplanmaması, e-posta ve telefon gibi alanların analitiğe düz metin olarak gönderilmemesi. İkincisi onay: çerez ve izleme teknolojilerinin, kullanıcı onayı öncesinde veri göndermemesi ve onay durumunun sinyale yansıması. Üçüncüsü şeffaflık: aydınlatma metninde hangi verinin hangi amaçla işlendiğinin yazılı olması. Hukuki metinlerin hazırlanması bizim işimiz değil, ancak teknik kurulumun bu metinlerle uyumlu olmasını sağlamak kapsamımızda.

Panelde gördüğüm ciro ile muhasebedeki rakam neden tutmuyor?

Genellikle beş sebepten biri: dönüşümün çift sayılması, değere KDV ve kargonun dahil edilmesi, iptal ve iadelerin geri beslenmemiş olması, ölçüm kesintisi yüzünden bazı siparişlerin hiç kaydedilmemiş olması ya da farklı para birimlerinin tek birimmiş gibi toplanması. Denetimde bu beşini sırayla eliyoruz. Fark tamamen sıfırlanmıyor, çünkü analitik tarayıcı tarafında çalışıyor ve bir miktar kayıp kaçınılmaz; ama farkın hangi sebepten ve hangi büyüklükte olduğu bilinebilir hale geliyor.

Mevcut ekibimiz kurulumu yaptı, denetim yaptırmaya değer mi?

Denetim, kurulumu yeniden yapmaktan belirgin biçimde ucuz ve çoğu durumda en yüksek getirili ilk adım. Çıktı, hangi olayın nasıl tetiklendiğini, hangi rakamın hangi sebeple şiştiğini ve düzeltme sırasını gösteren yazılı bir belge oluyor. Bu belgeyi kendi ekibinizle uygulamak da mümkün; kapsamı denetimle sınırlı tutan çalışmalar yapıyoruz.

Birden fazla site ve uygulamamız var, tek yerden ölçebilir miyiz?

Ölçülebilir, ancak yapı kararını baştan vermek gerekiyor. Aynı markanın farklı alan adları ve uygulaması tek bir mülkte toplandığında bütünsel kullanıcı yolculuğu görünür oluyor; buna karşılık her bir varlığın kendi raporunu ayrıştırmak zorlaşıyor ve kardinalite sınırlarına daha hızlı yaklaşılıyor. Ayrı mülklerde ölçüp veri ambarında birleştirmek çoğu durumda daha esnek bir çözüm sunuyor: hem her varlığın kendi raporu temiz kalıyor hem de birleşik tablo üretilebiliyor. Alan adları arası geçişte oturumun kopmaması için alan adlarının birbirine tanıtılması ve yönlendirme hariç tutma listesinin doğru doldurulması da şart; bu iki ayar atlandığında kendi sitenizden gelen trafik yönlendiren kaynak olarak kaydediliyor ve kanal raporu tamamen bozuluyor.

Ölçüm kurulumundan sonra bakım gerekiyor mu?

Evet, ama kapsamı sınırlı. Kurulumun kendisi tek seferlik bir iş; bakım tarafında yapılan şey, sitede ve platformlarda değişen şeylerin ölçümü bozup bozmadığını izlemek. Pratikte üç durum düzenli müdahale gerektiriyor: sitede yapılan yayınlar, reklam platformlarının arayüz ve arayüz dışı değişiklikleri, bir de yeni bir kanal ya da yeni bir ürün grubunun devreye alınması. Bunların dışında kurulum kendi başına çalışmaya devam ediyor. Otomatik uyarılar da tam bu yüzden var: bakımı takvime değil, gerçekten bir şey değiştiğinde tetiklenen sinyale bağlıyoruz.

Ücretsiz performans analizi talep edin