GA4'te ekibinizin ve geliştiricilerin ziyaretlerini veriden ayırmanın yolu, Admin altında iç trafiği tanımlamak ve ardından bir veri filtresi oluşturmaktır. Önce kural "Define internal traffic" ekranında IP adresine göre kurulur, sonra "Data filters" bölümünde filtre önce "Testing", doğruladıktan sonra "Active" durumuna alınır. Bilinen botlar ise Google tarafından zaten otomatik olarak dışarıda tutulur ve bunu kapatamazsınız. En kritik uyarı şudur: veri filtreleri yalnızca oluşturuldukları andan itibaren işler ve geçmiş veriyi düzeltmez.
Bu rehber analitik sorumlusu, ajans çalışanı ve kendi sitesini yöneten işletme sahibi için yazıldı. Önce iç ziyaretlerin hangi metrikleri nasıl bozduğunu gösterir, ardından üç filtre türünü ve bot dışlamayı ayırır, kural ile filtrenin adım adım nasıl kurulacağını anlatır, test aşamasında neye bakacağınızı listeler ve en sonda değişikliği nasıl kayıt altına alacağınızı örnekler. Arayüz adları Google Analytics Yardım sayfalarında göründüğü gibi İngilizce ve tırnak içinde verilmiştir; arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir.
İç Ziyaretler Verinizi Nasıl Bozar
Bir sitenin analitiği, o siteyi kullanan gerçek müşteri ve okuyucuların davranışını anlamak için vardır. Ekip üyeleri, ajans çalışanları, içerik editörleri ve geliştiriciler ise siteyi başka amaçlarla gezer. Bir yazıyı kontrol etmek, formu denemek, ödeme akışını baştan sona yürütmek ya da bir sayfanın mobilde nasıl göründüğüne bakmak gerçek bir müşteri niyeti taşımaz. Bu ziyaretler veriye karışınca raporlar, onları kullanan kişiye yanlış bir resim gösterir.
Hangi metrikler sapar
Sapmanın yönü her zaman aynı değildir. Test amaçlı yapılan bir dönüşüm olayı dönüşüm sayısını şişirir; hiçbir şey yapmadan sayfayı kontrol edip kapatan bir editör etkileşimli oturum oranını düşürebilir. Aşağıdaki tablo, sık görülen iç ziyaret davranışlarını ve raporda yarattığı yanılsamayı özetler.
| İç ziyaret davranışı | Raporda görünen etki | Yanlış çıkarım |
|---|---|---|
| Formu veya ödeme akışını test etmek | Dönüşüm ve olay sayısı artar | Kampanya veya sayfa daha iyi çalışıyor sanılır |
| Yayınlanan yazıyı kontrol etmek için açıp kapatmak | Sayfa görüntüleme artar, etkileşim kalitesi düşer | İçerik ilgi çekiyor ama sorunlu sanılır |
| Her gün aynı sayfaları gezen çalışanlar | Doğrudan trafik ve belirli sayfalar şişer | Marka bilinirliği arttı sanılır |
| Etiket testi yapan geliştirici | Tekrarlayan olaylar ve garip sayfa yolları görünür | Ölçüm hatası gerçek kullanıcı sorunu sanılır |
Küçük sitelerde etki daha büyüktür
Aylık ziyaretçi sayısı düşük olan bir sitede birkaç kişilik bir ekibin gündelik gezintisi bile toplam içinde belirgin bir pay tutar. Büyük sitelerde aynı ekip gürültüye dönüşür, küçük sitelerde ise raporun kendisi olabilir. Bu yüzden iç trafik filtresi, trafiği az olan siteler için lüks değil temel bir hijyen adımıdır.
Örnek senaryo: bir yerel hizmet sitesinin iletişim formu birkaç haftadır "iyi dönüşüm" veriyor görünüyor. Sahip, form teşekkür sayfasına gelen ziyaretlerin önemli bölümünün kendi ofisinden yapılan denemeler olduğunu fark etmeden reklam bütçesini artırmaya karar veriyor. Karar gerçek müşteri davranışına değil, ekibin testlerine dayanmış oluyor.
Dahili trafik ile şüpheli trafik aynı şey değildir
İki kavramı karıştırmak çözümü de karıştırır. Dahili trafik, sizin kontrol ettiğiniz kişi ve cihazlardan gelen, kaynağı bilinen trafiktir ve IP gibi bir kimlikle ayrılabilir. Bot veya sahte trafik ise kaynağı bilinmeyen, çoğu zaman rastgele ağlardan gelen ve ayırması daha zor trafiktir. Sahte trafiğin SEO metriklerini nasıl şişirdiğini sahte trafik ve şişirilmiş SEO metrikleri yazısında ayrıca ele aldık. Bu rehber, kontrolünüzdeki trafiği ayırmaya ve botlarda neyin Google'a bırakıldığını anlamaya odaklanır.
GA4'ün Sunduğu Filtreler: Üç Veri Filtresi ve Bot Dışlama
Google, Analytics Yardım'ında veri filtresini, gelen olay verisinin Google Analytics tarafından işlenmesini engelleyen bir araç olarak tanımlar. Data filters sayfası (yeni sekmede açılır) üç filtre türünü sayar: "Developer traffic", "Internal traffic" ve "Web hostname traffic". Bunlara ek olarak bilinen botlar için ayrı bir otomatik dışlama vardır. Hangisinin ne işe yaradığını netleştirmek, yanlış aracı seçmenin önüne geçer.
| Araç | Ne yapar | Siz ne yaparsınız |
|---|---|---|
| "Internal traffic" filtresi | IP adresi veya IP aralığına göre kullanıcıları dışarıda bırakır | Önce IP kuralını tanımlar, sonra filtreyi oluşturursunuz |
| "Developer traffic" filtresi | Hata ayıklama modunu kullanan geliştirici etkinliğini dışarıda bırakır | Yalnızca filtreyi oluşturursunuz |
| "Web hostname traffic" filtresi | Mülkünüze olay gönderen alan adlarına göre dışlama yapar | Filtreyi oluşturursunuz |
| Bilinen bot dışlaması | Bilinen bot ve örümcek trafiğini otomatik dışarıda bırakır | Hiçbir şey; kapatılamaz |
Filtrelerin işlem sırası
Google'ın belgesine göre etkin "Include only" filtreleri bir grup olarak birleştirilip önce uygulanır, ardından etkin "Exclude" filtreleri tek tek uygulanır. Bu rehberdeki iç trafik ve geliştirici filtreleri "Exclude" türündedir. Bir mülkte en fazla 10 veri filtresi oluşturulabilir. Google belgelerindeki sınırlar değişebilir; uygulamadan önce güncel sayfaya bakın.
Hangi filtre hangi sorunu çözer
- Ofisten veya sabit bir ağdan yapılan gezintiler için IP kuralına dayalı "Internal traffic" filtresi uygundur.
- Etiketi test eden geliştiriciler hata ayıklama modunu açıyorsa "Developer traffic" filtresi yeterli olur.
- Başka bir alan adına kopyalanmış etiketin gönderdiği olaylar için "Web hostname traffic" filtresi düşünülür. Bu filtrenin adımları bu yazının konusu değildir.
- Uzaktan çalışan, IP adresi sürekli değişen kişiler için tek başına IP kuralı yetmeyebilir; bu sınır aşağıda ele alınıyor.
Rapor filtresi farklı bir araçtır
Veri filtresi kalıcı bir müdahaledir. Yalnızca raporda gördüklerinizi gizlemek istiyorsanız Google report filters (yeni sekmede açılır) yani rapor filtrelerini önerir. Rapor filtresi, ayrıntı raporlarında hangi verinin gösterileceğini denetler ve geri alınabilir: filtreyi tıklayıp seçimi değiştirebilir ya da kaldırabilirsiniz. Veriyi yok etmeden bir görünüm denemek istiyorsanız önce bu yolu deneyin.
Adım Adım: İç Trafiği Tanımlama ve Veri Filtresini Kurma
İç trafik filtresi iki aşamalıdır. Önce hangi trafiğin "internal" sayılacağını belirten bir kural tanımlarsınız, sonra bu etikete sahip olayları dışarıda bırakan veri filtresini oluşturursunuz. Filter out internal traffic (yeni sekmede açılır) sayfası bu iki adımı tarif eder. Her iki adım için de mülk düzeyinde "Editor" rolü ya da üstü gerekir.
Başlamadan önce toplanacak bilgiler
- Dışarıda tutulacak ağları listeleyin: ofis, ajans, depo, sık çalışılan ortak çalışma alanı gibi.
- Herkese açık IP adresini bulun: Google'ın arayüzü "What's my IP address?" seçeneğini sunar. Yerel ağ adresiniz değil, internete çıkış yaptığınız herkese açık adres önemlidir.
- Adresin sabit olup olmadığını öğrenin: İnternet sağlayıcınızın verdiği adres değişebilir. Değişen adreslerde kuralı güncel tutmak gerekir.
- Kapsamı belirleyin: Hangi mülk ve hangi web veri akışı için yapılacağını yazın. Birden fazla mülkünüz varsa her birinde ayrı kurulum gerekir.
1. Adım: "Define internal traffic" kuralı
Google'ın tarif ettiği yol şöyledir: Admin altında "Data collection and modification" bölümünde "Data streams" seçilir, web veri akışı açılır, "Configure tag settings" tıklanır, ardından "Show more" ve "Define internal traffic" gelir. Burada "Create" ile yeni bir kural oluşturulur. Kuralda şu alanlar bulunur:
- Kural için bir ad.
- traffic_type parametresi için bir değer. Varsayılan "internal" değeridir; "emea_headquarters" gibi başka bir değer de yazabilirsiniz. Sayfaya göre değerini tanımlayabildiğiniz tek olay parametresi budur.
- IP adresi için bir "Match type" ve bir "Value".
- İsteğe bağlı olarak "Add condition" ile ek koşullar. Koşullar VE değil, VEYA mantığıyla çalışır.
Kuralı kaydettiğinizde Analytics gelen olaylara traffic_type parametresini ekler. Parametreyi elle de ekleyebilirsiniz.
IP eşleştirme türleri
Google'ın listesine göre eşleştirme türleri şunlardır: "IP address equals", "IP address begins with", "IP address ends with", "IP address contains", "IP address is in range" ve "IP address matches regular expression". Değer alanı IPv4 veya IPv6 adreslerini ve düzenli ifadeleri kabul eder. Aralık girmek için CIDR gösterimi gerekir; sayfanın örnekleri 10.0.0.0/8, 172.16.0.0/12 ve 192.168.0.0/16'dır.
| Durum | Uygun eşleştirme türü | Dikkat edilecek nokta |
|---|---|---|
| Tek bir sabit ofis adresi | "IP address equals" | Adres değişirse kural eskir |
| Ağ bloğu veya kurumsal aralık | "IP address is in range" | CIDR gösterimi kullanın |
| Aynı öneki paylaşan birkaç adres | "IP address begins with" | Kapsamı gereğinden geniş tutmayın, gerçek müşteri de aynı önekte olabilir |
| Karmaşık desen | "IP address matches regular expression" | Hatalı desen yanlış trafiği keser; Testing durumunda doğrulayın |
2. Adım: "Data filters" altında filtreyi oluşturma
Admin altında "Data collection and modification" bölümünde "Data filters" açılır, "Create Filter" tıklanır ve "Internal Traffic" seçilir. Filtre adı mülk içinde benzersiz olmalı, bir harfle ya da karakterle başlamalı, yalnızca Unicode harfleri, rakamlar, alt çizgi ve boşluk içermeli ve en fazla 40 karakter olmalıdır. Tür olarak "Exclude" seçilir; böylece traffic_type değeri eşleşen olaylar dışarıda bırakılır. Google'ın sayfası eşleşecek değeri anlatırken numaralı bir adıma atıf yapıyor ve bu atıf sayfadaki numaralandırmayla tutmuyor. Bu yüzden filtre ekranında yazdığınız traffic_type değerinin, kuralda tanımladığınız değerle aynı olduğunu arayüzde kendiniz kontrol edin.
Son olarak filtre durumu seçilir. Bu seçim bir sonraki bölümün konusudur, çünkü yanlış durumda kaydetmek sonradan düzeltilemeyen bir veri kaybına yol açabilir.
Uzaktan çalışanlar ve değişen IP'ler
Her çalışan evinden bağlanıyorsa herkesin IP adresini kural olarak toplamak hem sürdürülebilir hem de uygun bir yol olmayabilir. İç trafik filtresi yalnızca web etkinliği için çalışır, uygulama kullanıcılarını filtreleyemez. IP temelli kuralın tek başına yetmediği durumlarda hangi çözümün iyi olduğunu Google'ın bu sayfası söylemez. Pratikte ekipler ortak bir çıkış IP'si olan kurumsal bağlantı kullanabilir ya da geliştirici trafiği için hata ayıklama modunu, kalan ziyaretler için ise raporlarda ayrı bir kırılım kullanabilir. Bu seçimlerin her birinin sınırı vardır; kuralı belgelerken sınırı da yazın.
Testing Durumundan Active Duruma Geçiş
Veri filtresi oluşturulurken seçebileceğiniz üç durum vardır ve aralarındaki fark bu işin en önemli güvenlik önlemidir. Google'a göre "Testing" durumunda eşleşen veri "Test data filter name" boyutuyla etiketlenir, "Active" durumunda filtre gelen veriye uygulanır ve kalıcı değişiklik yapar, "Inactive" durumunda ise filtre değerlendirilmez.
| Durum | Ne olur | Ne zaman kullanılır |
|---|---|---|
| "Testing" | Eşleşen veri etiketlenir, dışarıda bırakılmaz | Yeni filtreyi doğrulamak için |
| "Active" | Eşleşen olaylar işlenmez ve kalıcı olarak kaybolur | Test doğrulandıktan sonra |
| "Inactive" | Filtre değerlendirilmez | Geçici olarak devre dışı bırakmak için |
Testing durumunda neye bakılır
Google'ın önerdiği doğrulama, bir keşif raporu oluşturmaktır: teknik olarak "Free form", satırlar olarak "Test data filter name" ve "Event name", değer olarak "Event count" ve bir filtre olarak "Test data filter name contains" ile kendi filtre adınız. Eşleşen satırlar görünüyorsa kural beklediğiniz trafiği yakalıyor demektir. Bunu yaparken iki şeyi ayrı ayrı sorun: kendi ziyaretlerim etiketlenmiş mi ve başka kimseler yanlışlıkla etiketlenmiş mi?
Bekleme süresi
Google, filtrelerin uygulanmasının 24 ile 36 saat sürebileceğini yazar ve değer görünmüyorsa daha sonra yeniden bakmanızı söyler. Bu yüzden testi aynı gün içinde bitirmeye çalışmayın. Kendi cihazınızdan birkaç sayfa gezin, ertesi gün veya sonraki gün keşfi açın.
Etkinleştirmeden önce kontrol listesi
- Testing durumunda kendi ziyaretiniz "Test data filter name" altında göründü.
- Eşleşen satırların çoğu beklediğiniz kişi ve ağlardan geliyor.
- Gerçek müşteri trafiği olması muhtemel bir ağ (örneğin geniş bir önek) yanlışlıkla etiketlenmedi.
- Filtre adı ve traffic_type değeri arasında tutarsızlık yok.
- Değişikliği yapan kişi, tarih ve gerekçe kaydedildi.
- Filtreyi etkinleştirecek kişinin mülkte "Editor" rolü var.
Karar kuralı: Active'e ne zaman geçilir
Kural basittir: eşleşen etiketlenmiş trafiğin tamamını açıklayabiliyorsanız Active'e geçin, açıklayamıyorsanız geçmeyin. Eşleşen satırların kaynağını söyleyemiyorsanız Testing'de bırakın, kuralı daraltın ve yeniden bekleyin. Kalıcı olarak yitirilen veri geri getirilemez, oysa Testing'de geçirilen fazladan birkaç gün bir maliyet doğurmaz.
Geliştirici Trafiği ve Bot Trafiği
IP kuralı, trafiği kaynağın kim olduğuna göre ayırır. İki başka kaynak türü için ise farklı yollar vardır: hata ayıklama modundaki geliştiriciler ve botlar.
"Developer traffic" filtresi
Developer traffic sayfası (yeni sekmede açılır) bu filtreyi, hata ayıklama modunu kullanan dahili geliştiricilerin etkinliğini dışarıda bırakan filtre olarak tanımlar. Geliştiriciler sorunları gidermek için DebugView'i kullanmaya devam edebilir, ancak bu etkinlik raporlarınızın dışında kalır. Kurulum sırası şöyledir: Admin altında "Data collection and modification" bölümünde "Data filters", ardından "Create Filter", "Developer Traffic", benzersiz ve 40 karakteri geçmeyen bir ad, "Exclude" ve bir durum seçimi. Filtreyi oluşturmak için mülk düzeyinde "Editor" rolü gerekir. Sayfa, hata ayıklama modunun ne olduğunu kendi içinde tanımlamaz ve ayrı bir makaleye yönlendirir; ayrıca bu sayfada etkinleştirilen filtrenin geçmiş veriye uygulanıp uygulanmadığına dair bir ifade yok.
Bu filtrenin pratik avantajı, IP adresi bilmenize gerek kalmamasıdır. Geliştirici nerede olursa olsun hata ayıklama modundaysa etkinlik ayrılır. Sınırı ise açıktır: hata ayıklama modunu açmayan sıradan bir ekip üyesinin gezintisi bu filtreyle ayrılmaz.
Bilinen bot trafiği
Known bot-traffic exclusion (yeni sekmede açılır) sayfasına göre bilinen bot ve örümceklerden gelen trafik Google Analytics mülklerinde otomatik olarak dışarıda bırakılır, yani bilinen botların olayları mümkün olduğu ölçüde verinizin dışında tutulur. Bu tespit, Google araştırmasına ve Interactive Advertising Bureau (IAB) tarafından sürdürülen International Spiders and Bots List kaynağına dayanır. Sayfaya göre bu dışlamayı devre dışı bırakamazsınız ve ne kadar bilinen bot trafiğinin dışarıda bırakıldığını da göremezsiniz. Listede olmayan botlar hakkında ve dışlamanın geçmiş veriye uygulanıp uygulanmadığı konusunda sayfada açık bir ifade yok; bu yüzden "botlar otomatik temizleniyor" demek yerine "bilinen botlar mümkün olduğunca temizleniyor" demek doğrudur.
Bilinmeyen bot ve şüpheli trafik işaretleri
Aşağıdaki işaretler Google belgelerinden değil, analitik uygulamasında yaygın kullanılan sezgilerden gelir ve tek başına kanıt değildir. Birkaçının birden görülmesi incelemeye değer bir durumdur.
- Bir gün içinde aniden artan ve başka bir metrikle (satış, form, arama görünürlüğü) desteklenmeyen oturum sayısı.
- Beklemediğiniz bir ülkeden veya şehirden gelen yoğun trafik.
- Neredeyse tüm oturumların aynı sayfaya aynı davranışla inip çıkması.
- Alışılmadık ya da sayfalarınızda hiç olmayan sayfa yolları.
- Gerçek bir kampanya olmadan doğrudan trafikte ani sıçrama.
- Mülkünüze, sahibi olmadığınız bir alan adından gelen olaylar.
Şüpheli trafikte karar kuralı
Önce rapor düzeyinde izole edin: şüpheli kırılımı raporlarda rapor filtresiyle dışarıda bırakarak hangi metriklerin değiştiğine bakın. Sorun belirli bir alan adından geliyorsa "Web hostname traffic" filtresini düşünebilirsiniz. Kaynağı belirsiz ve dağınıksa veri filtresi uygulamayın; çünkü yanlış kural gerçek ziyaretçileri de kalıcı olarak siler. Değişiklik yapmadan önce sorunun tarihini ve etkilenen metrikleri not edin ki sonradan verideki kırılmanın nedenini açıklayabilesiniz.
Çerez onayı ile ilişkisi
İç trafik filtresi ile onay kaynaklı ölçüm kaybı farklı sorunlardır, ancak aynı raporda birleşirler: onay vermeyen ziyaretçiler eksik, iç ziyaretler fazla görünebilir. Onay modunun ölçümü nasıl etkilediğini çerez onayı, KVKK ve ölçüm kaybı rehberinde anlattık. Ekip üyelerinin evden bağlantı adreslerini kural olarak yazmadan önce kurum içi gizlilik politikanızı gözden geçirin; kişisel bağlantı adresi kişisel veri sayılabilir.
Filtrenin İşe Yaradığını Nasıl Anlarsınız
Filtreyi Active yaptıktan sonra bitti saymak kolaydır, ama kurulumun doğru çalıştığını gösteren somut kontroller gerekir. Veri filtresi geri alınamayan bir değişiklik olduğundan, etkisini ilk günlerde dikkatle izlemek hem yanlış kuralı erken yakalar hem de rapor okuyucusuna güven verir.
Birinci kontrol: kendi ziyaretinizi yapın
Kuralda tanımlı bir ağdan siteyi açın, birkaç sayfa gezin ve ana hedef olayını tetiklemeden çıkın. Birkaç gün sonra aynı sayfaların raporlarda görünmediğini kontrol edin. Filtre için Google'ın yazdığı 24 ile 36 saatlik gecikmeyi hesaba katın. Aynı ziyareti kural dışı bir ağdan, örneğin mobil veriden de yapın; bu ziyaret görünmeli. Görünmüyorsa kural gereğinden geniş olabilir.
İkinci kontrol: önce-sonra karşılaştırması
Filtreden önceki ve sonraki birkaç haftayı aynı rapor yapısında yan yana koyun. Bu karşılaştırmada trafik kaynaklarından ziyade belirli sayfaların görüntülemesine ve dönüşüm olaylarına bakın. İç ziyaretlerin ağırlıklı olduğu sayfalar (iletişim teşekkür sayfası, yönetim paneline giden bağlantılar, yayın öncesi taslak sayfalar) belirgin biçimde azalabilir. Düşüşün bu sayfalarda yoğunlaşması beklenen bir işarettir; tüm sayfalarda eşit bir düşüş ise başka bir nedene işaret edebilir.
Üçüncü kontrol: gerçek müşterilerin korunması
Filtrenin en pahalı hatası gerçek müşteri trafiğini silmesidir. Ofis ağınız paylaşımlı bir adres aralığı kullanıyorsa, aynı aralıktaki başka kullanıcılar da dışarıda kalabilir. Bu riski görmek için Testing aşamasındaki etiketli satırlara bakın ve içinde sizin bilmediğiniz davranışlar olup olmadığını inceleyin. Sipariş, form gönderimi veya kayıt gibi gerçek müşteri olaylarında beklenmeyen düşüş görürseniz kuralı hemen "Inactive" durumuna alıp incelemeniz makul olur. Bu durum, önceden silinen veriyi geri getirmez, ama yeni verinin kaybını durdurur.
| Kontrol | Beklenen sonuç | Sorun işareti |
|---|---|---|
| Kuraldaki ağdan gezinti | Raporlarda görünmez | Raporlarda hâlâ görünüyor: kural eşleşmiyor |
| Kural dışı ağdan gezinti | Raporlarda görünür | Görünmüyor: kural gereğinden geniş |
| İletişim ve teşekkür sayfaları | Test kaynaklı fazlalık azalır | Gerçek müşteri sayısı da düşüyor |
| Dönüşüm olayları | Test dönüşümleri kaybolur | Gerçek siparişler ve formlarla uyuşmuyor |
Ajans için çok müşterili düzen
Birden çok müşterinin mülküne erişen bir ajansta en pratik yaklaşım, her müşteri için ayrı bir kayıt tutmaktır. Her mülk için filtre listesini, kuralın tanımlandığı akışı, ajans ağının eklenip eklenmediğini ve son kontrol tarihini bir tabloda tutun. Mülk başına 10 filtre sınırı olduğundan, aynı mülkte gereksiz birden çok iç trafik filtresi açmayın; tek bir kuralda birden çok koşul tanımlamak (koşullar VEYA ile çalışır) filtre sayısını sınırlı tutar. Ajans çalışanlarının ev bağlantıları gibi sık değişen adresler için ise belgelenmiş bir yöntem seçin ve bunu müşteriyle paylaşın.
Müşteriye nasıl anlatılır
Müşteri açısından bu değişiklik "trafik düştü" cümlesine dönüşebilir. Önceden hazırlanmış kısa bir açıklama, tepkiyi yönetmeyi kolaylaştırır: "Ekibin ve ajansın ziyaretleri artık ölçülmüyor, bu nedenle rakamlar gerçek müşteri davranışına daha yakın." Düşüşün miktarını ayrıca rakamla vermek istiyorsanız Testing döneminde etiketlenen olay sayısını kullanabilirsiniz; bu sayı filtrenin neyi ayırdığını gösteren somut kanıttır. Etiketli satırların toplamını rapor notuna ekleyin, ancak Active sonrası bu veriye erişemeyeceğinizi unutmayın.
Geriye Dönük Etki Yok: Değişikliği Belgeleme ve Raporlama
Veri filtreleri hakkında en sık yapılan yanlış varsayım, filtrenin geçmiş veriyi de temizlediğidir. Google'ın Data filters sayfası bunu açıkça yazar: Analytics veri filtrelerini oluşturma anından itibaren değerlendirir ve filtreler geçmiş veriyi etkilemez. Uygulandığında etkisi kalıcıdır; dışarıda bırakılan veri hiç işlenmez, dolayısıyla ne Google Analytics'te ne de BigQuery'de bulunur.
Bunun raporlamaya anlamı
Filtreyi etkinleştirdiğiniz gün, aylık karşılaştırmalarda yapay bir kırılma yaratır. Önceki dönemde iç trafik içeren rakamlar yeni dönemde temizlenmiş rakamlarla karşılaştırılır ve dönüşüm oranı veya oturum sayısı "düşmüş" görünebilir. Bu düşüş performans kaybı değil, ölçüm tanımının değişmesidir. Raporlarda bu tür kırılmaları işaretlemezseniz yönetici kısa sürede yanlış bir hikâye kurabilir.
Değişiklik kaydı şablonu
| Alan | Ne yazılır |
|---|---|
| Tarih ve saat | Filtrenin Active durumuna geçtiği an |
| Filtre türü ve adı | "Internal traffic" veya "Developer traffic" ve filtre adı |
| Kural içeriği | Hangi ağ veya yöntem, kural adı, traffic_type değeri |
| Test süresi | Testing durumunda kaç gün kalındı ve ne gözlemlendi |
| Sorumlu | Kuralı kuran ve onaylayan kişi |
| Beklenen etki | Hangi metriklerde düşüş veya düzeltme bekleniyor |
| Gözden geçirme tarihi | IP adreslerinin güncelliğini yeniden kontrol edeceğiniz gün |
Aylık rapora not düşme
Raporun altına kısa bir not eklemek yeterlidir: "Belirtilen tarihte ofis ağı ve geliştirici etkinliği veri filtreleriyle dışarıda bırakıldı; bu tarihten önceki rakamlar iç ziyaretleri içerir." Rapor yapınız için aylık SEO raporu şablonuna bu notu ölçüm değişiklikleri satırı olarak ekleyebilirsiniz.
Organik trafik analizi için sonucu
Organik trafiği filtrelemeden yorumlarsanız iç ziyaretler özellikle sayfa görüntüleme ve etkileşim sayılarını bozar. Organik performansı GA4'te nasıl analiz edeceğinizi GA4 ile organik trafik analizi yazısında anlattık; filtreyi kurduktan sonra o yazıdaki karşılaştırmaları yeni tanımla yeniden başlatmak daha sağlıklıdır.
Filtre devreye girdikten sonra düzenli kontrol
- Birkaç gün sonra kendi ziyaretinizin raporlara girmediğini doğrulayın.
- Ağ değiştiğinde (ofis taşıma, sağlayıcı değişikliği) kuralı güncelleyin.
- Yeni ekip üyesi veya ajans eklendiğinde kapsamı yeniden gözden geçirin.
- Her üç ayda bir filtre listesini ve durumlarını (Testing, Active, Inactive) kontrol edin; sınır olan 10 filtreyi aşmayın.
- Beklenmedik trafik düşüşlerinde ilk olarak filtrenin yanlış bir ağı kapsayıp kapsamadığına bakın.
Sık yapılan hatalar
- Filtreyi doğrudan Active durumda oluşturup test etmemek.
- Yerel ağ adresini (192.168 ile başlayan) kural olarak yazmak; GA4'e ulaşan adres herkese açık adrestir.
- Çok geniş bir "begins with" kuralıyla gerçek müşterileri de dışarıda bırakmak.
- Filtrenin geçmiş veriyi düzelteceğini varsaymak.
- Değişikliği belgelemeden aylık karşılaştırma sunmak.
- Bilinen bot dışlaması olduğu için ek bir inceleme gerekmediğini düşünmek.
Sık Sorulan Sorular
GA4'te kendi ziyaretlerimi nasıl hariç tutarım?
Admin altında web veri akışınızdan "Define internal traffic" kuralını IP adresinize göre oluşturur, ardından "Data filters" bölümünde "Internal Traffic" türünde bir "Exclude" filtresi kurarsınız. Filtreyi önce "Testing" durumunda doğrulayın, sonra "Active" yapın. Mülk düzeyinde Editor rolü gerekir.
Filtre geçmiş veriyi de temizler mi?
Hayır. Google, veri filtrelerinin oluşturma anından itibaren değerlendirildiğini ve geçmiş veriyi etkilemediğini yazar. Etkinleştirilen filtrenin etkisi kalıcıdır; dışarıda bırakılan veri Analytics'te ve BigQuery'de hiç bulunmaz.
Filtre ne kadar sürede çalışmaya başlar?
Google filtrelerin uygulanmasının 24 ile 36 saat sürebileceğini belirtir. Testing durumunda değer görünmüyorsa daha sonra yeniden bakın ve hemen kuralı değiştirmeyin.
Bot trafiğini GA4'te kendim filtreleyebilir miyim?
Bilinen bot ve örümcek trafiği Google tarafından otomatik dışarıda bırakılır; bu dışlamayı kapatamaz ve ne kadar trafiğin dışarıda kaldığını göremezsiniz. Bilinmeyen bot için sayfada ayrı bir ayar yoktur; kaynağı belliyse alan adına ya da ağa göre filtre düşünülebilir, belli değilse önce rapor düzeyinde inceleyin.
Developer traffic filtresi IP kuralının yerine geçer mi?
Hayır. Developer traffic filtresi yalnızca hata ayıklama modunu kullanan geliştirici etkinliğini dışarıda bırakır. Hata ayıklama modunu açmayan ekip üyelerinin ziyaretleri için IP temelli iç trafik kuralı gerekir.
Bir mülkte kaç veri filtresi oluşturabilirim?
Google'ın Filter out internal traffic sayfası mülk başına en fazla 10 veri filtresi sınırı verir. Belgelerdeki sınırlar değişebilir; uygulamadan önce güncel sayfaya bakın.
İlgili rehberler: SEO A/B Testi: Cloaking Olmadan Başlık ve Şablon Denemesi, GA4 Veri Eşiği Nedir? Raporda Satırların Gizlenme Nedenleri.
Sonuç
Temiz bir GA4 verisi için üç adım yeterlidir: iç ağları tanımlamak, filtreyi Testing durumunda doğrulamak ve ancak ardından Active yapmak. Geliştirici etkinliği için ayrı "Developer traffic" filtresi, bilinen botlar için ise Google'ın kapatılamayan otomatik dışlaması vardır. Bilinmeyen bot trafiğinde önce rapor düzeyinde inceleyin, kaynak netleşmeden kalıcı filtre kurmayın. Filtrenin geçmiş veriyi düzeltmediğini, etkinleştirme tarihinden itibaren karşılaştırmaların kırılacağını ve bunu raporda not etmeniz gerektiğini unutmayın.
Temiz ölçüm kurduktan sonra bir sonraki adım, doğru kitlenin gördüğü yerde yer almaktır. Hedef kitlenize ulaşan sitelerde konumlanmak için Akua Adforce'ta reklam alanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili sayfada yazılıdır.
Yorum Yaz
Yorum yapabilmek için giriş yapmalısınız. Giriş Yap