GA4 ve GTM ile Veri Tutarsızlıklarının Tespiti ve Önlenmesi

— 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.