Google Analytics 4 öğrenmek
Google Analytics 4 her kullanıcı etkileşimini bir olay olarak sayar ve bütün raporları bu tek fikir üzerine kuruludur. Bu dersten tek bir şey alacaksanız şunu alın: standart raporlar ile keşifler iki ayrı motordur ve veri saklama ayarı yalnızca ikincisini sınırlar.
- Ders 12 / 15
- Orta
- Ücretsiz, kayıt yok
GA4'ün dört adımı, bu sırayla
Çoğu kişi üçüncü adımdan başlar, sonra sayılardan yakınır.
-
1
Etiketi kurun ve test edin
Gerçek Zamanlı ya da DebugView'de olayların gerçekten geldiğini görün
-
2
Anahtar olayı işaretleyin
Her tıklama değil, işletme için önemli olan eylem
-
3
Veri saklamayı denetleyin
İki ay ya da 14; yalnızca keşifleri sınırlar
-
4
Search Console'u bağlayın
Sonra rapor koleksiyonunu Library'den yayımlayın
Bu adımların hiçbiri trafik getirmez. Analytics görme aracıdır, büyütme aracı değil.
Son kontrol: Bu dersteki bilgiler ve araç adları bu tarihte kaynaklarıyla yeniden doğrulanır.
GA4 tam olarak neyi sayar?
GA4'te ölçü birimi olaydır: bir sayfanın açılması, bir bağlantıya tıklanması, bir videonun başlaması, bir satın almanın tamamlanması. Sistem davranışı bile bir olaydır, bir uygulamanın çökmesi gibi. Analytics'in önceki sürümleri sayfa görüntülemeyi ve olayı iki ayrı şey sayardı; burada tek bir şey var ve geri kalan her şey onun adıdır.
Olaylar dört türde gelir ve bu dördünü bilmek kafa karışıklığının yarısını bitirir. İkisi sizin yerinize toplanır: etiketle birlikte gelen otomatik toplanan olaylar ve o seçenek açıkken gelen gelişmiş ölçüm olayları. İkisini sizin uygulamanız gerekir: önceden tanımlı ad ve parametreleri olan önerilen olaylar ve kendi tanımladığınız özel olaylar.
Ve Google'ın belgesinde bütün planı değiştiren tek bir cümle var: özel olaylar çoğu standart raporda görünmez, bu yüzden anlamlı bir analiz için özel raporlara ya da keşiflere ihtiyacınız olur. Yani bir özel olay oluşturmaya karar verdiğiniz anda, analizini de kendinizin kuracağına karar vermiş olursunuz. Google'ın kendi tavsiyesi, başka hiçbir olay işinizi görmüyorsa özel olay oluşturmaktır.
Her olay bir anahtar olay olabilir: işletmeniz için önemli olan eylemi işaretlersiniz ve raporlarda ayrıca görünür. Bir olayın gerçekten ulaşıp ulaşmadığını görmek için iki yer var: son 30 dakikada tetiklenen olayları gösteren Gerçek Zamanlı rapor ve tek bir kullanıcının bütün olaylarını gösteren, test için var olan DebugView. Etiketi kurduktan sonra ikisinde de bir şey görmüyorsanız sorununuz raporlarda değil, kurulumdadır.
Dört tür olay ve hangileri sizin işiniz
-
iş yok
Otomatik toplanan
Etiketle birlikte gelirler
-
tek anahtar
Gelişmiş ölçüm
O seçenek açıkken toplanır
-
siz uygularsınız
Önerilen
Önceden tanımlı ad ve parametreleri vardır
-
son çare
Özel
Yalnızca başka hiçbir olay işinizi görmüyorsa
Özel olay çoğu standart raporda görünmez ve analizini kendiniz kurmanız gerekir.
Raporlar mı keşifler mi: hangisini açayım?
GA4'te veriye bakmak için iki ayrı yer var ve insanlar genellikle sayılarının neden uyuşmadığını çözemez. Standart raporlar toplulaştırılmış ve önceden kurulmuştur. Keşifler ise kendi raporunuzu kurma aracıdır: huni, yol, kohort, serbest biçimli tablo.
Ve neredeyse hiçbir eğitimin söylemediği şey, doğrudan Google'ın yardımından: veri saklama ayarı standart toplulaştırılmış raporları etkilemez ve yalnızca keşifleri ile huni raporlarını etkiler. Sıradan bir mülkte iki seçeneğiniz var: iki ay ve 14 ay. Yani mülkünüz iki ayda duruyorsa standart raporlar size geçen yılı gösterirken keşfiniz iki ay çizgisinde duvara toslar. Kimse bir hata görmez; veri orada değildir, o kadar.
Bu yüzden yeni bir mülkte yapılacak ilk iş, o ayarı açıp hangi seçenekte olduğunu görmektir. Google, saklama süresini artırdığınızda bunun zaten toplanmış veriye de uygulandığını yazıyor. Bir ayrıntı daha: iki aylık süre, ayarınız ne olursa olsun yaş, cinsiyet ve ilgi alanı verisine her zaman uygulanır.
Hata sanılan ama hata olmayan iki davranış daha var. Birincisi, veri eşikleri: bir satırdaki kullanıcı sayısı azsa, demografik veriden kimsenin kimliği çıkarılamasın diye Google o satırı gizler. Bu eşikleri değiştiremezsiniz ama daha geniş bir tarih aralığı genellikle aynı veriyi geri getirir. İkincisi, "(other)" satırı: bir tablo sınırından fazla satıra ihtiyaç duyduğunda Analytics en yaygın değerleri tutar ve kalanı tek satırda yoğunlaştırır. Google, 500'den fazla değeri olan her boyutun yüksek kardinaliteli sayılması gerektiğini yazıyor; parametre yüklü sayfa adresleri tam olarak buna dönüşür.
Raporlar ve keşifler, iki ayrı motor
İkisinden biri veri saklama ayarına duyarlıdır, diğeri değil. Bu tek fark, "neden veri yok" anlarının çoğunu açıklar.
Standart raporlar
- Toplulaştırılmış ve önceden kurulmuş veri
- Veri saklama ayarı onları etkilemez
- Özel olaylar çoğunda görünmez
- "Neler oluyor" sorusu için doğrudur
Keşifler
- Huni, yol, kohort, serbest biçimli tablo
- Saklama sınırında duvara toslarlar
- Özel bir olayı analiz etmenin tek yeri
- "Neden ve hangi adımda" sorusu için doğrudur
Hiçbiri diğerinin yerini tutmaz. Hangisini açacağınıza sorunuz karar verir.
Search Console'u bağlayın, sonra bir şey daha yapın
Search Console'u Analytics'e bağlamak iki rapor ekler: biri Search Console metrikleriyle organik arama sorguları için, diğeri açılış sayfalarını her iki aracın metrikleriyle yan yana koyan organik arama trafiği için. Bağlantının yaptığı ve iki aracın tek başına yapmadığı şey ikincisidir: sorgudan, kullanıcının vardıktan sonra yaptığına kadar, tek bir tabloda.
Ve şimdi o bir şey daha, ki "bağladım ama ortada bir şey yok" mesajlarının yarısının sebebi budur: Search Console rapor koleksiyonu varsayılan olarak yayımlanmamıştır. Onu sol gezinmedeki Library altında bulup kendiniz yayımlamanız gerekir. O ana kadar bağlantı çalışır ve hiçbir şey görünmez.
Zaman harcamadan önce bilinmesi iyi olan birkaç sınırı var. Search Console metrikleri yalnızca Search Console boyutlarıyla ve üç Analytics boyutuyla uyumludur: açılış sayfası, cihaz ve ülke. Bu raporlar zaman serisi grafiklerini desteklemez. Search Console verisi, toplanmasından 48 saat sonra Analytics'te kullanılabilir olur. Ve Search Console 16 aylık veri tuttuğu için bu raporlar da 16 aydan fazlasını taşımaz.
Yapısal bir sınır da var: bir web veri akışı tam olarak bir Search Console mülküne bağlanır, tersi de geçerlidir. Birkaç Search Console mülkü olan bir site için, örneğin dil başına bir tane, bu hangisinin Analytics'e gideceğini seçmek demektir. Search Console dersi çok dilli bir sitenin neden en baştan birkaç mülke ihtiyaç duyduğunu anlatıyor.
Analytics sayısı neden Search Console sayısına eşit değil?
Bu soru her aylık raporlama toplantısında sorulur ve kısa yanıtı şu: iki araç, iki farklı noktada iki farklı şeyi sayar. Search Console tıklamayı Google tarafında sayar; Analytics ziyareti kullanıcının tarayıcı tarafında. Bu iki nokta arasında ikisinin de denetlemediği şeyler vardır.
Google farkın nedenlerini kendisi sıralıyor: gizliliği korumak için bazı veriler gösterilmez, örneğin çok az sayıda aranan sorgular; kaynak verinin işlenmesi sayıları kaydırabilir, örneğin yinelenenleri elemek için; hesaplama ile görünürlük arasında gecikme vardır ve toplanan veri genellikle iki ila üç günde kullanılabilir olur; Search Console günleri Pasifik Saati ile etiketler, dolayısıyla diğer sisteminiz başka bir saat dilimindeyse günlük görünümler tam uyuşmaz; ve Analytics gibi araçlar yalnızca JavaScript'i etkin olan kullanıcıların trafiğini görür.
Sonuncusu pratikte kulağa geldiğinden önemlidir ve Google'ın yazmadığı bir çeşidi vardır; çünkü o onların değil sizindir: etiket dosyası hiç yüklenmezse hiçbir olay kaydedilmez ve hiçbir yerde bir hata görünmez. Kullanıcı sayfayı görür, Search Console tıklamasını sayar ve Analytics hiçbir şey olmadığını sanır. İranlı bir site için bu durum kuramsal değildir: etiket dosyası bir Google alan adından gelir ve o alan adının İran içinden erişilebilir olması verili değildir.
Çalışma kuralı şu: iki sayı arasındaki fark normaldir ve olağan büyüklüğünü bilmelisiniz. Küçük ve istikrarlı bir fark yukarıdaki nedenler demektir. Bir gecede aniden büyüyen bir fark ise kurulumda bir şeyin kırıldığı anlamına gelir ve nereye bakılacağı bir sonraki bölümdedir.
Analytics betiği sayfanın neresinde durmalı?
Bu bölüm eğitimlerde yok, çünkü gerçek bir site işletene kadar buna çarpmazsınız. Standart GA4 parçası iki parçadır: dosyayı bir Google alan adından getiren bir betik etiketi ve onu yapılandıran birkaç satır JavaScript. Gerçek dünyada her iki parça da risk taşır.
Birinci parça, dışarıdaki bir alan adına bağımlılıktır. O alan adı kullanıcılarınızın bulunduğu yerden yavaşsa ya da açılmıyorsa etiket yüklenmez ve hiçbir veri kaydedilmez. Bizim yanıtımız, dosyayı kendi alan adımızda barındırmak ve güncel sürümü getiren günlük bir cron çalıştırmaktır. Toplama işlemi bilinçli olarak vekil sunucudan geçirilmiyor ve doğrudan Google'a gidiyor; çünkü istekler sunucumuzdan geçseydi Google sunucunun IP'sini görür ve coğrafi raporlar bozulurdu.
İkinci parça, nerede durduğudur. Siteniz betikleri ilk kullanıcı etkileşimine kadar erteliyorsa kuyruk sırası önem kazanır: belgede daha erken görünen daha erken yüklenir ve geri kalan onun arkasında bekler. Analytics oldukça ağır bir dosyadır ve beklemesinin bir maliyeti yoktur; iletişim formunuzdaki captcha ise bekleyemez. Yani analytics parçasının yeri kuyruğun başı değil sonudur.
Ve yalnızca uzun kenar önbelleği olan sitelerde kendini gösteren bir tuzak: betik dosyasının adı içeriğinin özetiyle değişiyorsa ve önceki dosya siliniyorsa, kenar önbelleğinde duran her sayfa eski adı işaret eder ve silinmiş bir dosyaya varır. O sayfalarda Analytics çalışmaz ve panoda hiçbir hata görünmez. Doğru kural, dosya yolunu sabit tutmak ve önbellek kırmayı sorgu dizesiyle yapmaktır; o zaman bayat bir sayfa bile sağlam bir dosyaya varır. Site hızının kendisi konunuzsa, site hızını artırmak bu tartışmanın derinleştiği yerdir.
Yapay zekayla hızlı yol
Buradaki hızlı yol beklediğiniz şey değil. Bir dil modelinin Analytics verileriniz yoktur ve olmamalıdır; gerçekten hızlanan şey ölçümün tasarımıdır. Yani bir iş sorusundan, hazır bir raporun onu zaten yanıtlayıp yanıtlamadığına, yanıtlamıyorsa tam olarak hangi keşfin gerektiğine ve gereken olay hiç yoksa neyin gönderilmesi gerektiğine gitmek. Model bu üçünü hızlı ve doğru yapar, çünkü iş dili yapıya eşlemektir. Bütün bunlardan önce, kimsenin yapmadığı ve en çok zaman kazandıran basit bir kontrol var: etiketin önbelleklenmiş bir sayfada da gerçekten yüklendiğinden emin olun. Bunun için ucuz ve hızlı bir model yeter; güncel tercihimiz <a class="text-link" href="/tr/ai/">yapay zeka bölümünde</a>.
- Önce aşağıdaki kabuk komutunu sitenin gerçek bir sayfasında çalıştırın. Etiket dosyasının adresini HTML'in kendisinden çeker ve o adresin ne döndürdüğüne bakar. 404 alıyorsanız, siz onu düzeltene kadar bu dersin geri kalanı anlamsızdır.
- Mevcut olay listenizi Admin bölümünden ve Events sayfasından kopyalayın. Yalnızca olay adları gerekir, hiçbir kullanıcı verisi değil; bu sınırı koruyun.
- İkinci aşama komutunu iş sorunuzla ve o listeyle çalıştırın. Çıktı, hangi hazır raporun yanıtladığını açıkça söylemeli; hiçbiri yanıtlamıyorsa gereken keşfi tekniği, boyutları ve metrikleri adlandırarak vermeli.
- Çıktı gereken olayın var olmadığını söylüyorsa, önerilen parçayı siteye koyun ve DebugView'de test edin. Olayı DebugView'de görene kadar hiçbir şey kurulmuş değildir.
Kopyalamaya hazır şablon
U="https://example.com/"
# Etiket dosyasinin adresini sayfanin kendisinden ceker ve saglam donup donmedigine bakar.
# Site betikleri erteliyorsa adres data-src icinde olabilir.
H=$(curl -s -A "Mozilla/5.0" "$U")
SRC=$(printf '%s' "$H" | grep -oE '(data-)?src="[^"]*(gtag|analytics|gtm)[^"]*"' | head -1 | cut -d'"' -f2)
echo "tag: $SRC"
curl -s -o /dev/null -w '%{http_code} %{size_download}\n' "$SRC"
---- Asama 2: model komutu ----
Rol: Google Analytics 4 icin olcum tasarimcisi. Bu sitenin verisine erisimin
yok ve ondan hicbir sayi bilmiyorsun.
Is sorusu:
{soru, ornegin: kac kisi danismanlik formunu acip birakiyor}
Mulkte su anda var olan olaylar:
{olay adlari listesi}
Tam olarak uc bolumde yanitla:
1) Standart bir rapor bunu zaten yanitliyor mu? Evetse raporun adini ve yolunu
yaz ve burada dur.
2) Hayirsa gereken kesfi belirt: teknik, boyutlar, metrikler, filtreler ve
tarih araligi. Gereken aralik iki aydan uzunsa, veri saklama ayarinin 14 ay
olmasi gerektigini acikca yaz.
3) Gereken olay yukaridaki listede yoksa, onerilen olay adini ve parametrelerini
yaz, ayrica hazir bir gtag parcasi ver.
Kurallar:
- Bu site hakkinda hicbir sayi yazma. Verisine sahip degilsin.
- Onerilen olayin standart bir Google adi varsa o adi kullan, yeni ad uydurma.
- Soru Analytics verisinden hic yanitlanamiyorsa bunu soyle ve yanitin nereden
geldigini soyle.
Çıktıya güvenmeden önce: İki şeyi kendiniz bitirin. Birincisi, modelin önerdiği her olayın, üzerine rapor kurmadan önce DebugView'de görülmesi gerekir; doğru görünen ama tetiklenmeyen bir parça, tam da hiçbir yerde hata göstermeyen durumdur. İkincisi, bu iş akışında hiçbir kullanıcı verisi taşımayın. Google'ın kendi politikası, kendisine bir kişiyi tanımlayabilecek hiçbir verinin geçirilmemesi gerektiğini söyler ve sayfa adresleriyle başlıkları, bu verinin genellikle istemeden sızdığı yerdir. Bu iş için olay adlarının listesi yeterlidir, fazlası gerekmez.
Bu işte yapay zeka
Buradaki tutumumuz olağan hâle gelenin tersi: modele Analytics verinizi değil, ölçüm tasarımını verin. Bunun iki nedeni var. Birincisi, bir Analytics dışa aktarımı kullanıcılarınıza dair davranış verisidir ve onu dış bir servise göndermek bir kısayol değil hukuki bir karardır. İkincisi, model bir iş sorusunu rapor yapısına çevirmekte gerçekten hızlıdır ve insanların en çok vakit kaybettiği yer tam olarak orasıdır.
Gerçekten işe yarayan araçlar
- Gemini Ölçüm tasarımı aşamasına uygun; rapor adlarını ve keşif tekniklerini daha doğru biliyor. Kendi kaydımız İran'ın Google'ın desteklenen ülkeler listesinde olmadığını yazıyor; ödeme yolu <a class="text-link" href="/tr/ai/buy/">yapay zeka satın alma</a> sayfasında.
- Claude Olay parçalarını yazmak ve gözden geçirmek için daha iyi; standart adı kullan, yeni ad uydurma dediğinizde daha az doğaçlama yapıyor. İran, Anthropic'in iki desteklenen ülke listesinin de dışında.
- BigQuery Export Yapay zeka değil ve hem veri eşiğinin hem "(other)" satırının yanıtı. Ham olayları size verir, siz kendiniz toplulaştırırsınız. Ücretsiz değildir ve bir Cloud projesi gerektirir; Google ayrıca Google signals verisinin BigQuery'ye aktarılmadığını yazıyor, dolayısıyla sayılar panoyla uyuşmayacaktır.
Nerede geri teper
İlk risk gizlilik ve o sizin değil, kullanıcılarınızın. Google'ın kendi politikası, Google'ın bir kişiyi tanımlamakta kullanabileceği hiçbir verinin Analytics'e geçirilmemesi gerektiğini açıkça söyler ve bu verinin çoğu zaman sayfa adresleri ile başlıkları üzerinden istemeden gönderildiğini yazar. Aynı adresleri bir dışa aktarıma koyup dış bir servise gönderirseniz sorunu bir adım daha dışarı taşımış olursunuz; görüşmenizin eğitim için kullanılıp kullanılmadığı o servisin planına ve ayarlarına bağlıdır ve kendi sayfasında yazar. İkinci risk teknik: model, olay parçalarını ve boyut ile metrik adlarını akıcı biçimde üretir ve ürettiğinin bir kısmı GA4'te hiç yoktur. Bunu yakalamak zordur, çünkü "açılış sayfası etkileşim oranı" gibi bir ad tam da var olması gereken bir şeye benzer. Tek güvenilir kontrol, o olayı DebugView'de ve o boyutu arayüzün kendisinde görmektir.
Kaynaklar: Analytics Help: best practices to avoid sending personally identifiable information Analytics Help: about data thresholds Analytics Help: set up BigQuery Export Anthropic: is my data used for model training Google: Gemini Apps Privacy Hub
Bu tavsiyenin sınırı
Analytics yalnızca tarayıcının bildirdiğini görür ve yalnızca etiket çalıştıysa. JavaScript'i olmayan ya da etiket dosyası hiç yüklenmemiş bir kullanıcı hiçbir raporda yoktur. Veri eşikleri ve "(other)" satırı bazı satırları gizler, saklama ayarı da keşiflerin tavanıdır. Hepsinden önemlisi: Analytics ne olduğunu söyler, neden olduğunu değil. Nedeni müşterilerle konuşmaktan ve sayfanın kendisine bakmaktan gelir, panodan değil.
Kendi işimizden
Bu site gtag.js'i Google'ın alan adından değil kendi alan adından sunuyor. Bu dersin yazıldığı gün dosya diskte 525.880 bayt, yani yaklaşık 513 KB ve sıkıştırılmış hâli yaklaşık 169 KB; o sabah 07:35'te günlük cron yeni bir sürüm getirdi ve dosya yolu hiç kımıldamadan ver sorgusu değişti. Bu tasarımın sebebi gerçek bir arıza: eskiden dosya adı içeriğinin özetiydi ve yenisi gelir gelmez önceki dosya siliniyordu, oysa eski adı işaret eden HTML kenar önbelleğinde 30 güne kadar yaşıyordu. Günlüklerde o tarihsel adların hiçbiri bir kez bile 200 almadı, yalnızca 404; yani Analytics önbelleklenmiş sayfalarda fiilen çalışmıyordu ve panoda hiçbir hata görünmüyordu, sayılar sadece gerçeğin altındaydı. Aynı gün kenar önbelleğinden gelen bir sayfa hâlâ önceki ver sorgusunu istiyordu ve yine de sağlam bir dosya aldı; eskiden 404 veren tam olarak buydu. Şimdi yol sabit, yedi eski kopya hâlâ diskte duruyor çünkü bilinçli olarak 45 gün saklanıyorlar ve 45, kenar önbelleğinin 30 gününden fazla. Parçanın yeri de değişti: sayfanın üstünde basıldığı sürece ertelenmiş betik kuyruğunun ilkiydi ve captcha aracı onun arkasında bekliyordu, bu yüzden kuyruğun sonuna taşındı. Analytics bekleyebilir, captcha bekleyemez.
Gerçek devam soruları
Veri saklamayı 14 aya mı iki aya mı ayarlamalıyım?
Hiç keşif kurmayacaksanız fark etmez. Kuracaksanız ve yıldan yıla karşılaştırma sizin için önemliyse, 14 ay tek seçenektir. Google, süreyi artırmanın bunu zaten toplanmış veriye de uyguladığını yazıyor; yani geç karar vermek sandığınız kadar pahalı değil.
Keşfim neden gerçek veri yerine "(other)" diyor?
Çünkü gereken satır sayısı tablonun sınırını aştı ve Analytics en yaygın değerleri tutup kalanı tek satırda yoğunlaştırdı. Suçlu genellikle çok fazla değeri olan bir boyuttur, örneğin parametre taşıyan sayfa adresleri. Google, 500'den fazla değeri olan her boyutun yüksek kardinaliteli sayılması gerektiğini yazıyor.
Search Console'u bağladım ama hiç rapor görmüyorum.
Çünkü Search Console rapor koleksiyonu varsayılan olarak yayımlanmamıştır. Yan gezinmedeki Library altında bulup yayımlayın. Yeni bağladıysanız, Search Console verisinin toplanmasından 48 saat sonra Analytics'te kullanılabilir olduğunu da hatırlayın.