— Selamlar herkese, Zeyot Walks'a hoş geldiniz. Bugün Ferit'le beraber analitik stüdyolarını konuşacağız; beraber analitiks ekibindeyiz. Kendisi Web Analytics Specialist olarak çalışıyor, ben de Web Analytics Manager olarak çalışıyorum. Sürekli yeni müşterilerde özellikle gördüğümüz hatalar: property'lerde yaptığımız optimizasyonlar ya da çok yaygın kronik sorunlar hakkında doğaçlama bir sohbet yapmayı planlıyoruz. Öncelikle hoş geldin Ferit, nasılsın, iyi misin?
— Hoş buldum Zafer, iyiyim. Sen nasılsın?
— Ben de iyiyim, teşekkür ederim. İstersen direkt şeyle başlayabiliriz: Bize bir property geldiği zaman, bir Google Analytics 4; zaten artık Universal Analytics olmadığı için tamamen Google Analytics 4 dünyası içerisindeyiz. Burada neler yapıyoruz? Bize geliyor marka, genelde de analitiks hizmeti ihtiyacı olan markalar; gerçekten yüksek trafikli, büyük brand'ler oluyor. Burada çok fazla şeyle karşılaşıyoruz sektör olarak ama genelde mesela nelerle karşılaşıyoruz? Burada en çok neleri sen ilk başta, roadmap'in en başında tespit ediyorsun? Bu şekilde konumuza giriş yapabiliriz.
— Tabii. Şimdi biz ilk başta... Marka bize ilk geldiğinde, ilk ulaştığında zaten yüksek trafikli markalar oluyor. Hani daha işte SEO çalışmalarını yapmamış ya da PPC çalışmalarını yapmamış markalar değil de, bu çalışmaları yapıp daha sonrasında analitiks hizmeti isteyen markalar oluyor. Ve bunlar yüksek trafikli oluyor, senin de söylediğin gibi. Şimdi bunlarda biz audit çalışması yaparken aslında bizim bir audit sıralamamız var ve bunlara yönelik kontroller sağlıyoruz. Şimdi burada en çok karşılaştığımız sorunların başında, aslında benim ilk gördüğüm sorunlardan en büyüğü, bütün sayfalarına marka sahipleri bütün sayfalarına GTM ve Google Analytics kodları eklememiş oluyorlar.
En çok burada hatayla karşılaşıyoruz. Yani önce aslında baktığımız yer bizim direkt websites.
— Yani önce temel kuruluma bakıyoruz. Yani ileri seviyeye geçmeden önce bir kere sizin analitiksiniz doğru çalışıyor mu? Çünkü genelde hep neyle karşılaşıyoruz? Marka bize geliyor, tamam başlıyoruz ama daha başlayalım da temel kurulum senelerdir yanlış çalışıyor. Yani bunu çok görüyoruz. Ya en basitinden, session yanlış ölçülüyor. Yani inanç değil; e-commerce konsept moda geçmeden önce. Bu markaların çoğu bir dönem analitiks danışmanlığı da alıyor olabilirler. Ancak çok basit şeyler...
— Gözden kaçabiliyor. Evet, yani biz bunu hani analitiks danışmanlığı almış şirketlerde de gördük daha öncesinde. Hiç almamış şirketlerde, hatta ben şöyle söyleyebilirim: Hiç almamış şirketlerde en azından sorunları çözmek çok daha basit olduğunu düşünüyorum ben Zafer en azından. Daha önceden analitiks danışmanlığı almış şirketlerde hem kafalar birazcık karışık oluyor hem de belli bir entegrasyon yapıldıysa bunu düzeltmek zor oluyor. Çünkü bir veri akışı var bir yere ve hani yeni gelmiş bir markaya senin verin şu tarihten itibaren hatalıydı. İşte bak burada şöyle bir sorun yaşamışsın, senin bu sayfanda aslında bu çalışmıyordu demek biraz zor olabiliyor. Dediğim gibi hani daha öncesinde bu hizmeti almış markaların problemleri daha büyük olabiliyor. En çok yaşadığımız sorunlardan bir tanesi aslında bu.
Bütün sayfalarda kodların ekli olmayıp, bütün sayfaları analiz edemiyor olması markanın gibi şey yapabilirim. Devamında yine en çok yaşadığımız sorunlardan bir tanesi, bütün sayfalarda olabiliyor kodlarımız ama page view'lar duplicate olabiliyor. Yani yazılımsal olarak bu benim...
— Orayı ekleyeyim, uzmanlık alanım.
— Evet, bir hep...
— Page view.
— Şansa benim karşıma çıkıyor genellikle. Zafer de hep bana bu konuda böyle şey yapıyor, takılıyor. Giriyorum, bir sayfayı debuglamaya çalışıyorum, bir sayfaya bakıyorum, inceliyorum sadece. Duplicate page view karşıma çıkıyor. Bu da aslında sen de detaylandırırsın konuyu. Direkt hani x2 session gibi düşünebiliriz, x2 user gibi düşünebiliriz. Hani bu çok değiştiriyor metrikleri, bounce rate'i değiştiriyor, her şeyi değiştiriyor aslında. Giriyorsun, hani duplicate page view karşıma çıkınca ben zaten böyle bir kalıyorum. Çünkü çok büyük sorunlar var o tarafta. Hani bütün sayfaları eklemedin kodları, bu bir sorun ama duplicate page view yaşıyorsun, bu çok daha büyük bir sorun. Bu da genellikle şundan kaynaklanıyor: Ya yazılımsal olarak yanlış kod eklenebiliyor ya da işte marka, ben şunu da gördüm, marka unutmuş, bir daha ekletiyor.
GTM'ini ya da JForm'u.
— Ya da paralel kurulum var. Yani GTEK ve GTM üzerinden kurulum var. Zaten page view dediğin şey en temel event Google Analytics 4'te. Burada bunun duplicate olması aslında alt parametrelerinin de duplicate olması demek. Yani o page view altında bir sürü event gidiyor. Session'dan tut da diğer her şeyin aslında x2 olarak sayılmaya başlaması gibi bir sıkıntı oluyor. Bu da dediğin gibi sil baştan yanlış bir temel kurulum var, entegrasyon. Sonra biz bunu ne yapıyoruz? Söylüyoruz. Diyoruz ki: "Bakın, yanlış ölçüyormuşsunuz. O zaman bizim verimiz ne?" diyorlar. Şeklinde oluyor. Yani biz de diyoruz ki: "Bilmiyoruz, düzeltmemiz lazım önce."
— Yani bunu düzeltmek bir aylık bir süreç. Sen de tahmin edersin. Şimdi ben bugün duplicate page view'ü kaldırdım. Senin session'un düştü ama sen iki gün sonra session'unu yükseltecek misin? Daha da mı düşecek? Senin aylık grafiğin ne gibi ilerliyor, bunu bilemiyoruz. Ve yeni gelen bir marka. Bu, bilmiyorum, sende de öyle ama bende de bir mahcubiyet oluşturuyor. Böyle sanki hani sorunu ben buluyorum, diyorum daha önceden bir hata okudum ama ben de bir mahcup oluyorum. Sanki ben yapmışım gibi. Çok büyük bir sorun olduğu için.
Çünkü adamlar bu sefer diyorlar ki: "Biz bu zamana kadar bıraktığımız veriler yanlış mı? Ben bu kadar reklam verdim, yanlış mı?" Diyorsun, yanlış yani yapacak bir şey yok.
— Orada şuna geleceğim ben: Hani bir mahcubiyet oluşturmuyor aslında bende. Niye oluşturmuyor? Bu hatayı ben yapmadım. Ha, olabilirdim de. Ancak şöyle bir durum var: Bu bize şunu gösteriyor. Buradan bizi dinleyenlere de bunu söyleyebiliriz. En temel bir hata bile, çok basit bir hata bile sizin yanlış ölçmenize sebep oluyor. Ve öyle büyük markalarda bunu yaşıyoruz ki, milyon dolarlık markalar. Yani cirosal anlamda. Ve içerideki tüm ekip böyle kalıyor. Ya biz hatırla, şunu yaşadık seninle: Yeni bir müşteri toplantısına gittik, farklı bir yerle çalışıyorlardı. Biz bunları gösterdik, şok oldu hepsi.
Yani.
— Türkiye'nin bildiği bir şey burası, kurum bu aslında yani.
— Evet, yani biz bunları gösterdik. Ya bakın, ve bu nasıl olmuştu? Bizden eğitim almışlardı sadece. Biz bir eğitim vermiştik. Ve biz bu hataları eğitim esnasında örneklerle gösterirken fark ettik. Yani bir audit falan da yoktu ortada bu arada. Ama ya ben burada şey için de söylemiyorum bu arada, hani bizim de hatalarımız var, gözden kaçırdığımız şeyler var, sonradan hemen düzelttiğimiz şeyler var. Fakat hani hata biraz temel olduğu zaman, hani iş karmaşıklaşıyor. Yani yoksa tabii ki bizim de "ya bunu nasıl gözden kaçırmışız" dediğimiz, düzelttiğimiz şeyler oluyor.
Ama bu çok temel bir hata olduğu için bir analitiks danışmanlığı alan markanın analitiksinde bulunmaması gerekiyor aslında. Konu biraz daha bu. Bizim şaşırma sebebimiz ya da bunu yerme sebebimiz aslında bu. Ya bunu bir kere hani audit'te biz tespit ediyoruz. Ve sadece bu da değil. Biz sadece page view açısından konuşuyoruz bir 3-5 dakikadır ama. Bir e-ticaret sitesi, örnek veriyorum, ciroyu ölçüyor, organik trafikten aldığı trafiğin ciroya dönüşünü, reklamdan aldığı, sosyal medyadan hepsini analitiks'te görüyor neticede. Gelir ölçüyor, satılan, görüntülenen ürünler. Fakat e-ticaretin çok yanlış çalıştığını görüyoruz. İnanç değil e-commerce kurulumundan bahsediyorum. Burada yine bazı basit ama direkt sonuca etki eden hatalar var. Mesela bunlar ne? Revenue bir kere yanlış sayılıyor.
Kargo sayılmıyor, indirim dahil olmuyor. Ya da vergi total revenue'nün içerisine dahil oluyor gibi sorunlar oluyor. Ve yine bir duplicate problemi transaction'da yaşanıyor aslında. Bunu sen de bir markamızda tespit etmişsin, etmiştin zaten. Şimdi bizim transaction ID olarak gönderdiğimiz bir sipariş numarası, aslında tüm siparişlerde unique bir numara olması lazım. Öyle değil mi? Random bir numara oluyor bu genelde. Bunun birden fazla kez oluşması aslında aynı siparişin çoklanması anlamına geliyor.
— Yani bunu iki kere görüyorsan aynı ID'den, burada senin yazılımsal olarak bir hatan var çok yüksek ihtimalle. Çünkü iki ID'nin aynı anda pushlanması imkansız. Yani kullanıcı iki tane üst üste alışveriş bile yapsa aynısından, iki ID'yi pushlamaması gerekiyor aynı zamanda. Ama ikisini aynı anda görüyorsan muhtemelen inanç konusunda hata var. Zaten bu, hani zaten konuşacağımız başlıkların içerisindeydi bu. Şey gibi oldu biraz bu. Hani sen JForm'u kurdun, doğru kurdun. İnanç.com'da purchase kurdun ama purchase'in de hatalı çalışabilir. Yani en temel yine bu şeylerden biri. Biz inanç.com kurduğumuzda da başka markalara direkt purchase aslında ilk başta kuruyoruz. Çünkü hani bunun bir çalışması lazım, sonra diğerlerini çalıştırırız gibi yaklaşıyoruz. Bu da en temel hatalardan bir tanesi aslında.
— Orada şunu ekleyeyim ben: Purchase'i ilk başta kuruyoruz dedin ya. Bizim e-ticaret kurma, yani inanç değil e-commerce entegrasyonunda hata yapmamak için ilerlediğimiz bir roadmap var. Genelde şöyle oluyor: Biz süreci fazlara bölüyoruz. Yani tüm event'leri dokümante edip gönderdiğimiz zaman, karşı tarafta yazılım ekibinin aksiyon alması, alsa bile o aksiyonun doğruluğu konusunda şüpheler oluyor.
— Evet, çok uzun bir süre.
— Keza, aynen, keza yaptık dedikleri yerde bizim kontrolümüzün de zorlaşması anlamına geliyor. O yüzden biz şöyle başlıyoruz: Önce bir purchase'i kurduruyoruz. En temel event. Purchase'i kurdurup gelir takibini vesaire simüle ediyoruz. Yani ya kullanıcı bize, marka bize bir test user veriyor, bir dummy user kullanıyoruz. Gidiyoruz, müşteri gibi sipariş veriyoruz sitele. Ya da hani bir şey olmuyorsa, bir test user'ı sağlayamıyorlarsa bize, ucuz bir üründen sipariş veriyoruz. Benim evime gelen ürünler oldu biliyorsun. İptal edilemeyip. Öyle siparişler verip aslında data layer'ın, GTM'in, analitiks'teki debug kısmının mükemmel olduğuna emin oluyoruz. Yani burada birden fazla senaryo olabilir. Kapıda ödeme doğru çalışması lazım, havale, normal kredi kartı. Oradaki parametrelerin doğru gelmesi lazım.
Yani parametre değerlerinin doğru type'lar olarak tanımlanması lazım. Yani string gönderilmemesi, number gönderilmesi ya da string'in hakikaten string gönderilmesi gerekiyor. Burada çok fazla alt parametre olduğu için fazlara bölmek her zaman bizim işimizi kolaylaştırırken sürecin de aslında doğru finalize olmasını sağlıyor. Daha sonra ne yapıyoruz? Tamam, purchase çalışıyor. Direkt gelir ölçmeye başlıyor zaten. Bu çok güzel bir veri. Direkt analitiks'te hangi üründen ne kadar sattım, ne kadar gelirim oldu. En temel, yani birçok raporu dolduran bir kurulum purchase. Sonrasında add payment info, add shipping, add to cart, even from cart. Bunların hepsini akabinde, aynen, dokümante edip yazılım ekibine iletiyoruz. Ve genelde yani hızlı bir şekilde kuruluyor. Ama yazılım ekibi daha önce böyle bir kurulum yapmadıysa, orada bizim biraz daha yönlendirme yapmamız, birkaç tane toplantıda göstermemiz, Google'ın kaynaklarından örnekler vermemiz.
Çünkü kolay bir kurulum değil gerçekten. Hani analitiks tarafında custom olarak yapılıyorsa bu, yani epey teste tabi olması gerekiyor. O yüzden faz faz ilerlemek burada en doğrusu diyebilirim.
— Ben de o şekilde söyleyebilirim. Bir de şimdi diğer bir soruna geçeceğim. Şimdi purchase'la konuşuyoruz. Şey de önemli aslında, hani sen satış yapıyorsun ve işte bir reklam veriyorsun, bundan satış elde ediyorsun. Ama senin bounce rate'lerin uçmuş gitmiş. Yüzde üçler, yüzde dörtler. Bu benim en çok gördüğüm sorunlardan bir tanesi yine. Genelde gelen markalar neyi conversion işaretleyip, neyi conversion işaretlememesi gerektiğini hiçbir fikre sahip olmuyorlar. Ve bunu neredeyse markaların yani yüzde altmışında, yüzde yetmişinde yaşıyoruz. Bilmiyorum sana soruyorum şimdi, session start'lar conversion sayılmış. Hani bütün kullanıcıların yaptığı event'ler conversion sayılmış. Atıyorum websinde kocaman bir şey var, girişinde banner var. Ve banner'ın görüntülenmesi conversion sayılmış.
Yani giren, websine giren bütün kullanıcılar bu işlemi yapıyor ve sen bunu conversion sayıyorsun. E doğal olarak ne oluyor? Ondan sonra senin bounce rate'lerin, çeşitli metriklerin etkilenmeye başlıyor bu durumdan. Bu da yine en çok gördüğümüz hatalardan bir tanesi diye söyledim. Buna ekleme yapmak istersen. Bu benim hep görüp görüp markalara yazdığım bir durum çünkü.
— Tabii tabii. Yani burada zaten conversion olarak tanımlama sınırlı. Bir tane de conversion var, en temel purchase. Zaten onu kaldıramıyoruz. Bir e-ticaret sitesinde aslında purchase kuruluysa conversion odur. Yani satış yapmak. Çok basit. Yeterli. Yani sonsuza kadar purchase'tir aslında baktığın zaman. Ama burada page view, session start vesaire olduğu zaman, raporlarda filtreleme yapmadan doğru sonucu bulamıyorsun. Yani bir bakıyorsun bir milyon dönüşüm var. Yani sağlıklı değil. Reklam tarafına da zarar veriyor bu. Çünkü reklamcıların bir hedeflemesi oluyor, bir öğrenmesi oluyor kampanyanın. Oradaki birden fazla conversion orayı da karıştırabiliyor. Hani bize soruyor reklam tarafındaki arkadaşlar mesela, hangi conversion'u ben baz almalıyım? Halbuki biz tanımlamamışız o conversion'ları.
Yani bir sürü conversion var. Yani bu ne olması lazım? Ya tabii ki şu olabilir. Yani e-ticaret dışına çıkarsak, bir sigortacılık markası düşünelim. 10 tane conversion olabilir, 15 tane conversion olabilir. Yani tamamlayıcı sağlık sigortası, kasko, cep telefonu sigortası, DASK vesaire. Ya bunların hepsi bir dönüşüm. Ayrı ayrı takip edilmesi gerekiyor bunların. Burada tamamız. Yani o orayı istediğiniz gibi doldurabilirsiniz. Ama senin dediğin gibi varsayılan event'leri conversion tanımlayan çok fazla marka görüyoruz. Ve bizim audit kapsamında direkt disable yaptığımız ayarlar onlar oluyor.
— Bunun dışında yine benim eklemek istediğim bir konu var burada. Şimdi böyle konuşuyoruz, konuşuyoruz, aklıma geliyor. Şeylere bakıyoruz, domain'lere bakıyoruz. Hangi domain'lerden websine veri akıyor? Yani websine değil, JForm'a veri akıyor. Bu da yine en çok gördüğüm sorunlardan bir tanesi. Büyük markalar genellikle test siteleri kullanıyor Zafer. Ve bunları kullanırken şimdi şöyle bir mantıkla yaklaşıyorlar. Biz buraya JForm kurduk ana sitemize. Bunu testte de kuralım. Testte yaptığımız işlemleri işte event kuracaksak, yani data layer push yapacaksak, bir şey yapacaksak, değiştirme yapacaksak önce burada yapalım.
Daha sonra bunu canlıya alalım şeklinde yaklaşıyorlar. Aslında çok doğru bir yaklaşım. Ama burada bizim aslında önerdiğimiz şey JForm'ları ayırmak gibi. Çünkü developer burada giriyor, test sitesinde yaptığı bütün her şeyi organize ediyor. Sonra test sitesinde bunları denemeye başlıyor. Sürekli deniyor, sürekli deniyor, sürekli deniyor. Ve developer çünkü gün içerisinde buna belki binlerce defa giriyor bu website. Kapatıyor, bir daha giriyor. Kapatıyor, bir daha giriyor. Bir debug'lıyor bir şeyi, bir daha giriyor. Daha sonra ne oluyor? Senin JForm'a, aynı JForm'u bağladıysan buraya, binlerce session akmış oluyor. Binlerce event akmış oluyor. Aynı şekilde çeşitli subdomain'lerden, çeşitli yerlerden, hep domain'lerden event gelmiş oluyor. Kullanıcı, user gelmiş oluyor.
Ondan sonra raporlarda, bunu custom raporlarda bir ayırıyorsun. İşte senin aylık atıyorum 5 milyon session'ın var. İşte 1 milyon session da şeyden gelmiş. Testten gelmiş. Test sitesinden gelmiş. Bu sefer marka yine bir duruyor. Çünkü 1 milyon session direkt silinecek aslında. Tamamen developer girmiş. Hiçbir onun hedeflediği bir kullanıcı değil. Ve burayı silmek zorunda kalıyoruz. Aslında bu da temel sorunlardan bir tanesi görmüş olduğumuz.
— Yani datayı kirletiyor ve büyük account'larda, yani büyük websitelerinde bunu daha fazla görüyoruz. Zaten senin ekibinde 5 kişi varsa problem değil. Hani data makul seviyede kirleniyor. Ama çok büyük şirketlerin o kadar fazla test verisi oluyor ki. Yani birçok websitesinin o kadar trafiği yok. Yani sadece korkunç bir developer trafiği var. Ve dediğin gibi bunlar sürekli session start yapıyor. Yani bu da ne oluyor? Test sitesinin verisini normal main property'ye bağlıyor. Biz orada ne yapıyoruz? Ya bir host name filtresi kullanıyoruz, ya IP tarafında bir engelleme yapıyoruz. Yani eskiden Universal Analytics'te de yaptığımız gibi, eskiden daha kolaydı. Şu an remote çalışma yaygın olduğu için hani IP de çok etkili olmuyor. O yüzden genelde host name bazlı bir kırılım yapmak daha çok hayat kurtarıyor gibi.
Ama kesinlikle dediğin doğru. Yani audit tarafında doğru veri, ya ben gerçekten doğruyu ölçüyor muyum dediğimizde, bunun da özellikle büyük trafikli, çok fazla çalışan sayısı olan markaların property'lerinde bunu optimize etmemiz gerekiyor. Diyerekten consent mode tarafına geçmek istiyorum. Çünkü consent konuşmada.
— Burayı devam ettiremeyiz.
— Aynen, mümkün değil. O yüzden consent mode tarafında da özellikle bu sene, geçen sene epey gündemdi. Ama Avrupa Birliği'nde ya da Avrupa ekonomik alanında 5-6 senedir veri gündem aslında. Bu arada hani consent tarafından, hani neyden bahsettiğimizi bilmeyenler olabilir dinleyiciler içerisinde. Kısaca şöyle anlatayım ben. Herhangi bir websitesine girdiğimizde hepimizin gördüğü bir banner vardır. Kabul et, reddet. Biz genelde reddedi göremeyiz nedense Türkiye'deki sitelerde. Asıl olay o. Hani sizin verinizi, verinize saygı duyarak bir ölçümleme yapılması. Yani siz ona reddet dediğinizde orada o site için söz hakkı bitiyor. Remarketing yapamaz size. Bir ölçümleme yapamaz. Yapar ama nasıl yapar? Modelleme vesaire. Burada da aslında olay detaylaşıyor. Hani sadece konu o değil. O kadar basit değil.
Hani kabul et, reddet. Kabul edersek sıkıntı yok, reddedersek sıkıntı var gibi bir durumdan ziyade, marketing'in devam etmesi için, ölçümlemenin devam etmesi için orada Google consent mode kurulumunun doğru yapılması lazım. Burada da Google'ın partneri olduğu cookie management platformlar var. Ya da Türkiye'de bunu sağlayan cookie çerez yönetim şirketleri var. CMP dediğimiz. Burada bir kere onunla, yani kendi başınıza da bir consent kurulumu yapabilirsiniz. Hani illa onlara gerek yok. Ama bir panel olması, daha profesyonel bir yönetim olması, kurulum tarafında belli bir standardın olması işleri kolaylaştırıyor.
— Analizi de arttıracaktır. Yani burada sana reddeden kullanıcıları veriyor, kabul eden kullanıcıları veriyor. Bunların hangi cihazlardan yaptığını bunu veriyor. Hangi ülkelerden yaptığını. Çünkü reddeden kullanıcıları biz genellikle çok göremiyoruz. Belli bir kaybımız oluyor burada. Hani cookie management platformlarla çalışmak, hatalı bir kurulumun olmasını da engelliyor aslında Zafer. Öyle söyleyebilirim. Hani herhangi bir analitik hizmeti almadın ve sen consent mode kurmak istiyorsun. Cookie management platformlar burada senin hatalı bir kurulum yapmanı da engelliyor. Ama diyerek bir virgül atayım. Herhangi bir cookie management platformla çalışıyor olmak hata yapmayı engellemiyor. Bunu Zafer de çok iyi biliyor aslında.
Burada hani cookie management platformların daha önceden görmemiş olduğu hatalar da olabiliyor. Ya da senin kişisel olarak yaptığın hatalar da olabiliyor. Bir kurulumu yanlış yaptın, belli parametreleri yanlış seçtin. GTM üzerinden kurarken burada hatalar yaşadın. Ya da bulunması çok zor hatalar oluyor. Yine burada bir markamıza örnek vereceğim. Zafer'le biz yaklaşık bir iki hafta kadar uğraşmıştık bu sorunu bulabilmek için. Hatırlar mısın Zafer? Direct patlaması yaşadığımız bir marka vardı consent mode kurulumu sonrası. Hani markanın bir trafiği var. Bu trafik aslında hani direct'te de olsa, organikte de olsa, bakıyoruz ki hani aynı trafik. Yani geçtiğimiz ayda ya da ondan önceki ayda ya da ondan önceki ayda aynı. Ama sürekli direct'te akıyor trafik. Hani kurulum buradan consent mode'dan kaynaklandığını daha sonrasında bulmuştuk.
Yanlış hatırlamıyorum herhalde Zafer. Sayfa yeniliyordu ve sayfa yenildikten sonra user'ı direkt direct'te gönderiyordu. Bu sefer direct'teki user'lar patlıyordu.
— Evet, orada sürekli kullanıcının ID'si değişmesi gibi problem vardı. Tespit edilmesi de biraz zor bir hataydı aslında. Biz de dediğin gibi hani birçok şeye baktık ama ona bakmak, yani onu takip etmek aslında biraz daha zordu. Ve dediğin gibi cookie management platformların, ya burada Türkiye'dekilerin birçoğuyla çalışıyoruz ama hani hata yapmamanız anlamına gelmiyor. Ne yazık ki cookie management kullanıp daha da bariz hatalar yapan markalar çok fazla. Destek konusunda da bazen sıkıntılar yaşanabiliyor. Burada bir analytics danışmanınızın olması ya da en azından bunu debug yapabilecek içeride birilerinin olması, onu takip etmesi. Çünkü sürekli de güncellenen bir alan. Yani burada consent mode vardı. Consent mode v2 geldi. Yeni parametreler eklendi.
Bunlar sizde aktif oluyor mu vesaire gibisinden. Çünkü bunun hukuksal bir boyutu var.
— Yani yanlış kurulum yaptığında aslında başını, markanın başını ağrıtabilecek süreçler bunlar.
— Evet, evet. Yani burada ya hata yaptım, yanlış ölçmüşüm gibi bir durumdan ziyade, bir hukuksal tarafı da olan bir alan. Tabii o taraf bizim uzmanlık alanımız değil. Biz daha çok işin teknik parametreler kısmındayız. Kurulumun yapılması, reddeden kullanıcıların da rızasına saygı göstererek bu verilerin analytics'te modellenmesi, makine öğrenimiyle, bunun buradaki koşulları sağlayan özellikle property'lerde önemli. Yani örnek veriyorum, 20 kişi geliyor websiteme. Onu reddediyor, onu kabul ediyor. Basic bir consent mode kurulumu varsa ki bu da olabilir. Ama bir kurulum var aslında. Bir kullanıcı rızasına saygı gösteriliyor. Ne olacak? Yarı yarıya belki daha fazla verimiz kaybolacak.
Ama arka tarafta bir modelleme çalışıyorsa Google Analytics 4'te, burada %70'ini %80'ini kurtarabileceğiz verinin. Oradaki iki tane veri kaybolacak. Yani %atıyorum %20'si buhar olacak. Bu da aslında bize çok iyi bir örneklem verecek şey açısından. Ölçümleme açısından. O yüzden advanced consent mode'u doğru bir şekilde oturtmak önemli.
— Yani aslında burada demek istediğimiz, hani hem veri kaybı yaşamamak için consent mode'u kontrol etmek çok önemli. Hem de ilerideki dava süreçleriyle, çeşitli süreçlerle başınızın ağrımaması için aslında bunu iyi kontrol etmek önemli bir nokta gibi gözüküyor.
— Ya aynen. Türkiye'deki büyük e-ticaret siteleri. Yani neyi bekliyorsunuz bilmiyorum. Bu Avrupa'da yaygın. Avrupa ekonomik alanında. O yüzden onların da aslında kullanıcı verilerine saygı göstermeye başlaması, bizim açımızdan. Neticede hepimiz bir tüketiciyiz. Yani ben spor ayakkabı almak için girdiğim zaman X sitesine her yer spor ayakkabı olmasını istemiyorum. Yani bana remarketing yapmanı istemiyorum belki. Belki öylesine baktım.
— Türkiye'de çok saygı duyulan bir konu değil ama şu an.
— Evet, evet. Yani o yüzden burada bence biraz özellikle büyük siteler tarafında bir şapkanın önlerine koyulması gerekiyor.
— Cezaların ciddileşmesi gerekiyor Zafer.
— Evet, aynen. Belki cezaların o tarafta caydırıcı olması lazım. Avrupa'da işler biraz daha şu an şey. Yurt dışı tarafındaki markalarımıza hemen hemen hepsi en önemli gündemleri bu. Analytics'i biz gün bir kurduğumuz zaman bu doğru çalışıyor mu diye bakıyorlar. Çünkü oradaki işler farklı yürüyor. Yani biz önce Analytics ile birlikte consent'in de doğru çalıştığına emin oluyoruz. Onun haricinde consent tarafında.
— Sorunumuz yoksa diye devam ediyoruz.
— Şeye yani hatalı Inance e-commerce tarafına baktık. Ben konularımıza bakıyorum. Burada Adil ve Kamil. Efendim?
— Ben direkt sana soru sorabilirim aslında. Bu da bir hata bu arada. Şimdi Zafer, benim bir GFor hesabım var. Ben bir markayım. Ve 360 mı kullanmalıyım? BigQuery mi kullanmalıyım? Ve bunun bana indikatörü nedir? Yani ben verilerimi Adil'da görüyorum. Benim raporlarım patlıyor. Benim raporlarım kıpkırmızı ünlemli. Ben 360 ne zaman kullanmalıyım? Ya da BigQuery'e ne zaman geçmeliyim?
— Bence burada BigQuery tarafına geçmek daha mantıklı. Ancak çok yüksek trafikli websitelerinde BigQuery biraz maliyetli olabiliyor. Çünkü yanılmıyorsam aylık, günlük de olabilir. Orada çok şey değil ama aylıktı galiba. Belli bir export sınırı var ücretsizde. Onu aşmak için 360'ınızın olması gerekiyor. Değişmediyse tabii en son öyle hatırlıyorum. Ama küçük websitelerinde BigQuery, yani küçük web sitesi dediğim görece düşük trafikli web sitesi diyeyim. Hani BigQuery az maliyetli bir şey sanılanın aksine. Belki de hiçbir maliyeti yok. Çünkü size bir kredi de tanımlıyor Google Cloud. O kredi doğrultusunda BigQuery'ye bağladığınız zaman veriler oraya akıyor. Bu size ne elde ediyor? Ettiriyor en basit olarak. Verileriniz üzerinde daha fazla söz hakkına sahip oluyorsunuz.
Bir veriyi sorgulamak için Google Analytics raporunun size verdiğinden ziyade BigQuery'de sorgu yaparak daha sampling'siz, yani örnekleme olmayan verileri görebiliyorsunuz. Ek olarak BigQuery çok fazla tool'u entegre edebilen bir kısım olduğu için, yani siz Excel'le bir veriyi aktarıp normal Google Analytics 4 verinizle match edebiliyorsunuz. Yani orada blend bir rapor oluşturabiliyorsunuz. Yani atıyorum CRM'den bir export alındı. Google Analytics 4'de matchleyip BigQuery üzerinde sorgulama yapabiliyorsunuz. BigQuery'den görselleştirme tarafına Looker vesaire veri gönderebiliyorsunuz aynı şekilde. O yüzden ben hani 360 çok pahalı bir şey. Özellikle çok büyük firmalar için bile çok pahalı.
O yüzden 360 çok yaygın değil. Ama BigQuery bence bahsetmiş olduğun ağdır ya da sampling sorunlarını bir nebze olsun çözecek. Aynen öyle.
— Buradaki soru şu, sorma sebebimiz de şu, hani bunu konuşma sebebimiz de şu. Hesaplarda ağdır diye bir sorun yaşanıyor. Ya da kardinaliteye takılma sorunları oluyor. Bu da sampling olarak gözüküyor. Yani threshold değil, orasıyla karıştırmayalım. Sampling olarak sorunlar olabiliyor. Ve hatırlar mısın bilmiyorum yine bir markamızda raporlara bir şeyler ekleyemeyecek durumdaydık. Hani herhangi bir parametre ekliyorsun, herhangi bir metrik ekliyorsun ve direkt rapor sampling'e düşüyor. İşte diyor senin %15'ini gösterebiliyorum. %10'unu gösterebiliyorum senin. Bu tip sorunlar yaşamamak için aslında 360 ve BigQuery tarafına başvurulabilir.
— Aynen öyle. Son olarak ben şeyden bahsedelim istiyorum. Yani yapay zeka olmadan bir sohbet olmaz bugünlerde. Son yıllarda. Yapay zeka tarafını Web Analytics tarafıyla nasıl kullanıyoruz biz? Yani bir Web Analytics danışmanı olarak burada neler yapıyoruz şeklinde. Ben şöyle bahsedeyim sana topu atmadan. Özellikle Google Tag Manager üzerindeki sorunları çözmek için çok fazla başvurabiliyoruz. Yani çok iyi kod yazıyor neticede AI. GTM tarafında da bizim çoğu zaman custom bir JavaScript'e ihtiyacımız oluyor. Eskiden ne yapıyorduk? Bir kodu bir şekilde yazıp, yani neticede biz bir developer değiliz. Nihayetinde her gün developerlar gibi kod yazmıyoruz. Bir JavaScript'i bir şekilde yazıp bulup ya da bir yerden hata verdiği zaman stack overflow ya da internette bunun neden yanlış çalıştığı, bu bir variable olabilir.
Çok kullandığımız ya da bir custom HTML olabilir. Neden yanlış çalıştığın, kodun neresinde hata yaptığımız JavaScript'in araştırmakla geçiyor. Ama şu an direkt derdimizi anlatarak.
— Yazdırabiliyorsun.
— Evet, bize kodu yazıp veriyor. Ve genelde ilk denemede ya da 3-4 deneme sonrasında. Burada hani bizim biraz ona verdiğimiz promptla alakalı. Yani orada ne kadar iyi bir yönlendirme sağlayabilirsek bize o kadar iyi dönüşü oluyor. Çok fazla zaman tasarrufu. Yani ben bir gün, iki gün bir kod üzerinde uğraştığım, farklı arkadaşlarıma danıştığım, yani ileri seviye developerların başını ağrıttığım, hani şu neden çalışmıyor gibi. Şu an direkt kodumu veriyorum. Diyorum ki ben bunu bu yüzden kullanmak istiyordum. Fakat şu hatayı alıyorum. Ya da bana bir değer döndürmüyor. Direkt olarak doğrusunu veriyor. Ve çoğu zaman dediğim gibi çalıştırıyorum.
— Ben de burada şunu söyleyebilirim aslında. Hiç sen de bunu yaşamışsın illa. Genellikle bir markayla çalışıyorsun ve third party'lerden gelen kodlar oluyor. İşte bunu hani Tag Manager üzerinden çalıştıralım. Biz buradan ölçümleme yapacağız şeklinde. Ya bunların çalışmadığı senaryolar olabiliyor. Bunların direkt Tag Manager'a pushlayamadım. Benim çok öyle yaşadım. Direkt Tag Manager'ın hata verdiği, işte burası yanlış yazılmış denen kısımlar oluyor. O da Tag Manager'ın hatalarını da biliyorsun. Hani diyor 12. satırda yanlışlık var. Ama böyle detaylandırmıyor bu konuyu. Onları da ben, onlar için de çok kullanıyorum. Direkt atıyorum. Diyorum ki hani burada bir hata olduğunu söylüyor tool. Sen ne diyorsun? Direkt düzeltip, bunu bunun içine tanımlamamışsın.
Bunu böyle yapmamışsın. Aslında bunu böyle yapsan daha doğru olur deyip çözdüğüm konular da oldu benim. Hani hiç şimdi E'ye danışmazsan bu saygı duyacaksın. Third party'ye bir daha soracaksın. Bunu tekrar yazabilir misiniz? O markaya dönecek. Ben bunu tekrar yazdım. Bunu tekrar pushlayabilir misiniz? Bakacaksın bir daha hata var falan. Hani çok uzun bir süreç. Onun yerine düzeltip hemen devam edebiliyorsun aslında. AI bu işe de yarıyor.
— Evet, yani orada benim baştan sona çok karmaşık bir teski. AI sayesinde çözdüğüm bir case var yani. Hani ben direkt bu bahsettiğim bir third party kurulumunu. Verileri çekerek. Ya tabii bunun için hani sıfır GTM bilginizin olması da iyi değil neticede. Hani AI anlatmaya çalıştığını direkt mantık yürütebilmek. Ha böyle diyorsa buradan yapmam lazım. Ya da hani onun hatalı yönlendirmesini sizin düzeltmeniz lazım. Çünkü ne kadar mükemmel de olsalar halen yani çoğu zaman halüsinasyon vesaire birçok hatayla AI üzerinde de karşılaşıyoruz. Tamamen ona süreci teslim etmekten değil kasıt. Yani burada ona bir asistan olarak kullanıp kendi bilginizle harmanlayıp aslında teski tamamlayabilmek doğru şekilde. Çünkü hani sıfırdan finale kadar AI o kurulumu sizin için yapmayacak ama geçmişte olmayan çok güçlü bir asistan.
Sizden her şeyi daha iyi biliyor. Sadece onu kullanmak önemli. Diyerekten istersen varsa eklemek istediğin bir şey.
— Aslında genel olarak bütün sorunları, yani temel olarak kullanıcıların karşısına çıkabilecek bütün sorunları konuştuk. Bütün hepsini diyemem bunun içerisinde. Ama temel olarak çoğu sorunu konuştuk gibi. Hani bunlar kontrol edilse aslında sorunların çok büyük bir kısmı hallolacak sorunları konuştuk.
— Aynen öyle. Zaten ZO olarak bu tip içeriklerde aktifiz. Sadece ZO Talks değil, Digital Zone ya da Blog tarafındaki içeriklere de göz atabilirsiniz. Analytics tarafında da orada ürettiğimiz içerikler var. ZO komünitesini bu doğrultuda takip etmenizi öneririm. Diyerek kapatabiliriz. Dinleyenlere çok teşekkür ediyoruz. Bize vakit ayırdıkları için. Yeni bir ZO Talks'ta görüşmek üzere. Hoşçakalın.
— Görüşmek üzere. Hoşçakalın.
— Hey everyone, welcome to Zeyot Walks. Today, Ferit and I are discussing analytics studios. We’re both on the analytics team. He’s a Web Analytics Specialist. I’m a Web Analytics Manager. We’ll chat about common mistakes we see with new clients. We’ll cover property optimizations and chronic issues. Welcome, Ferit. How are you doing?
— Thanks, Zafer. I’m good. How about you?
— I’m great, thanks. Let’s dive in. When we get a new Google Analytics 4 property, what’s our process? Universal Analytics is gone. We’re living in a Google Analytics 4 world now. Brands come to us for analytics services. They’re usually high-traffic, major brands. We see a lot of issues in this industry. What’s at the top of your roadmap? What do you spot first? That’s how we can kick things off.
— Sure. When brands first reach out, they usually have high traffic. They aren't beginners. They’ve already done SEO or PPC. They come to us specifically for Analytics services. As you said, they have high traffic. We follow a strict audit checklist. The biggest issue I see right away? They haven't added GTM and Google Analytics tags to every page. That’s where we find the most errors. We always start with the website.
— We check the foundation first. Before going advanced, is your Analytics even working? We often start a project only to find the base setup has been broken for years. We see this constantly. Sessions are tracked incorrectly. Even before moving to e-commerce or advanced concepts, these brands often had prior consultants. Yet, simple things get missed.
— Exactly. We’ve seen this even with companies that had previous Analytics consulting. Honestly, Zafer. It’s often easier to fix these issues for companies that never had consulting before. Companies with prior consulting often feel confused. Existing integrations are tough to fix. Data is already flowing somewhere. Telling a new client their data was wrong is hard. Pointing out specific tracking errors is tricky. Brands that used other services often have bigger issues. This is one of the biggest problems we face. Sometimes codes aren't on every page. The brand can't analyze their full site. Another common issue is duplicate page views.
Technically speaking, that’s my...
— Let me add that. It’s my area of expertise.
— Yeah, we always...
— Page view speaking.
— It usually happens to me by chance. Zafer always teases me about this. I’ll be debugging a page. I’m just looking at it. Then, a duplicate page view pops up. You can elaborate on this. Think of it as 2x sessions or 2x users. It totally skews your metrics. It ruins your bounce rate. It changes everything. When I see a duplicate page view, I’m stuck. It’s a massive problem. Missing codes is one thing. But duplicate page views? That’s a huge issue. It’s usually bad code implementation. Or sometimes, brands just forget and add it twice.
They double up on GTM or JForm'u.
— Or they have parallel setups. Like GTAG and GTM running together. Page view is the core event in Google Analytics 4. If that duplicates, all sub-parameters duplicate too. You’re firing a ton of events under one page view. Everything, including sessions, starts double-counting. It’s a fundamental setup error. A bad integration. We have to tell them. We say, "Look, your tracking is wrong." They ask, "So, what is our real data?" We tell them, "We don't know. We have to fix it first."
— Fixing this takes a month. You know how it goes. I remove duplicate page views today. Your sessions drop. Will they bounce back in two days? Or drop further? We can't predict your monthly trends yet. It’s a new brand. I feel embarrassed, even though I didn't cause it. I’m the one pointing out the old mistakes. It feels like it’s my fault because the issue is so huge. They ask, "Was all our past data wrong? Was all that ad spend wasted?" You have to say, "Yes, it was wrong. Nothing we can do."
— I don't feel embarrassed anymore. I didn't make the mistake. But here is the lesson for our listeners. Even the smallest, most basic error ruins your entire measurement. We see this with massive brands. I mean, million-dollar companies. Revenue-wise. The whole team is just stunned. Remember that client meeting? They were working with someone else. We showed them the data. They were shocked. Exactly.
— This is a household name in Turkey. A major institution.
— Yes, we showed them. And how did it happen? They just took our training. We were running a session. We spotted these errors while using examples. There wasn't even an audit involved. I’m not saying we’re perfect. We make mistakes too. We miss things and fix them quickly. But when the error is fundamental, things get complicated. Sure, we have "how did we miss that" moments. We fix those too. But this was a basic error. A brand paying for Analytics consulting shouldn't have this. That’s the real issue. That’s why we’re surprised or critical. We usually catch this during an audit.
It’s not just that. We’ve been talking about page views for a while. E-commerce sites track revenue. They track organic, paid, and social traffic. They see it all in Google Analytics. They track sales and product views. But e-commerce setups are often broken. I’m not talking about Inanç, but general e-commerce setups. There are simple, high-impact errors. For instance, revenue is often miscounted. Shipping isn't counted. Discounts are missed. Taxes get lumped into total revenue. Plus, there’s the transaction duplication issue. You actually caught this on one of our accounts.
The transaction ID must be unique for every order. Right? It’s usually a random number. If it appears more than once, the order is being duplicated.
— If you see the same ID twice, you likely have a coding error. It’s impossible to push two identical IDs at once. Even if a user buys the same thing twice, the IDs shouldn't clash. If you see both, there’s a setup error. This was on our agenda anyway. It’s like this. You set up JForm'u correctly. You set up purchase on Inanç.com, but it can still fire incorrectly. It’s a fundamental issue. When we built inanç.com, we set up purchase tracking first. We thought, "Get this working, then handle the rest." That’s actually a huge mistake.
— Let me add this. You mentioned setting up purchase first. We follow a specific roadmap for e-commerce integrations to avoid errors. We usually break the process into phases. When you document and send all events at once, the dev team struggles to act. Even if they do, you can't be sure it's accurate.
— Yeah, it takes forever.
— Exactly. It also makes it harder for us to verify their work. So, we start by setting up purchase. It’s the most critical event. We track revenue and simulate the flow. The brand gives us a test user or we use a dummy account. We place orders just like a real customer. If they can't provide a test user, we buy a cheap item. You know I’ve had products show up at my house that I couldn't cancel. We place test orders. We ensure the data layer, GTM, and Analytics debug mode are perfect. There are many scenarios here. Cash on delivery, wire transfers, and credit cards must work. All parameters must fire correctly.
Parameter values need the right data types. Don't send strings if you need numbers. Ensure strings are actually strings. There are many sub-parameters. Breaking this into phases makes our job easier. It ensures the process is finalized correctly. What’s next? Purchase is working. It starts tracking revenue immediately. This is great data. You see exactly which products sold and your total revenue in Analytics. Purchase is the foundation for most reports. Then we handle add payment info, add shipping, add to cart, and remove from cart. We document these and send them to the dev team. They usually set it up quickly. If they’re new to this, we guide them. We hold meetings and share Google resources.
It’s not an easy setup. If you’re doing custom work in Analytics, it needs heavy testing. That’s why I recommend moving in phases.
— I agree. Let’s move to the next question. We’re talking about purchase tracking. It’s also important to track sales from ads. But what if your bounce rates are through the roof? Three or four percent. This is a common issue I see. Brands have no clue what to mark as a conversion. I see this with 60 or 70 percent of brands. I’ve seen session starts marked as conversions. Every user event is counted as a conversion. Imagine a huge banner on the homepage. They mark the banner view as a conversion.
Every user triggers that event. You’re counting it as a conversion. Naturally, your bounce rate and other metrics get skewed. This is one of the biggest mistakes we see. Feel free to add to this. I’m constantly flagging this to brands.
— Exactly. You should limit your conversion definitions. The most basic one is purchase. You can't remove that. For e-commerce, a purchase is the only real conversion. It’s simple. That’s enough. Purchase is really all you need. If you track page views or session starts, you can't get clean data without filtering. You end up with a million conversions. It’s not healthy. It even hurts your ad performance. Advertisers have specific targets and campaign learning phases. Multiple conversions can confuse the algorithm. They often ask us which conversion to prioritize. Yet, we haven't even defined those conversions properly.
There are just too many conversions. What should happen? Outside of e-commerce, take insurance brands. They might have 10 or 15 different conversions. Think health insurance, auto, mobile, or earthquake policies. These are all distinct conversions. They must be tracked separately. We agree on that. You can fill that list however you like. But many brands mark default events as conversions. We disable those immediately during our audits.
— I have another point to add here. As we talk, it comes to mind. We check the domains. Which domains are sending data to JForm? This is one of the most common issues. Big brands usually use test sites, Zafer. They think, "We installed JForm on the main site. Let's add it to the test site too." They want to test data layer pushes and changes there first. Then they push those changes live. That is actually a solid approach. But we recommend separating the JForms. Developers often organize everything on the test site, which causes issues.
Then they start testing on the staging site. They test constantly. Over and over. Since they’re developers, they hit the site thousands of times a day. They close it and reopen it. They debug something and refresh again. What happens next? If you connected the same JForm, you get thousands of sessions. Thousands of events flood in. You get events from various subdomains and domains. You get tons of fake users. Then you segment this in custom reports. Say you have 5 million monthly sessions. 1 million of those came from testing. From the test site. The brand pauses. That 1 million sessions is basically trash.
It’s just developer traffic. These aren't your target users. We have to delete all of it. This is one of the core problems we see.
— It pollutes the data. We see this more in large accounts. If you have a team of five, it’s no big deal. The data pollution stays manageable. But huge companies generate massive amounts of test data. Many websites don't even have that much real traffic. It’s just insane developer volume. Like you said, they trigger session starts constantly. They link test site data to the main property. So, what do we do there? We use a hostname filter or block by IP. It was easier in Universal Analytics. Remote work makes IP filtering less effective now. Hostname-based filtering is a real lifesaver these days.
You’re spot on. For audits, we must ensure we’re measuring correctly. This is vital for high-traffic brands with many employees. We need to optimize those properties. With that, I want to move on to consent mode. It’s a hot topic.
— We can’t skip this.
— Exactly, it’s impossible. Consent mode was huge last year. It’s been a major issue in the EU for years. Some listeners might not know what we mean by consent. Let me explain. You see a banner on every site. Accept or reject. We rarely see "reject" on Turkish sites. That’s the real issue. It’s about measuring data while respecting user privacy. Once they hit reject, you lose access. No remarketing. No tracking. Well, maybe some modeling. It gets complicated. It’s not that simple. It’s not just about accept or reject. You need Google consent mode for tracking to work. Google has official partners for this.
There are also local CMP providers. You can build your own consent setup. You don't strictly need them. But a professional dashboard makes everything easier.
— It boosts your data quality. You see who accepted and who rejected. You see their devices and locations. Usually, rejected users are invisible. We lose a lot of data there. CMPs prevent bad setups, Zafer. If you're setting up consent mode alone, it’s risky. CMPs help you avoid mistakes. But let me add a caveat. Using a CMP doesn't guarantee zero errors. Zafer knows this all too well. Cookie management platforms can have hidden bugs. You might also make mistakes yourself. Maybe you misconfigured a setup. Or you chose the wrong parameters. You might have hit snags while setting it up in GTM.
Some errors are really hard to find. I’ll use one of our brands as an example. Zafer and I spent about two weeks tracking one down. Remember that, Zafer? We had a brand where direct traffic spiked after a consent mode setup. The brand had steady traffic. Whether it was direct or organic, the volume was the same. It matched the previous months perfectly. But the traffic kept flooding into direct. We eventually traced it back to the consent mode setup. I think I remember it right, Zafer. The page would refresh. After the refresh, it sent the user straight to direct. That caused the direct traffic numbers to explode.
— Yeah, the user ID kept changing. It was a tough bug to catch. Like you said, we checked everything. But tracking that specific issue down was a real headache. And like you said, cookie management platforms aren't perfect. We work with most of them in Turkey. But that doesn't mean they're error-free. Many brands use them and still make obvious mistakes. Sometimes, getting support for these issues is a real struggle. You need an Analytics consultant. Or at least someone in-house to debug. This field updates constantly. We had Consent Mode. Now we have Consent Mode v2. New parameters keep getting added.
Are these active for you? It matters. There is a legal side to this.
— A bad setup can cause real headaches for a brand.
— Exactly. It’s not just about bad tracking. There are legal implications too. That’s not our expertise, though. We focus on the technical parameters. We handle the setup. We respect user consent. We model data in Analytics using machine learning. This is crucial for certain properties. Say, 20 people visit my site. Some reject, some accept. You might have a basic Consent Mode setup. It’s still a setup. You’re respecting user choice. But what happens? You might lose half your data or more. Google Analytics 4 uses modeling behind the scenes. You can recover 70% to 80% of your data. Only about 20% will vanish. This gives you a solid sample for your analytics.
It’s great for measurement. That’s why setting up advanced consent mode correctly is vital.
— You need consent mode to prevent data loss. It also keeps you safe from future legal headaches. It’s a critical control point for any business.
— Exactly. Major e-commerce sites in Turkey, what are you waiting for? This is standard in the EEA. They need to respect user data. We’re all consumers at the end of the day. If I check a site for sneakers, I don't want them everywhere. I don't want your remarketing. Maybe I was just browsing.
— It’s just not a priority in Turkey yet.
— Yeah, exactly. Big sites need to get their act together.
— Penalties need to get serious, Zafer.
— Agreed. Penalties should be a real deterrent. Things are different in Europe right now. It's the top priority for all our international brands. They check if Analytics is working right from day one. Things work differently over there. We make sure consent works perfectly alongside Analytics. Beyond that, regarding consent.
— We move forward if there are no issues.
— We looked at faulty e-commerce tracking. I'm checking our topics. Adil and Kamil are here. Yes?
— Let me ask you directly. That’s a mistake too. Zafer, I have a Google Analytics 4 account. I’m a brand. Should I use 360? Or BigQuery? What’s the indicator? I see my data in Analytics. My reports are crashing. They’re full of red exclamation marks. When should I use 360? Or when should I switch to BigQuery?
— I think moving to BigQuery makes more sense. But it can get pricey for high-traffic sites. If I recall correctly, there’s a monthly export limit on the free tier. You need 360 to bypass that. Unless things changed, that’s how I remember it. For smaller sites, BigQuery is actually quite cheap. It’s not as expensive as people think. It might even be free. Google Cloud gives you credits. When you connect BigQuery, data flows right in. What does this get you? Simply put, you get full control over your data.
Instead of relying on Google Analytics reports, you can query BigQuery. You get unsampled data. You see the raw numbers without any sampling. BigQuery integrates with so many tools. You can import Excel data. Match it with your Google Analytics 4 data. Create blended reports. Export data from your CRM. Match it in Google Analytics 4. Run queries in BigQuery. Send that data to Looker for visualization. 360 is super expensive. It's pricey even for huge companies. That's why 360 isn't common. But BigQuery solves those "other" rows or sampling issues. Exactly.
— We're discussing this for a reason. Accounts hit "other" row issues. Or cardinality limits. This shows up as sampling. Don't confuse it with thresholds. Sampling causes real problems. Remember that one brand? We couldn't add anything to reports. Add a parameter or metric. The report immediately hits sampling. It says it can only show 15%. Or maybe 10%. Use 360 or BigQuery to avoid these headaches.
— Exactly. Let’s talk about AI. You can’t have a conversation without it today. How do we use AI in Web Analytics? As a consultant, what are we actually doing here? Let me start before passing it to you. We use it a lot for GTM issues. AI writes great code. We often need custom JavaScript for GTM. What did we do before? We aren't developers. We don't code every day. We’d hunt for scripts or search Stack Overflow. We’d waste time fixing errors in variables.
Or maybe a custom HTML tag. We’d spend hours debugging JavaScript. Now, we just explain the problem.
— You just generate it.
— Yes, it writes the code for us. It usually works on the first try. Or maybe after a few tweaks. It all depends on our prompt. Better prompts mean better results. It saves so much time. I used to spend days on code. I’d bug senior developers for help. I’d ask why things weren't working. Now, I just paste my code. I explain my goal. I mention the error or the missing value. It gives me the fix immediately. Most of the time, it just works.
— I’m sure you’ve been there. You work with a brand. They send third-party code. They want it in GTM for tracking. Sometimes that code just fails. I’ve struggled to push it to GTM. GTM throws errors. It says the syntax is wrong. You know how GTM errors are. It points to line 12. It doesn't explain why. I use AI for that too. I paste the error. I ask what it thinks. It fixes it. It tells me what I missed. It even suggests better ways to write it. Without AI, you’d have to wait. You’d ask the third party for a rewrite. That takes forever.
I rewrote it. Can you push it again? Checking for errors takes forever. AI lets you fix it and keep moving.
— I solved a complex task with AI. I handled a third-party setup by pulling data. You still need some GTM knowledge, though. You must understand the logic. If AI suggests something, you need to verify it. You have to catch its mistakes. AI still hallucinates and makes errors. Don't hand over the whole process. Use it as an assistant. Combine it with your own expertise. AI won't do the whole setup alone. But it's a powerful assistant. It knows more than you. You just have to use it right. Anything else you want to add?
— We covered the main issues users face. Not every single one, but the core problems. If you check these, most issues will be solved.
— Exactly. We’re very active with this content at ZO. Check out our Digital Zone or blog. We have plenty of Analytics content there too. I highly recommend following the ZO community. Let’s wrap it up there. Thanks to everyone for listening. We appreciate your time. See you in the next ZO Talks. Goodbye.
— See you later. Goodbye.
This transcript was generated using AI speech recognition and verified against subtitle style rules.
