— Selamlar herkese, Zeo Talks'a hoş geldiniz. Bu bölümde analytics tarafıyla ilgili konuşacağız; ölçümleme dünyasında biz neler yapıyoruz? Zaten daha önce 2 Zeo Talks'a dahil olmuştuk, Ferit'le birlikte. Ben analytics ekibinde Web Analytics Manager olarak görev yapıyorum; Ferit de senior düzeyinde görev yapan arkadaşım. Belli başlı konularımız var, Ferit'le birlikte onları konuşacağız ama biraz daha, yani, doğaçlama olacak. Hani sadece bir şeye bağlı kalmadan, konu konuyu açacak şekilde olacağını düşünüyorum. Muhtemelen 35-40 dakikalık bir şey düşünebilirsiniz, bir oturum düşünebilirsiniz. Diyerek Ferit, hoş geldin diyorum sana.
— Hoş bulduk. Yine Zeo ekranlarındayız. Özgür, bu süreçte zaten bayağı olmuştu Zeo Talks çekmeyeli; bugün de biraz konuları genişledik. Bir Zeo Talks çekelim dedik.
— Marketing ekibinden biraz kaçtık da Mart ayında yakalandık, değil deme?
— Evet, evet.
— O yüzden güzel oldu. İlk olarak ben şeyi konuşmak istiyorum; ya, biraz daha ısınma turu için. Google Analytics 4 ya da GTM ile fark ettiğimiz, veri tarafındaki tutarsızlıkları nasıl fark ediyoruz? Yani, örnek veriyorum: Bir sorun oluyor, genelde bize nasıl geliniyor? "Yanlış ölçüm yapıyor." Bu herhangi bir şey olabilir; hani temel metrikler olabilir, session, user olabilir, ya da custom kurulmuş bir conversion olabilir. Burada biz nasıl hareket ediyoruz aslında? Yani burada araç olarak ne kullanıyoruz? Real-time rapora mı bakıyoruz? Hani daha çok debug view ile mi biz bunu yapıyoruz, ya da console ile mi? Çünkü çok fazla şey var; hani bunu tespit edebileceğimiz eklenti var, araç var. Burada araç da önerebiliriz; izleyenlerin direkt olarak kullanabileceği araçlar.
Buradan başlayalım istiyorum.
— Ya orada ben sorayım: Session'dır, user'dır, oradaki farklar sence çok çabuk fark ediliyor mu? Markalar bence öyle gelmiyorlar; bence daha çok böyle revenue ya da işte ürün sepeti ekleme, ürün sepetten çıkartma, işte ödeme adımına gitme gibi geliyorlar diye düşünüyorum. Session'ı, user'ı fark etmek biraz daha zor olmuyor mu sence?
— Orada bence zor olmuyor aslında. Niye? Çünkü trajik bir düşüş olursa, yani örnek veriyorum, markanın aylık 1 milyon ziyaretçisi varken, ya da atıyorum günde 100 bin ziyaretçisi varken, birdenbire 60 bine düşerse 2-3 gün üst üste, marka burada şey diyor; yani hani "benim verim düştü". Aynen. Yani tamam, hani daha çok conversion odaklı markalar; doğal olarak da böyle olması gerekiyor. Ama bence herhangi bir metrik, yani zaten session düşerse user da düşüyor, user düşerse engagement da düşüyor. Genel bir düşüş oluyor çoğu zaman. Bence fark ediliyor; fakat bunu çözmek biraz zor oluyor.
— Evet.
— Ya orada, hani, şunu görebiliyoruz ya bazen: Debug'luyoruz fakat bir sorun yok. Ben kendimi debug view'da görebiliyorum. Network'te collect olarak istek geliyor, 200'den kodu döndürüyor. Real-time'da kendimi görüyorum, vesaire. Orada biraz işler daha detaya inmemizi gerektiriyor. Burada da şuna dönüyoruz: Bazı sayfalarda problem var, yani genel olarak. Ya da consent ile alakalı, yani çerez yönetimi tarafıyla alakalı bir problem buna sebep olmuş olabilir. Yani ben kendimi görüyorum ama o tarafta onay vermeyen kullanıcıları, gelişmiş consent mode kapsamında değerlendirmiyor mu property? Bu biraz daha bence konuşulması gereken şey oluyor o durumda. Extension anlamında ne kullanıyoruz? Hani böyle bir problem oldu. Tek assistant tarafını ben çok kullanıyorum. Yani direkt olarak.
— Mesela çok. Yani assistant'a girmeden debugger açıyorum. Sayıyor mu, saymıyor mu, duplicate var mı yok mu, bir oradan bakıyorum. Çünkü tek assistant'a girince işte bağlayacaksın da tekrar connect edeceksin de, mesela çok bilgi sahibi olmayan bir kullanıcı için, işte debugger ekleyip hemen console'a. Devamında işte şey yapabilir: JFor akıyor mu, ya da işte akmıyor mu, duplicate var mı yok mu, ona bakabilir direkt olarak. Ya da mesela sayfalardan şüpheleniyoruz; atıyorum ana sayfada geliyor, sayfalardan şüpheleniyoruz. Sayfa değiştirebilir, daha detay sayfalara gidebilir. Daha alttaki sayfalar, yani işte bu kategori ağacının daha altındaki sayfalara gidebilir ki belki oralarda eklenmemiş olabilir. Burada başka ne kullanıyoruz? Hani tek assistant kullanıyorsun da, gerçi CSP hatası alıyor olabilir. Bunu da çok görüyoruz mesela; ara ara hep karşımıza geliyor, Content Security Policy hatası.
Farkında olmadan güncelleme yapılıyor ya da güncelleme yapılmıyor. JFor da eklemiş olursak.
— Bu arada ben şeyin lafını kestim, şeyi söyleyecektim; hani bu eklentileri biz söylüyoruz ama bence video altında da paylaşalım ki, hani deneyimlenmeyen kişiler varsa deneyimlesinler. Hani debug yapabilsinler, bizim yaptığımız gibi. O yüzden hani sen anlatırken ben de not aldım; analytics debugger'ı ekledim. Mesela tek assistant var, onu.
— Analytics debugger'ı kullanırken ama bir JFor şeyini, özelliğini açmak lazım orada. Onu da bir söyleyelim. Orada JFor'u görüp görmemesini ayarlamak lazım.
— Ve o eklentide çok fazla şey var. O, hani, biraz daha eklenti düzeyine indiğimiz zaman, yani sadece Google Analytics 4 özelliğine düşünmemek lazım. Yani orada siz şeyi de açabiliyorsunuz; Adobe ya da Matomo gibi tool'ları da debug edebiliyorsunuz. Yani mükemmel bir.
— Ekranlara da bakabiliyorsun.
— Aynen, mükemmel bir tool. Senin de favori tool'un biliyorum. Ekran görüntüleri hep şeyle geliyor.
— Yani insanlara anlatırken hep oradan aktarmak güzel oluyor. Çünkü çok basit bir şekilde aktarıyor konuyu. Hani aynen.
— Benim de çok iyi.
— Oradan direkt, hani, zaten şeyde de veriyor; mesela JFor ID'inde veriyor senin. "Bakın" diyorsun, "bu burada sayıyor saymıyor" ya da işte JFor olmadığında "JFor yok" diyor zaten direkt sana.
— Ya ben orada biraz da, bu arada, eski kafalıyım da. Biraz network'e kayıyor kafam benim.
— Ha o da olabilir, tabii.
— Aynen. Yani orada direkt olarak bir eklentiden ziyade, mesela server-side falan olduğu zaman bazı eklentiler yakalayamıyor. Hani şeyi, oradaki gönderimi. O yüzden ben console'u kullanıyorum ama kesinlikle şeyi, hani, debugger'ı, tek assistant'ı ya da ne bileyim, farklı bir eklenti daha vardı, o aklıma gelmedi şimdi.
— Orada ben de şeyi yapayım: Network'ten bakmaya çalışırken JFor yazmıyoruz, collect yazıyoruz.
— Aynen, collect olarak toplanıyor veriler.
— Aynen, collect yazıp oradan JFor gidiyor mu gitmiyor mu. Çünkü her sayfada iseniz o collect'i bir daha atması gerekiyor. Onu da dikkat etmek lazım.
— Aynen öyle. Onun haricinde zaten Google Analytics 4'ün, Universal Analytics'ten çok daha öne çıktığı konulardan biri debug view görünümü. Yani debug view'ı aktif hale getirerek, ki bunu nasıl aktif hale getiriyorduk? Birden fazla yöntemi vardı. En çok kullandığımız bir yöntem, Tag Manager'ın ön izleme modundaysanız zaten sizin yaptığınız tüm aksiyonlar debug view'a gidiyor ve debug view'da görebiliyorsunuz kendinizi. Orada, hani, bir problem olmadan yansıyor. Zaten Tag Manager'ın ön izleme modu da bir debug etme aracı. Bu arada onu da ekleyeyim; hani oradan da debug edebiliyorsunuz. Onun haricinde Google Analytics Debugger diye bir eklenti var. Bu, az önce bahsettiğimiz Ferit'in söylediği şeyden değil; Google'ın kendi aracı bu, extension'ı. Google Analytics Debugger diye geçiyor.
Bunu şey yaptığınız zaman, yani extension tarafına ekleyip üzerine bir kere tıkladığınızda on konumuna geliyor ve hangi sitede geziniyorsanız gezinin, analytics property'sinin debug view'ını aktif hale getiriyorsunuz aslında. O yüzden bu eklenti de, Google Analytics Debugger eklentisi, Google'ın, bizim için önemli eklentilerden biri. Bunu da not alıyorum ben. Bunların hepsini paylaşacağız çünkü, ki havada kalmasın. Yani deneyebilin siz de, biz bunları anlatırken. Bu şekilde aslında debug kısmı, değil mi? Yani var mı ekstradan atladığımız? Kesin vardır bu arada. Ama bizim kullandığımız.
— Yani ama ne kadar faydalı bilmiyorum. Ben real-time raporları hiçbir zaman kullanmıyorum. Çünkü şeyi göstermiyor, kullanıcı özelinde bir şey göstermiyor. Real-time raporlar başka bir kullanıcıya da düşebilir aynı anda istedi. O yüzden ben real-time raporlarını çok tavsiye etmiyorum. Burada tavsiye ettiğimiz, hani, 3 tane tool; işte tek assistant, işte tag manager, işte debugger ve şey, analytics debug kısmını on yapmak. Onlar çok yeterli olur diye düşünüyorum, herhangi bir şeyi kontrol ederken.
— Aynen öyle. Kontrol etmeyi konuştuk. Biraz da veri zenginleştirme tarafını konuşalım istiyorum. Yani bir kurulumu yaparken, bir, yani, data layer olabilir ya da ne bileyim, Android/iOS tarafında bir şeyi takip etmek için bir dokümantasyon oluşturuyoruz. Burada dokümantasyonları biz nasıl oluşturuyoruz aslında? Orada developer'la iletişime geçme noktasında aslında nasıl hareket ediyoruz? Buradaki şeyler nelerdir, bakış açıları?
— Ben mümkün olduğunca az iletişime geçmeye çalışıyorum. Yani raporu öyle bir hazırlayalım ki mümkün olduğunca az iletişime geçelim. Burada şey kritik bence: Ekran görüntüsü, yani nerede çalışacağına dair ekran görüntüsü. Yani şimdi adama "add payment info" deyince adam anlayamayabiliyor bunu. Çünkü adamın ilgilendiği alan olmayabilir bu konu. Yani başka kodlarla da ilgileniyor olabilir. Senin o kod bloğunu bilmek zorunda değil. "Add payment info" deyince, işte kredi kartının girildiği alanda çalışması gerektiğini bence görselle göstermek zorundasın. Bu senin görevin yani.
— Tabii.
— Bir de kod bloklarının temiz olması önemli bence burada. Her şeyin isimlendirmesinin düzgün olması. Bir de şöyle bir şey var: Şimdi kod bloklarında bir sürü şey yazıyor. İşte bir önceki e-commerce nesnesinin seed'i de olabilir bu, işte event adı da olabilir, işte item ID de olabilir, ya da ne bileyim, işte item list name de olabilir. Bunların ne olduğu da önemli. Şimdi orada zaten çok karışıklık yaşanıyor. İşte event name'in ne olduğunu anlıyor. Bir önceki e-commerce nesnesini silmeyi de anlıyor. Ama item ID deyince yazılımcı bir kalıyor orada. Şimdi item ID ne demek? Markaların kullandığı SKU'lar var, işte kendi item ID'leri var, transaction ID'leri de olabilir belki bunlar.
Bir sürü ID var. Burada onları detaylıca açıklamak önemli. Hatta mesela bunları yollarken ben işaretleyerek de yolluyorum. Mesela atıyorum "view item list" yolladım. Bu event normalde liste görüntülendiğinde çalışması lazım. Ama listenin ben oradaki şeyini de çekiyorum, o kategori ağacını da çekiyorum ki, o kategori ağacına göre yazdığımı bilsin diye o. Yoksa yazılımcı, gelmeyen yazılımcı da oluyor. Mesela yapıyor, tamamen hatalı, hiç gelmemiş, sormamış. E bir daha değiştiriyoruz baştan ondan sonra her şeyi. O büyük bir problem oluyor yani. O tarafta ben ona dikkat etmeye çalışıyorum.
— Aynen. Zaten şey konusu var: Hangi siteye bu entegrasyon yapılacaksa, o siteye göre optimize etme o dokümanı. Yani şimdi zaten internet ortamında, özellikle Google'ın da paylaştığı, bir Enhanced E-commerce nasıl kurulması gerekir, hangi parametre neye karşılık geliyor, ne zaman çalışmalı, hepsi var bunların zaten. Hani yazılımcı gidip oradan, hani o bilgiye kolayca ulaşabilir. Ama burada bizim yapmamız gereken şu oluyor: O sitenin arayüzüne uygun aslında, senin dediğin gibi. Yani bazı sitelerde o checkout aşaması 3 adımdan oluşurken, bazı sitelerde 5 adımdan oluşabiliyor. Yani kargo süreci olan site de var, ya da bir online bir şey satıyor da olabilir. Hiçbir kargo süreci de olmayabilir. Bir uçak bileti satıyor olabilir. Yani burada o marka web sitesi özelinde ya da uygulama özelinde bunu optimize etmek gerekiyor.
Ve dediğin gibi oradaki parametreleri anlatmak gerekiyor. Yani örnek veriyorum: index. Index ne? Hani bunu oradaki developer bilmek zorunda değil. Bunu bizim aktarmamız lazım. Yani bu index'e sen hangi değeri göndereceksin? Item name'e neyi göndereceksin? ID'ye neyi göndereceksin? Price'ı nasıl göndereceksin? Bunların hepsini tek tek, tane tane açıkladığımız bir dokümantasyon aslında bizim yaptığımız. Ve bunu yaptığın zaman zaten senin kendi iş eforun da azalıyor. Çünkü sen orada ucu açık bir brief verdiğin zaman, yani kötü bir dokümantasyon yaptığın zaman, karşı taraf bunu anlamayacak. Ya da anlamaya çalışarak kendi zamanını da kaybedecek. Ki çoğu insan, ki ben de öyleyimdir, kendi zamanını kaybetmeden detay ister.
Yani sen bunu bana gönderdin de bu yetersiz diye detay istemek oluyor burada. Hatta bir toplantı yapalım. Gel bunu anlat. Bu neden kaynaklandı? Benim kötü dokümantasyon yapmamdan kaynaklandı aslında. Yani orada mükemmel bir dokümantasyon çıkartmak zorundayız. Ki biz SEO içerisinde, analytics departmanında buna çok dikkat ediyoruz. Ki yani bunu da söylemekte şey görmüyorum. Birçok markadan da bu konuda olumlu geri dönüş alıyoruz. Hani çok güzel dokümantasyon. Hani yazılım ekibinden de aynı şekilde. Hani çok hızlı bir şekilde yapabildik gibi. Ama tabii ki de eksik bıraktığımız, hatalı yaptığımız yerler de olabiliyordur. Onları da hızlıca revize edip, aslında entegrasyonun yapılması için tekrar gönderiyoruz ve entegrasyon yapılıyor. Burada şey de önemli bu arada; hani dokümantasyon önemli, fakat o entegrasyonu yapacak yazılımcının deneyimi de önemli.
Daha önce bunu hiç yapmayan junior bir yazılımcıysa, ki çok karşılaşıyoruz, hani genelde senior tipler daha iyi şey işlerle uğraşırken, juniorlara bu tip işler paslanabiliyor aslında. O yüzden böyle olduğu zaman senin orada mükemmel dokümantasyon yapman da aslında pek bir, aynen, pek bir işe yaramıyor. Senin onu açıklaman lazım. Defalarca belki de.
— Bir de ben burada şeyi eklemek istiyorum. Mesela string veriler, number veriler, onlar da bence önemli. Onları da bir tanımlamak gerekiyor. Gerçi ben çoğu zaman yapmıyorum. Yani raporda bunu belirtiyorum. Raporun, kod bloğunun içerisinde belirtiyorum. Ama belki hani burada şey de yapılabilir: "Bu veri string, bu veri number, bu veri böyle gönderilmesi lazım, bunu böyle toplaman lazım" şeklinde. Orada ekstradan bir yönlendirme de yapılabilir diye düşünüyorum. Çünkü şeyde çok rastladım ben; number gönderilmesi gereken verilerin number gönderilmediğine, number gönderilmemesi gereken verilerin number gönderildiğine çok rastladım.
Hani onu da bir detaylıca açıklamak lazım orada.
— Aynen. Yani orada, çünkü hani atıyorum, item ID bir number'dır aslında, fakat string gönderilmesi gerekiyor. Doğru mu? Yani orada number göndermenin amacı ne? Onun matematiksel bir işleme tabi olması, analytics tarafında. Yani bir gelirse bu, bir revenue ise, bunun number olarak gönderilmesi gerekiyor aslında. Çok basit. Quantity ise, öyle değil mi? Bir number'dır bu. Price bir para birimi olduğu için bunun bir matematiksel işleme tabi tutulacağı için, number olarak gönderilmesi gerekiyor. Bunlar aslında yanlış gönderimler, en çok kurulum sonrası hataya neden olan kısımlar. O yüzden dokümantasyon okey. Fakat dokümantasyonda bunları belirtmiyorsak, yani parametre düzeyine inmeden bir dokümante ediyorsak, Enhanced E-commerce'da yine problem olabiliyor.
O yüzden yanlış gönderimler bizim direkt verilerimizi bozuyor açıkçası. O yüzden bu da bizim önemli gördüğümüz kısımlardan biri. Var mı bu konuda farklı söyleyeceğin bir şey?
— Yok. Burada farklı söyleyecek çok bir şey yok aslında. Aktardık detaylarını. Ama buradan şeye geçebiliriz: Burada en çok gördüğümüz yanlışlar ne? Yani biz aslında bu konuyu event'ler özelinde, hatta daha da çok Enhanced E-commerce üzerinde konuştuk. Çünkü bence bir web sitede kurulabilecek en kritik event'ler bunlar. Burada şeye geçebiliriz: Bu zamandır çalışıyoruz, burada gördüğümüz en kritik hatalar ya da en çok gördüğümüz hatalar ne diye geçebiliriz. Orada ben başlatabilirim konuyu. Benim en çok gördüğüm hata şu: Mesela belli başlı event'ler var. Atıyorum select item, ürün seçiminde çalışması lazım. View item list, ürün listesi görüntülendiğinde çalışması lazım. View item, ürün görüntülendiğinde çalışması lazım. Çoğu marka bunu şurada yapıyor: Ürün sayfasında yapmış.
İşte view item list çalışıyor, select item çalışıyor, view item çalışıyor. Ana sayfada da ürünün var ama yapmamış. Ana sayfada listen var, yapmamış. Ürün içerisinde ürün listesi var. Yani ürünün aşağı kaydırdıkça benzer ürünleri görebiliyorsun, yapmamış.
— Ya da modül var. Third party bir modül var.
— Aynen. Third party modüller var. Bir pop-up çıkıyor, orada ürün gösteriyor. Orada yapmamış bu event'leri. Remove mesela remove from cart'ta çok fazla görüyorum ben.
— Add to cart.
— Add to cart'ta da olur. Ana sayfada add to cart yapıyorum, olmuyor. Gittim üründen add to cart yaptım, mesela yandaki pop-up açıldı. Tamam mı? Yandaki pop-up'ta da add to cart artı var. Orada da yapabiliyorum. Orada çalışmıyor. Ben bu capture'ı koşturmadım. E sepete gittim. Sepette ben bu ürünü iki kere almak istiyorum belki. Çoğu ben yaparım yani bunu. Sepette bir ürünü iki kere de eklediğim oluyor benim. Sepette bir daha basıyorum ve orada da çalışmıyor. O zaman sen hangi add to cart'ı saydın? Sadece ürün içindeki add to cart'ı saydın. Çok eksik bir veri mesela. Neredeyse belki %50'sini, %60'ını kaybettin verinin. İşte benim add to cart'ım bu kadar demek, orada sonra çok yanlış. Benim ürün listem görüntülendi demek, çok yanlış bence bu mesela burada.
Sen bununla çok karşılaştın mı bilmiyorum ama ben çok karşılaşıyorum yani.
— Tabii tabii. Orada zaten dediğin şey, o quantity, adet miktarının arttırılması mesela sepette ıskalanan yerlerden biri. Ya da ürün detay sayfasında, tamam, zaten orası en temel add to cart aksiyona alınabilecek bir yer. Ama ürün detayda da add to cart yapabiliyorsun. Çoğu site yapısında. Yani direkt sepete ekle diyorsun, ürün sepete gidiyor. Ya da dediğin gibi bir modül çıkıyor orada, bir third party modülü. Orada bir sepete ekleme yapılıyor. Sen ne oluyor? Sadece ürün detayı saydığın için, senin sepete eklemen atıyorum 50.000 iken, ne oluyor?
35.000'e düşüyor aslında. Ya bu o veriyi hiç ölçmesen daha iyi. Yani çünkü doğru bir veri değil bu. Hadi şunu anlarım: 50.000 iken 48.000, 47.000. Hani illa ıskalanır. Neticede bir şeyler engelleyebilir. Kullanıcının tarayıcısı, girdiği cihaz, hani çalışmaz, JavaScript temelli bir şey. Bir şeyler bloklayabilir. Fakat böyle temel hataları yaptığın zaman, zaten hatayı sen kendin yaratıyorsun. O bozulmadaki hatayı sen kendi elinle yaratmış oluyorsun. Ya şeye geldik aslında buradan. Dokümantasyon, dokümantasyonu verdik, entegrasyon. Aslında entegrasyon tarafında yapılan hatalar bunlar. Şey tarafında da çok oluyor. Purchase tarafında. Yani bir satın alma gerçekleşiyor. Oradaki quantity aslında 1 gözüküyor. Halbuki 2.
— Evet.
— Yani mesela o üründen 2 tane eklenmiş. Çarpı 2 olması lazım. Bu ne oluyor? Senin her şeyini etkiliyor. Ciro'nu etkiliyor. O ürünün satın alma adedini etkiliyor. Her şeyi etkiliyorsun yani. Bir tane yanlış. Oradaki tüm veri analytics içerisinde bozuluyor. Bu tabii şeye de sebep oluyor. Yani bu event'ler sadece Google Analytics 4 içerisinde değil. Yani GTM'den aynı add to cart'ı sen Meta'ya, Ads'e gönderiyorsun.
— Evet.
— TikTok'a gönderiyorsun. Atıyorum.
— Hatalı oluyor. Ben mesela şurada şeyi karşılaşıyorum: Quantity. Bence basit bir hata yine. Purchase'in çoklanması durumu. Sayfaya gidince purchase çoklanıyor. Her zaman bunu komut ederim. Çok kritik bir hata bence. Ben mesela alışverişlerimde, alışverişimden sonra işte bir daha girer bakarım, sayfayı bir yenilerim. Yapabilirim ben. Kullanıcıyım yani. Böyle bir aksiyonum var. Sayfayı yenilediğim zaman tekrar purchase atıyor. Aynı ürünü sanki bir daha almışım gibi. Bir daha almışım gibi. 5 kere yenilersem aynı üründen 5 kere almışım gibi. Ne oldu? Revenue gitti. İşte ürünler gitti. Senin bütün kârlılığın tamamen yanlış hesaplandı. Bunlara dikkat etmek lazım. Hani aynı kodu bir kere çalıştırmak gerekiyor. Bu kritik kodla işte. Mesela purchase bir kere çalışacak. O transaction ID bir kere atacak. Sonra bitecek orada.
— Aynen öyle. Diğer bir konumuz da direkt olarak geçebileceğimiz, PII verileri. Yani ne demek? Kullanıcıyı doğrudan tanımlayabilecek bilgiler. Benim adım soyadım, mail adresim, telefon numaram, T.C. kimlik numaram. Çoğaltabilirsiniz böyle. Hani bunlar doğrudan beni tanımlayan bilgiler. Cinsiyetim değil. Ne bileyim, yaşım değil. Bunlar zaten analytics'in kullanıcı hakkında tuttuğu ender bilgilerdi aslında. Kullanıcı tarafta çok veri göremiyoruz. Ki Google Analytics 4 bu tarafta daha hassas. Eski Universal Analytics'e göre. Hatta yaş raporlarında unknown veri çok daha fazla. Her zaman. Değil mi? Yani her report'ta bunu görüyoruz. Yani null set veri, yaş, lokasyon da aynı şekilde. Çok fazla. Çünkü hani işin biraz daha teknik tarafına girersek, IP'deki son hanenin direkt maskelenmesi Google Analytics 4'te.
O senin lokasyonunla da belki alakalı. Ki böyle bir şey oluyor. Çünkü Universal Analytics'te biz bunu şey yapıyorduk. Anonymized IP deyip ekstra GTM'den anonimleştiriyorduk. Yani anonymized IP tool yaptığımız zaman o IP'yi anonimleştiriyordu. Ama Google Analytics 4 bunu zaten varsayılan olarak getirdi. Aynen. O yüzden bu bakış açısıyla ki kullanıcı verilerini konuştuğumuz dünyada PII çok hassas bir konu. Analytics hesabının ki bizim başımıza hiç gelmedi Allah'tan. Hani öyle bir şeyimiz olmadı. Çünkü biz hani hemen yakalıyoruz. Neticede biz bu işin danışmanlığını veren kişilersek, bunu yakalamak da bizim görevimiz. Geçtiğimiz günlerde bir markada daha yakaladık. Mail adresi gibi bir bilgiydi. Direkt silme isteği gönderdim. Biraz uzun sürdü.
Bayağı uzun sürdü bu arada hani o silme isteği. Fakat eninde sonunda o silinebiliyor. Yani o dünyanın sonu olmuyor. O yüzden kişisel verileri tespit etme tarafıyla ilgili biraz konuşabiliriz. Yani mail adresini nasıl yakalayabiliriz? Örnek veriyorum: Yüzlerce dimension altında veri toplanıyor. Binlerce metrik sallıyorum. Yüzlerce metrik var burada. Genelde ne oluyor? Bir parametrenin altında geliyor bu. Mesela sayfa. Kullanıcı satın alırken URL'de mail adresi taşınıyor.
— Evet.
— Çok karşılaştığımız bir şey söylüyorum şu an. URL'de mail adresi taşınıyor. ferit@leo.org mesela. Telefon numarası da taşınıyor. Ne güzel. Bunların hepsi o sayfanın parametreleri olarak raporuna gidiyor. Yani siz bunu istemeden toplamış oluyorsunuz. Fakat Google Analytics 4 bunu fark edebiliyor. Hani onun bir mail adresi olduğunu, @gmail.com, @hotmail.com ki çok açık, bir telefon numarası olduğunu anlayabiliyor. O yüzden bunları biz nasıl yakalıyoruz? @gmail.com diye aratarak çok manuel bir şey. Ondan sonra ne bileyim, bir telefon numarası zaten kendini belli ediyor. Ve şöyle yakalanabiliyor. Genelde sayfa raporu için bahsediyorum. Çok fazla parametre oluşuyorsa sayfada, hani örnek veriyorum, senin sitende 100 sayfa var. Analytics'e bir giriyorsun, 1100 tane page width var.
Orada demek ki bir parametre ekleniyor sayfaya ki kendini duplike ediyor sayfa sürekli. Öyle yakalanabiliyor. Manuel yakalayabiliyoruz. Onun haricinde bir custom event'in alt parametresi olabiliyor. Örneğin ödeme yöntemi seçerken kullanıcının direkt kart bilgisinin bir kısmı gidiyor belki oraya. Adı soyadı. Atıyorum yani. Hani bir yazılımsal bir bug'la olabilir bu. Ya da ne bileyim, input'ların, input'larla alakalı olabilir işin teknik kısmı. Öyle gidebilir. O yüzden zaten şeyde çok vardır bu arada. Hani PII'yı nasıl tespit edeceksiniz diye. Ben onunla ilgili de bir şey ekleyeyim. Direkt link ekleyelim videonun altına. Kendi hesabınızda bunu kontrol edin siz de.
— Bu arada ben burada ince bir trik ekleyeyim. Zafer'in mesela söylemiş olduğu kırılımlara bakabilirsiniz ama bu kırılımların en üstlerine bakmayın. Bu kırılımların en az session alan, en az view alan, en az user alan kırılımlarına bakın bence. Yani tersine çevirin raporu. Çünkü böyle şeyler çok az oluyor. Bug'lı oluyorlar. Yanlış ürün verilmiş oluyorlar. Bunlar hep en az yerlerden çıkıyor. O yüzden ben bunların kontrolünü yaparken hep raporu tersine çeviririz. İşte en az user, en az session oluşturan kısımlara bakarım ki oradan kaydırıp bakayım. Çünkü böyle benim karşımda hiç çıkmadı. Ben 2,5 yıldır sektördeyim neredeyse. Zafer'in de karşısında bir iki defa bence anca çıkmıştır. Çok nadir olan bir şey. O yüzden en tersten bakıp birkaç sayfa kaydırmam yeterli oluyor benim yani.
— Bunu ben aslında bir ekran paylaşmak istiyorum. Şu an o kaynağı ararken de direkt hani bunu somutlaştırmak istiyorum. Ekran paylaşımı diyorum. Şu an görünüyor mu ekranım acaba Ferit? Aynen paylaşıyorum. Mesela az önce bahsettiğim email. Analytics'e nasıl geliyor? Ya da first name, last name. Hani sitede bu taşınıyor URL ile birlikte. Genelde en çok karşılaşılan bu. Bunu aslında page path raporu, az önce bahsettiğim gibi, page path raporunun aynen burada yani first name olarak bunları aratmanız lazım. Ya da tag manager'dan bunları bloklamak olabilir. Bu şekilde şey yapabiliriz aslında. Aynen. Yani biraz somutlaştırmak istedim. Onun haricinde ben bu arada az önce gösterdiğim şeyi de şeye linkleyeceğiz ki internette çok fazla PII diye arattığınız zaman, PII in C4 gibi bir arama yaptığınız zaman çok daha fazlasını zaten buluyorsunuz.
Önemli konulardan biri ki şu an GDPR, KVKK dünyasındayız neticede. Bunları ki hani PII'dan ziyade direkt cookie'lerin tartışıldığı bir dünyadayız. O yüzden bu kısım önemli. Onun haricinde bakıyorum, kullanıcı yolculuğuyla alakalı bir konumuz var ki onun entegrasyon tarafından konuştuk. Biraz şey tarafını konuşabiliriz onun. Hani tamam entegrasyonu yaptık. Kullanıcı @paymentinfo, @shippinginfo ya da begin checkout bütün adımlardan geçiyor. Burada bu raporlar bize ne sağlayabilir? Hani entegrasyon tarafını konuştuk. Bu konuda da biraz bence markanın raporlama tarafını. Hani markaya bu işi raporlama ya da marka buradan neyi talep etmeli? Bu event'lerden ne sonuç çıkarmalı? Bunları bence konuşmalıyız şu aşamada diye düşünüyorum.
— Burada şunu söyleyeyim. Aslında funnel diyoruz biz bunlara. Yani birbirine bağlı şekilde event'ler bir funnel oluşturuyor sonuçta bize. Purchase'e kadar giden adımları funnel'laştırıyoruz. Burada bence birinci fayda şu: Kullanıcı nerede kayboluyor? Senin sitende? Hangi adımda? Bu arada bu satın alma için konuşulmayabilir tamamen. Biz bunların dışında da entegrasyonlar yapıyoruz. Mesela işte sigorta sitelerinde funnel'lar olabilir. Senin kişisel bilgilerini soruyor çünkü bu siteler. İşte neyi sigorta atmak istiyorsun? Sen kimsin? Nerede yaşıyorsun? Ürünün ne? Ne yapmak istiyorsun? Gibi şeyler soruyorlar. O yüzden bunlar böyle step'leştirilip funnel haline getirilebilir. Zaten funnel'ların temel mantığı burada kullanıcılar nerede düşüyor? Hangi step'te düşüyorlar?
Öncelikle bence faydası bu. Hangi adımda düştüğünü tespit etmek. Ben en çok bunlar için kullanıyorum funnel'ı.
— Aynen. Yani burada gitgide azalan bir yapıda zaten funnel mantığı. Kullanıcıdan siz hani örnek veriyorum, bir T.C. kimlik numarası istiyorsanız, hani her sektörde zorunlu olmayabilir. Bunu oradan çıkartmak mantıklı olabilir. Neden? Çünkü kullanıcı o funnel'ın o step'inde düşüyorsa demek ki bir şeye takılıyor. Ya kargo ücreti görüyor.
— Evet.
— En çok karşılaştığımız. Yani kullanıcı geliyor, checkout geçiyor. Çok yüksek bir rakam sayı. Şeye geçiyor. @shippinginfo'ya geçiyor. Orada kargo bilgisini görüyor. Kargo tutarını. Belki vazgeçiyor. Farklı bir siteye yöneliyor. Bunu Analytics'ten tespit edebiliyorsunuz. Yani o funnel'ı düzgün kurduğunuz zaman ve şeyler de düzgün çalışıyorsa event'leriniz, onu çok rahat bir şekilde tespit edebiliyorsunuz. Funnel'ın zaten genel geçer olarak kullanıldığı taraf e-ticaret tarafı. Onun haricinde bir üyelikte de bu olabilir. Yani direkt şey söyledik biz ama hani bir inance e-commerce dünyası değil sadece. Orada siz kendi step'lerinizi oluşturabiliyorsunuz. Bir formdur. Örnek veriyorum. Bir araba markasında test sürüşü için bir form dolduruyorsun. Birden fazla adım, araç var.
Adım var. Onların hepsini alt parametrelerle birlikte gönderip kullanıcı hangi step'te test yapmaktan vazgeçiyor mu bu taraftan analiz edebiliyorsun aslında. Yani kullanıcıyı orada kaçıran bir şey mi var? Çünkü bir insan bir şeye karar verdiği zaman, bir form doldurmaya, bir ürünü satın almaya karar verdiği yoldan çıkıyorsa vazgeçiyor. Yani çok basit. Eğer teknik bir hata yoksa. Yani o da yakalanabiliyor bu arada. Çünkü aynen. Yani çalışmıyor bir şey. Kimse fark etmiyor bunu içeride vesaire. Onu da fark edebiliyorsunuz. Çünkü bazı hatalar kronik ve sürekli çıkmayabiliyor.
Ya da bazı tarayıcılarda yaşanabiliyor bu sorun. Funnel'ı tarayıcı bazlı, cihaz bazlı kırabiliyorsunuz. Yani hani mobilde ayrı, webde ayrı, hatta platform bazlı. iOS, Android ayrı şekilde de bakabiliyorsunuz. O yüzden burada oturup gerçekten hani sadece şey de değil. Bir Analytics danışmanlığı işi de değil bu. Kendi markanızın hani zor şeyler değil bu anlattığımız şeyler aslında. Yani biraz kurcalamak gerekiyor. Bunları şey yapmak lazım. Evet. Entegrasyon biraz şey bir iş. Hani entegrasyon için bir danışmanlığa ihtiyacınız var ama kurulduktan sonra aynen funnel analizini bir yere kadar gayet yapabilirsiniz.
Yani hiç sıfır bilginiz olsa bile. O yüzden eğer çalışan bir funnel yapınız varsa bunu böyle belli periyotlarla kontrol etmek faydalı olabilir. Hangi platform özelinde ne gibi hatalarla karşılaşıyorsunuz? Sizi final bayrağına gidecek noktadan hangisi ediyor aslında? Onu orada yakalayabiliyorsunuz. O da funnel analizinin aslında nihai amacı.
— Sıfır. Kurulumların amacı komple aslında zaten. Bu kadar ardı ardına kurulum yapmanın temel amacı aslında.
— Evet. Evet. Aynen öyle. Şeyden konuşmadık bu arada. Yani hep veriden konuştuk da konsept modu konuşmasak olmaz. Yani bir şeyler eksik kalır.
— Ama ben burada kendimizi tebrik etmek istiyorum. Bence ZEO'daki çoğu markaya konsept modu farkındalığı kazandırmış bulunuyoruz. Çünkü çoğu markayı bir şekilde görüşmeye ikna ettik. Bunun gerçekten olduğunu söyledik. Kanunları attık. Kararnameleri attık. Bunun olacağını söyledik. ZEO'daki çoğu marka buna artık ikna olmuş durumda. Kabullenmiş durumda. Kuracaklar. Bütün sektöre de bunun yayılmasını dilerim artık. Çünkü insanların verisi önemli. Burada biraz konu şeye de giriyor sonuçta. Burada müşteri biz de olabiliyoruz. Benim tercihlerimin önemli olduğunu hani bu felsefi bir konuda birazcık. Ben toplanmak verilerimin analiz edilmesi istemiyorsam analiz edilmemesi lazım. Ben şeyleri hatırlıyorum çünkü. Eskiden böyle şeyler hiç yoktu. Her yerden sağdan soldan var reklam çıkıyordu.
Adblocker dediğim şeyi bilmiyorum. Biraz daha küçüğüm. Adblocker denen şeyi bilmiyorum. Her yerden var reklam çıkıyordu. Sen buna baktın, buna baktın, bu çıktı. Dünyamız böyle bir kanser haline gelmişti. Reklamların da bir sınırı olması lazım. İnsan verisinin toplanmasının da bir sınırı olması lazım. Burada biz veri işi yapıyoruz ama bunların da bir sınırı var. O yüzden bunlara saygılı olmak gerekiyor. Biz burada ZEO olarak iyi bir yol katettiğimizi düşünüyorum. Çünkü geçtiğimiz ay 30 ya da 40 toplantı yaptık bütün markalarımızla. İşte her biri belki yarım saat, bir saat olsa saatlerimizi ayırdık bunu aktarmak için. Ki markalarımız bu duruma düşmesin diye.
— Evet. Evet. Yani bu çünkü bilinmeyen ya da bilinse bile halı altına süpürülen bir konu Türkiye'de. Yani Avrupa Birliği'nde çok katı zaten. Ama dediğin gibi yani biz ZEO içerisindeki Analytics danışmanlığına tabi olmayan markalarla da sadece marka SEO hizmeti alıyor. Reklam hizmeti alıyor. Ona danışmanlık veren danışman aracılığıyla bu bilgilendirmeyi yaptık. Ve hani bizden toplantı istediklerinde de seve seve bu toplantılara dahil olup hatta avukatlarla bazen bu toplantılara girip hani bunun teknik tarafını, neden olması gerektiğini, olursa olumsuz taraflarını, makine öğrenmesiyle eksiklerinin nasıl tamamlanacağını, hani bu konuları çok konuştuğumuz için hani diğer bizim Analytics için çektiğimiz ZEO talks'lara da bakabilirsiniz.
Hani konsept modu biz oralarda zannediyorsam bayağı detaylı konuştuk diye hatırlıyorum. Yani olması gerekiyor bunun artık. Yani bugün olmazsa çünkü ne 2025'te resmi şeyi var bunun. Hani bu dokümanı da paylaştık biz. Şeyle, GDPR'la tam uyumluluk gibi bir hedef söz konusu. Burada çok fazla çerez yönetim platformu var Türkiye'de. Ya da Google'ın direkt önerdiği, bunlar benim partnerim dediği çerez platformları var. Onlarla iletişime geçip aslında hani bunu en kısa zamanda sitenize, uygulamanıza kurmanız gerekiyor. Ki orada senin dediğin şey de önemli. Sadece bu şey değil. Biraz da işin felsefi yönü var. Yani çok büyük sitelerde ben görüyorum yani. Hani bana bir soru soruyorsun orada. Benim verdiğim cevabın toplamaya bir şeyi yok. Yani bu doğru değil.
Bu direkt iki üç siteden bahsediyorum. Dinleyenlerin aklına gelmiştir Türkiye'de büyük sitelerden. Sen bana orada bir soru soruyorsan o reddeti anchor text olarak o banner'ın içerisine gömmeyeceksin. Ben onu direkt şeyde görmek istiyorum çünkü. Aynen. Buton olarak görmek istiyorum. Reddetme hakkımın saklı olduğunu biliyorum. Ama bazen hani onu oraya koyuyorsun. Bastığın zaman da çalışmıyor. Yani o da çok fazla gördüğüm bir şey değil mi? O aynen. O orada var yani. Bir tane banner var orada. Ama bir işlevi yok veri toplamayla alakalı. Yani var olmak için var gerçekten. Hani bu hiç doğru bir şey değil. O yüzden bu konuda biz hassasız. Yani günün sonunda data ile uğraşan insanlarız. Görevimiz hani markaları bu konuda bilgilendirmek.
Bunun mükemmel çalışmasını sağlamak. Bunu yaparken de markanın veriden dolayı bir ciro kaybı yaşamamasını sağlamak. Aslında bu kötü bir şey değil. Yani hani bunu yapıp çok yüksek veriler kaybedip Google'ın da burada çözümleri var. Konsept mod bu yüzden var yani aslında. Sizin o kayıp verinizi yerine koymak için var. O yüzden bu konuda hassas olmak bence güzel bir şey diyebilirim. Onun haricinde var mı farklı bahsetmediğimiz bir konu bu bölümümüzde?
— Yok. İşte veri hakkından bahsettik. Nereden sata yakalanabilir onlardan anlattık. Data layer'a girdik. Sonra devamında data layer'ın nasıl kullanabileceğini anlattık. Kullandığımız data layer'ı nasıl GA4'e aktardığımızı anlattık. Funnel'ları nasıl analiz edebiliriz? Yani artık her veriyi topladık. Funnel'ları nasıl analiz edebiliriz? Onu anlattık. Son olarak yine bir konsept moda değindik. Değinmezsek olmazdı. Aslında anlatacaklarımız bu kadar.
— Evet. Teşekkür ediyoruz bize vakit ayırıp dinlediğiniz için. ZEO kanalında zaten bu tip içerikler sadece Analytics tarafında değil, yapay zeka, SEO, reklam tarafındaki ya da diğer konularla alakalı ZEO talks'lar, içerikler var. ZEO kanalına da abone olup bu içeriklerden faydalanabilirsiniz. Gerek podcast olarak, gerek YouTube içerisinde. Bizi takip etmenizi öneririz diyerekten sağlıcakla kalın diyorum. Görüşmek üzere.
— Hey everyone, welcome to Zeo Talks. Today we’re diving into analytics. What are we doing in the measurement world? Ferit and I have done two Zeo Talks before. I’m the Web Analytics Manager here. Ferit is a senior member of our team. We have a few topics to cover. We’ll keep it casual and improvised. We’ll let the conversation flow naturally. Expect a session around 35 to 40 minutes. Ferit, welcome to the show.
— Thanks. Good to be back on Zeo. It’s been a while since our last talk, Özgür. We’re covering a lot of ground today. Glad we’re doing this.
— We tried to dodge the marketing team, but they caught us in March, right?
— Yeah, exactly.
— That’s great. Let’s start with a warm-up. How do we spot data inconsistencies in Google Analytics 4 or GTM? When a problem pops up, how does it usually reach us? "The tracking is off." This could mean anything. It could be core metrics like sessions or users. It could be a custom conversion. How do we handle this? What tools do we actually use? Do we check the real-time report? Do we use DebugView or the console? There are so many options. There are plenty of extensions and tools to spot these issues. Let’s recommend some tools the audience can use right away.
Let’s start there.
— Let me ask you this. Are session and user discrepancies easy to spot? I don't think brands notice those first. They usually come to us about revenue, add-to-carts, or checkout steps. Isn't it harder to notice session or user issues?
— I don't think it's that hard. Why? Because if there's a massive drop, they notice. Say a brand has 100,000 daily visitors. If that drops to 60,000 for a few days, they know. They immediately say, "My data is down." Exactly. Conversion-focused brands need this. But every metric is linked. If sessions drop, users drop. If users drop, engagement drops. It’s usually a total decline. It’s easy to spot. But fixing it is tough.
— Yeah.
— Sometimes we debug and see nothing. I see myself in DebugView. The network request returns a 200. I show up in real-time. That’s when we need to dig deeper. We look for page-level issues. Or maybe it’s a consent management problem. I see myself. But is the property failing to track users who opt out under advanced consent mode? That’s the real conversation. What extensions do we use? When that happens, I rely heavily on Tag Assistant. It’s my go-to.
— I skip Tag Assistant. I just open the debugger. I check for counts and duplicates there. Tag Assistant is a hassle. You have to connect and reconnect. For non-technical users, just add the debugger. Check the console. See if the JFor is firing. Check for duplicates directly. Maybe you suspect specific pages. Like the homepage. You can navigate to deeper pages. Check the lower category pages. Maybe tags aren't firing there. What else do we use? Tag Assistant often hits CSP errors. We see that constantly. Content Security Policy errors are common.
Updates happen without you knowing. Or they don't happen. If we added JFor.
— Sorry for interrupting. I wanted to say we should share these extensions. Let's put them under the video. Beginners should try them out. They can debug just like we do. I took notes while you talked. I added Analytics Debugger. There's Tag Assistant too. Add that.
— You need to enable a specific JFor feature in Google Analytics Debugger. Let's mention that. You have to toggle the JFor visibility settings.
— The extension is packed with features. Don't just think about Google Analytics 4. You can also debug tools like Adobe or Matomo. It's an excellent tool.
— You can even see the screens.
— Exactly, it's a perfect tool. I know it's your favorite too. Your screenshots always come from there.
— It's great for explaining things to people. It breaks down complex topics so simply. Exactly.
— Mine is great too.
— It shows it right there. It gives you the item ID. You can see if it’s tracking. If it’s missing, it tells you.
— I’m a bit old-school, though. My brain leans toward the network tab.
— Yeah, that works too.
— Exactly. Some extensions miss server-side requests. That’s why I use the console. But I definitely use the debugger and Tag Assistant. I’m forgetting the name of that other extension.
— Let me add this: When checking the network tab, don't search for JFor. Search for "collect."
— Exactly. Data is collected via collect calls.
— Check if the JFor call fires. It must fire on every page. Keep an eye on that.
— Exactly. Debug view is where Google Analytics 4 really beats Universal Analytics. You need to activate it. There are several ways to do that. The most common way is Tag Manager preview mode. Your actions flow right into debug view. You can see yourself there. It works seamlessly. Tag Manager preview mode is a debugger itself. I should add that. You can debug from there too. Also, there is the Google Analytics Debugger extension. This is different from what Ferit mentioned. It is Google's own official extension. It is called Google Analytics Debugger.
Just add it to your browser. Click it to turn it on. It activates debug view for your Analytics property on any site. This Google Analytics Debugger extension is a key tool for us. I'm taking notes on this. We'll share everything so nothing is left hanging. You can try these out while we explain. That covers the debug part. Did we miss anything? Probably. But this is what we use.
— I don't know how useful they are. I never use real-time reports. They don't show user-specific data. Real-time reports might show another user's data instead. I don't really recommend them. We recommend three tools. Tag Assistant, Tag Manager, and the Google Analytics Debugger. Turning on the Analytics Debugger is enough. That should be plenty for checking anything.
— Exactly. We covered checking. Let's talk about data enrichment. When setting things up, we create documentation. This covers the data layer or tracking on Android/iOS. How do we create that documentation? How do we handle communication with developers? What are the best perspectives here?
— I try to minimize communication. Let's prepare reports that require very little back-and-forth. Screenshots are critical here. Show exactly where it should trigger. Just saying "add payment info" isn't always clear enough. They might not care about this. They have other code to manage. They don't know your specific block. When you say "add payment info," show them the credit card field. Use visuals. That is your job.
— Exactly.
— Clean code is vital here. Use proper naming conventions. Code blocks get messy fast. You have e-commerce objects, event names, item ID, and item list name. Clarity is key. They get the event name. They know to clear the e-commerce object. But "item ID" confuses them. Is it a SKU? A system ID? A transaction ID? There are too many IDs. Explain them in detail. I even annotate my requests. For "view item list," I pull the category tree. I want them to know exactly what I’m tracking.
Sometimes developers just don't show up. They deliver broken code without asking questions. Then we have to redo everything from scratch. It’s a huge problem. I really try to watch out for that.
— Exactly. You have to optimize the documentation for the specific site. Google already provides guides on Enhanced E-commerce. They explain the parameters, what they mean, and when they should trigger. Developers can easily find that info. But we need to tailor it to the site's interface. Like you said, some checkouts have three steps. Others have five. Some sites have shipping. Others sell digital goods. Maybe it’s an airline ticket site. You have to optimize the setup for that specific brand or app. You have to explain the parameters clearly. Take the index, for example. A developer might not know what that is. We have to define it. What value goes into the index? What about the item name?
What goes into the item ID? How should they format the price? We create documentation that breaks everything down step-by-step. Doing this actually saves you a ton of effort later. Vague briefs lead to bad documentation. The other side won't get it. They'll waste time trying to figure it out. Most people, myself included, want details upfront. We don't want to waste time. Asking for more details because the brief was lacking is a waste. Setting up extra meetings to explain things is inefficient. That happens because of my poor documentation. We have to produce perfect documentation.
We prioritize this in our SEO and Analytics departments. I’m proud to say we get great feedback. Brands love our documentation. The dev teams love it too. It helps them move fast. Sure, we make mistakes sometimes. We revise them quickly and resend them for integration. Documentation is key. But the developer's experience matters just as much. We often deal with junior devs. Seniors usually handle the complex stuff. Juniors get these tasks passed to them. Even with perfect documentation, it might not be enough.
You have to explain it. Maybe even multiple times.
— I’d like to add something here. String and number data types are crucial. You need to define them. I don’t always do it. I usually just note it in the report or the code block. Maybe we should specify: "This is a string. This is a number." We should explain how to send and aggregate them. I see this a lot. People send numbers as strings or vice versa. It happens constantly. We really need to explain that in detail.
— Exactly. Take item ID. It looks like a number, but it should be a string. Right? Why send it as a number? Only if you need mathematical operations in Google Analytics. If it’s revenue, it must be a number. It’s simple. Quantity is a number. Price needs to be a number for calculations. These are common mistakes. They cause the most post-setup errors. Documentation is fine. But if you don't define these at the parameter level. You'll still have issues with Enhanced E-commerce. Honestly, bad data ruins our reports. That’s why this part is so critical. Anything else you’d add?
— Not really. We’ve covered the details. Let’s move on to common mistakes. We’ve been focusing on events and Enhanced E-commerce. These are the most critical events for any site. Let’s talk about the errors we see most often. I can kick things off. The biggest issue is event placement. Take select item, view item list, or view item. Brands often only trigger these on the product page. They skip the homepage. They skip the lists. They even skip the related products section at the bottom.
— Or they rely on a third-party module.
— Exactly. Third-party modules exist. A pop-up shows products. They missed the events there. I see it a lot with remove from cart.
— Put it in my bag.
— It happens with add to cart too. I add to cart on the homepage. Nothing happens. I go to the product page. A pop-up opens. See? There’s an add to cart button there too. It doesn't work. I didn't trigger that capture. Then I go to the cart. Maybe I want two of that item. I do that often. I click again in the cart. It still doesn't work. So which add to cart did you track? You only tracked the product page button. That’s incomplete data. You lost 50% or 60% of your data. Claiming that’s your total add to cart is wrong. Saying your product list was viewed is also wrong.
I don't know if you see this often. But I run into it all the time.
— Exactly. Increasing the quantity in the cart is often missed. The product detail page is the main spot for add to cart actions. You can trigger an add to cart right there. Most sites work that way. You click add to cart and it goes. Or maybe a third-party module pops up. If you only track the product page, your add to cart count drops. It might go from 50,000 down to 35,000. Honestly, it's better not to track it at all. That data is just wrong. A small drop from 50,000 to 48,000 is fine. Browsers or devices can block JavaScript. That’s expected.
But these basic mistakes are different. You’re creating the data gap yourself. It comes down to documentation and integration. These are integration errors. It happens a lot with purchase tracking too. The quantity shows as one when it’s actually two.
— Yeah.
— Say you added two items. It should show as times two. This impacts everything. It hits your revenue. It hits your purchase counts. You’re messing up everything. One mistake ruins all your data in Analytics. This causes issues elsewhere too. These events aren't just for Google Analytics 4. You’re sending that same add to cart via GTM to Meta and Ads.
— Exactly.
— Or to TikTok, for example.
— It gets messy. I often see issues with quantity. It’s a simple error. Duplicate purchases are common. The purchase fires again when you refresh the page. I always check for this. It’s a critical bug. After I buy something, I’ll go back and refresh the page. I can do that. I’m a user. That’s a normal action. Refreshing the page fires the purchase again. It looks like I bought the item twice. If I refresh five times, it counts five purchases. Your revenue is toast.
Your product data is gone. Your profitability is calculated all wrong. Watch out for this. You must run the code only once. It’s critical. A purchase event should fire once. It sends the transaction ID once. Then it stops.
— Exactly. Next up, let’s talk about PII. That’s personally identifiable information. My full name, email, phone number, or ID number. You get the idea. These things identify me directly. Not my gender or age. Analytics already tracks those basic user details. We don't see much user-level data. Google Analytics 4 is much stricter here. It’s tighter than the old Universal Analytics. You see way more unknown data in age reports. Always. Right? It’s in every report. Lots of null sets for age and location. If we get technical, Google Analytics 4 masks the last digit of the IP.
That affects your location data too. In Universal Analytics, we had to do this manually. We used anonymized IP in GTM to scrub it. We had to use a specific tool to anonymize that IP. But Google Analytics 4 does this by default. Exactly. In a world focused on user privacy, PII is super sensitive. We’ve never had our Analytics account flagged. Thank God for that. We’ve never dealt with that. We catch these things fast. As consultants, it’s our job to spot them. We caught one for a brand recently. It was an email address. I sent a deletion request immediately. It took a while.
It took quite a while, actually. But it eventually gets deleted. It’s not the end of the world. Let’s talk about detecting PII. How do we catch an email address? Think about it. Data is collected under hundreds of dimensions. There are thousands of metrics. Or hundreds, at least. It usually happens under a parameter. Take the page URL. Users often carry their email in the URL during checkout.
— Exactly.
— This is a common issue. Emails like ferit@leo.org show up in the URL. Phone numbers do too. Great, right? All of this gets sent to your reports as page parameters. You end up collecting this data by accident. But Google Analytics 4 can actually spot this. It recognizes email patterns like @gmail.com or @hotmail.com. It even detects phone numbers. So, how do we catch them? Searching for "@gmail.com" is way too manual. Phone numbers usually stand out on their own. You can spot them easily. I’m talking about page reports here. If you see too many parameters, that’s a red flag. Say you have 100 pages. You check Analytics and see 1,100 page paths.
That means a parameter is duplicating your pages constantly. That’s how you catch it. We can spot it manually. It might also be a sub-parameter in a custom event. Maybe partial credit card info is leaking during checkout. Or names. It could be a software bug. Or maybe it’s related to your input fields. That’s the technical side of it. That’s why there’s so much talk about how to detect PII. I’ll add something for that. Let’s put a direct link below the video. You can check your own accounts.
— Here is a pro tip. Look at the breakdowns Zafer mentioned. But don't look at the top performers. Look at the ones with the fewest sessions, views, or users. Reverse the report. These issues are rare. They’re usually bugs or misconfigured items. They always hide in the low-traffic data. I always reverse the report to find them. I check the bottom of the list to catch those leaks. I’ve never seen this happen. I’ve been in the industry for 2.5 years. Zafer has maybe seen it once or twice. It’s extremely rare. I just scroll back a few pages to find it.
— I want to share my screen. Let’s make this concrete while I look for the source. Can you see my screen, Ferit? Perfect. Here is that email I mentioned. See how it hits Google Analytics? Or first name and last name. It gets passed in the URL. That’s the most common issue. You need to search for these in the page path report. Just search for "first name" right there. You could also block them in Tag Manager. That’s another way to handle it. I wanted to make this concrete for you. I’ll link the resource I showed earlier. If you search for "PII in GA4," you’ll find plenty more info.
This is critical. We’re living in a GDPR and KVKK world. It’s not just PII. We’re in a world where cookies are constantly debated. This part is vital. Moving on, let’s talk about the user journey. We covered the integration side. Now let’s look at the rest. We’ve done the integration. The user goes through payment info, shipping info, and begin checkout. What value do these reports provide? We covered the integration side. Now let's talk reporting. What should brands demand here? What insights should they pull from these events? We need to cover this now.
— Let's call these funnels. Connected events create a funnel for us. We map out the steps leading to a purchase. The main benefit? Seeing where users drop off. Where are they leaving your site? It’s not just for purchases. We build these integrations elsewhere too. Take insurance sites. They ask for personal info. What are you insuring? Who are you? Where do you live? What’s the product? These steps become a funnel. The core logic is simple. Where are users dropping off? Which step is the problem?
That’s the primary benefit. Identifying the exact drop-off point. That’s how I use funnels most.
— Exactly. Funnels are inherently reductive. If you ask for a national ID, it might not be necessary. Maybe remove that step. If users drop off there, they’re hitting a wall. They see the shipping cost.
— Exactly.
— It’s a common issue. Users reach checkout. They hit the shipping info step. They see the shipping fee. Maybe they bail. They head to another site. You can spot this in Google Analytics. If your funnel is set up right and your events fire correctly. It’s easy to track. Funnels are standard in e-commerce. But they work for sign-ups too. It’s not just for e-commerce. You can build your own custom steps. Think of a form. For example, booking a test drive for a car. There are multiple steps involved.
You can send all those steps with parameters. See exactly where users drop off. Is something scaring them away? If someone starts a form or a purchase and quits, they’ve changed their mind. It’s simple. Assuming there’s no technical error. You can catch those too. Sometimes things break internally. Nobody notices. You can spot that. Some errors aren't chronic. They don't always show up. Or they happen on specific browsers. You can break down your funnel by browser or device. Look at mobile versus web. Even platform-specific. Check iOS and Android separately. It’s not just about the setup.
This isn't just Analytics consulting. It’s your own brand. These things aren't that hard. You just need to tinker a bit. Integration is a bit technical. You might need a consultant for that. But once it’s live, you can handle funnel analysis. Even with zero experience. If you have a working funnel, check it periodically. See what errors pop up on which platforms. Find out what’s stopping users from reaching the finish line. You can catch that right there. That’s the ultimate goal of funnel analysis.
— Zero. That’s the whole point of these setups. The main reason for all this tracking.
— Exactly. We’ve been talking data. But we can’t skip consent mode. It’s a huge piece of the puzzle.
— I want to give us a shoutout. We’ve really pushed consent mode awareness at ZEO. We got most brands to the table. We showed them the laws. We shared the decrees. We told them it was coming. ZEO brands are on board now. They’ve accepted it. They’re setting it up. I hope the whole industry follows suit. User data matters. We’re customers too, after all. It’s a bit philosophical. My preferences matter. If I don't want my data tracked, it shouldn't be. I remember the old days. It was a total free-for-all.
I don't even know what an adblocker is. I’m a bit younger. Ads were everywhere. You looked at one thing, and ads followed you. It was like a digital cancer. Ads need boundaries. Data collection needs limits too. We work with data, but there’s a line. We have to be respectful. ZEO has made great progress. We held 30 or 40 meetings with our brands last month. We spent hours on this. Each session took up to an hour. We did it so brands don't fall into this trap.
— Exactly. It’s an unknown issue in Turkey. Or it’s just swept under the rug. It’s strictly regulated in the EU. Even for brands not using ZEO for Analytics, we still provide this guidance. Whether they use our SEO or ad services, we inform them through their consultants. We gladly join their meetings. Sometimes we even meet with their lawyers. We explain the technical side and the risks. We cover how machine learning fills the gaps. Check out our ZEO talks on Analytics for more.
We covered consent mode in great detail there. It’s a must-have now. 2025 is the official deadline. We’ve shared the documentation. The goal is full GDPR compliance. There are many cookie management platforms in Turkey. Google also recommends specific partners. You need to contact them. Get it installed on your site or app immediately. Your point is spot on. It’s not just technical. There’s a philosophical side to this. I see it on huge sites all the time. You ask me a question. My answer doesn't impact data collection. That’s just not right.
I’m talking about two or three specific sites. Listeners probably know which big Turkish sites I mean. If you ask me a question, don't bury the opt-out in an anchor text. I want to see it clearly. Exactly. I want to see a button. I know my right to opt out is reserved. But sometimes you put it there and it doesn't even work. I see that all the time, right? It’s just a banner sitting there. It has zero function for data collection. It’s just there for the sake of being there. That’s not right at all. We’re sensitive about this. We work with data. Our job is to educate brands.
We ensure everything works perfectly. We make sure brands don't lose revenue over data issues. This isn't a bad thing. If you lose too much data, Google has solutions. That’s why Consent Mode exists. It’s there to recover your lost data. Being sensitive about this is a good thing. Anything else we haven't covered in this episode?
— We covered data rights. We showed where to catch data. We dove into the data layer. Then we explained how to use it. We showed how to push that data to Google Analytics 4. We also analyzed funnels. We collected all the data. We showed how to analyze those funnels. Finally, we touched on consent mode. We had to. That’s a wrap for today.
— Thanks for tuning in. The ZEO channel has plenty more. We cover AI, SEO, and ads. Check out our ZEO talks and other content. Subscribe to the ZEO channel to stay updated. Catch us on our podcast or YouTube. Follow us for more. Stay safe. See you next time.
This transcript was generated using AI speech recognition and verified against subtitle style rules.
