Data Filters в Google Analytics 4: как да ги конфигурираме правилно
Когато GA4 е инсталиран на сайт или приложение, той не прави автоматично разлика между реални потребители и вътрешен трафик - служители, програмисти, агенции, QA специалисти или тестови посещения. За системата всички взаимодействия са просто събития, сесии и потребители. Ако не филтрирате този трафик, рискувате да взимате бизнес решения върху изкривени данни.
Вътрешният трафик може да повлияе на ключови метрики като брой потребители, conversion rate, engagement rate, средна стойност на поръчка, ефективност на рекламни кампании и фунии за поръчка или регистрация. Затова Data Filters не са просто техническа настройка - те са част от хигиената на данните.
В тази статия ще разгледаме видовете филтри в GA4, ще ви преведем стъпка по стъпка през конфигурирането на Internal traffic и Developer traffic, и ще споделим добри практики за по-чисти отчети.
Видове Data Filters в Google Analytics 4
GA4 предлага два основни типа филтри за входящи данни, всеки от които решава различен проблем:
|
Тип филтър |
Какво филтрира |
Най-честа употреба |
|
Internal traffic |
Посещения от IP адреси или IP диапазони |
Изключване на служители, офиси, агенции, VPN |
|
Developer traffic |
Активност от debug mode |
Тестване през GTM Preview, DebugView и QA процеси |
Internal traffic е трафикът от хора и системи, свързани с бизнеса, които не са реални клиенти: служители, собственици, маркетинг екипи, SEO и PPC агенции, програмисти, QA специалисти и корпоративни VPN-и. Обикновено се дефинира чрез IP адреси.
Developer traffic е трафикът от потребители, които работят в debug режим и тестват имплементацията на GA4, GTM или събитията в сайта. Този филтър е особено полезен, когато искате developer и analytics екипите да виждат събитията в DebugView, без тези тестове да изкривяват стандартните отчети.
Освен Internal и Developer traffic, GA4 поддържа и Web hostname traffic filter, който филтрира данни според hostname - например за изключване на staging среди (staging.example.com), preview домейни или некоректно копирани tracking кодове.
Ако работите с multi-domain или subdomain структура, hostname филтърът може да ви помогне да изолирате чисти production данни. Детайлната му настройка заслужава отделно внимание, но е добре да знаете, че съществува като опция.
Преди да започнете: какво трябва да проверите?
За да създавате, модифицирате или изтривате Data Filters, трябва да имате роля на Editor или Administrator за дадена GA4 property. Преди да пристъпите към настройка, уверете се, че знаете кои IP адреси са вътрешни, дали екипът използва VPN, дали имате staging среда и дали тествате през GTM Preview.
Препоръка: създайте прост tracking governance документ. Запишете името на филтъра, типа, IP адресите, датата на активиране и човека, който е направил промяната. След 3 месеца никой няма да помни защо е създаден даден филтър без документация.
Как да филтрирате Internal traffic в GA4?
За да филтрирате вътрешен трафик, първо трябва да дефинирате кои IP адреси са вътрешни, а след това да активирате data filter, който изключва събитията със съответната стойност на traffic_type.
Стъпка 1: отворете Web Data Stream
Влезте в правилната GA4 property и изберете web data stream-а, към който е свързан сайтът. Пътят е:
Admin → Data streams → изберете вашия Web Data Stream
Admin → Data streams → Web Data Stream
След това отворете „Configure tag settings“:
Кликнете върху „Show more“, за да видите останалите настройки, и изберете „Define internal traffic“:
След това изберете „Define Internal Traffic“ (Определяне на вътрешния трафик).
Show more → Define internal traffic
Стъпка 2: създайте правило за вътрешен трафик
Правилото казва на GA4 кои посещения трябва да бъдат маркирани като вътрешни. Обикновено това става чрез IP адрес или IP диапазон. Кликнете върху „Create“:
Следващата стъпка е да конфигурирате правилото, като въведете неговото име, стойност за параметъра и IP адрес/и:
Конфигурация на правилото за вътрешен трафик
|
Поле |
Какво да въведете |
Пример |
|
Rule name |
Ясно име на правилото |
Office Sofia, Agency VPN |
|
traffic_type value |
Стойност на параметъра (по подразбиране internal) |
internal, office_sofia, agency |
|
Match type |
Тип съвпадение за IP |
equals, begins with, CIDR |
|
Value |
IP адрес или диапазон |
Публичният IP на офиса или VPN |
Добра практика: ако имате няколко офиса, не слагайте всичко под една стойност. Използвайте отделни стойности като office_sofia, office_varna, agency, vpn_internal — това прави troubleshooting-а по-лесен.
Ако не знаете своя IP адрес, потърсете „What is my IP“ в Google.
Стъпка 3: създайте или редактирайте Data Filter
След като GA4 знае как да разпознава вътрешния трафик, трябва да кажете какво да прави с него. Отидете на:
Admin → Data filters
Изберете съществуващия филтър за Internal Traffic (всяка GA4 property има такъв по подразбиране) или създайте нов:
Admin → Data filters → Internal Traffic
В настройките конфигурирайте:
|
Настройка |
Препоръчителна стойност |
Обяснение |
|
Filter name |
Internal Traffic или по-конкретно |
Името трябва да е ясно за екипа |
|
Filter operation |
Exclude |
Изключва вътрешния трафик от обработката |
|
Parameter value |
internal или вашата custom стойност |
Трябва да съвпада с правилото от Стъпка 2 |
|
Filter state |
Първо Testing, после Active |
Не активирайте директно без проверка |
В GA4 филтрите имат две възможни операции: Exclude (изключва данните, които отговарят на филтъра) и Include only (обработва единствено данните, които отговарят на филтъра). За вътрешен трафик използвайте Exclude.
Стъпка 4: първо използвайте Testing режим
Testing режимът е задължителен етап. Когато филтърът е в Testing, GA4 маркира данните, които биха били филтрирани, но не ги премахва от отчетите. Можете да видите филтрираните данни, като добавите сравнение (comparison) към отчетите си с името на филтъра.
Проверете дали вашето посещение се маркира правилно, дали реални потребители не попадат във филтъра и дали всички вътрешни IP адреси се разпознават.
Стъпка 5: активирайте филтъра
Активирайте филтъра само когато сте сигурни, че правилото работи правилно. Променете:
Filter state → Active
Когато филтърът е в режим на тестване („Testing“), GA4 го оценява, но не прави никакви промени в аналитичните данни. Въпреки това може да видите филтрираните данни, като добавите сравнение към своите аналитични отчети с името на филтъра.
„Active“ (Активен) е статусът, който трябва да изберете, за да активирате филтъра и да изключите вътрешния трафик от своите отчети.
Не забравяйте: това не изтрива исторически данни. Филтърът влияе само върху данните след активирането. Третата опция „Inactive“ може да използвате, за да деактивирате филтъра временно.
Внимание: активен Data Filter има необратим ефект. GA4 не запазва филтрираните данни — те не се събират и не могат да бъдат възстановени, дори ако по-късно деактивирате филтъра. Затова Testing режимът не е препоръка, а задължителна стъпка.
Как да филтрирате Developer traffic в GA4?
За разлика от Internal traffic, който идентифицира потребителите по IP, Developer traffic филтрира на база debug mode. Това ви позволява да тествате GA4 имплементацията в DebugView, без тестовите действия да замърсяват стандартните отчети.
Стъпка 1: създайте Developer traffic filter
Отидете на:
Admin → Data filters → Create filter
Изберете тип на филтъра — „Developer traffic“:

Конфигурирайте филтъра: въведете име (напр. Developer traffic), за Filter operation изберете Exclude, а за Filter state оставете Testing за начало:
Developer traffic filter в Testing режим
Стъпка 2: настройте Google Tag Manager
Ако използвате GTM, можете да подавате различна стойност на traffic_type според това дали сте в Debug/Preview режим. Така GA4 ще разпознава тестовия трафик автоматично.
В GTM отидете на:
Variables → User-Defined Variables → New
За тип на променливата изберете „Lookup Table“:
Като Input Variable изберете вградената в GTM променлива „{{Debug Mode}}“:
След това настройте таблицата: за Input „true“ задайте Output „developer“, а за Input „false“ задайте Output „Undefined Value“ (нова променлива от тип Undefined Value):
Конфигурирана Lookup Table променлива
Важно: използвайте консистентно изписване. Ако в GA4 филтърът очаква „developer“, не подавайте „Developer“, „dev“ или друга стойност.
Стъпка 3: добавете параметъра към Google Tag
След като променливата е готова, добавете я към Google Tag-а, който изпраща данни към GA4. Отидете на:
Tags → изберете вашия Google Tag
Добавете нов параметър traffic_type и за стойност изберете Lookup Table променливата, която създадохте. Натиснете Save:
Стъпка 4: проверете и активирайте
Преди да активирате филтъра, проверете през GTM Preview Mode дали GA4 tag-ът се зарежда, дали traffic_type се изпраща правилно и дали събитията се появяват в DebugView. Ако всичко е наред, върнете се в:
Admin → Data filters → Developer traffic
и променете Filter state от Testing на Active.
Чести грешки при Data Filters в GA4
|
Грешка |
Какъв е проблемът |
Как да я избегнете |
|
Директно активиране на филтър |
Може да загубите легитимни данни |
Винаги започвайте с Testing |
|
Един общ filter за всичко |
Няма яснота какво се изключва |
Разделете офис, агенция, QA, VPN |
|
Прекалено широк IP диапазон |
Може да изключите реални потребители |
Проверете диапазона с IT екип |
|
Dynamic IP без контрол |
Филтърът работи днес, но не утре |
Използвайте VPN или developer tagging |
|
Staging сайт в production property |
Данните се смесват |
Отделна property или hostname филтър |
|
Липса на документация |
Никой не знае защо данните са се променили |
Водете tracking changelog |
Добри практики за по-чисти GA4 данни
Data Filters са само една част от качествената analytics настройка. За надеждни отчети ги комбинирайте с добра структура на events, ясно именуване и регулярни проверки.
-
Използвайте ясни naming conventions — например INT - Office Sofia - IP, DEV - Debug Mode, HOST - Production only.
-
Не смесвайте production и staging данни в едно property.
-
Документирайте всички филтри и пазете screenshots на настройките.
-
Първо тествайте, после активирайте — без изключения.
-
Проверявайте DebugView при всяка промяна в GTM.
-
Правете месечен analytics audit и сравнявайте GA4 данните с CRM или backend.
-
Следете метриките след активиране на филтри за неочаквани спадове.
Имайте предвид: GA4 позволява до 10 филтъра за една property. Планирайте структурата предварително.
Кога Data Filters не са достатъчни?
Data Filters решават конкретен проблем с входящите данни, но не са заместител на добра GA4 архитектура. Ако имате много държави и екипи, staging и production среди, различни брандове в една property или нужда от нефилтрирани raw данни, помислете за отделна GA4 property за тестване, BigQuery export за по-дълбок анализ, server-side GTM или subproperties при GA4 360.
Финален checklist
Преди да приемете, че настройката е готова, минете през тези точки:
|
№ |
Проверка |
✔ |
|
1 |
Имам списък с вътрешни IP адреси и диапазони |
☐ |
|
2 |
Проверил съм дали екипът използва VPN |
☐ |
|
3 |
Дефинирал съм Internal traffic rule с правилните стойности |
☐ |
|
4 |
Създал съм Data Filter с operation Exclude |
☐ |
|
5 |
Оставил съм филтъра първо в Testing режим |
☐ |
|
6 |
Проверил съм дали правилният трафик се маркира |
☐ |
|
7 |
Проверил съм дали реални потребители не попадат във филтъра |
☐ |
|
8 |
Документирал съм настройките |
☐ |
|
9 |
Активирал съм филтъра едва след успешен тест |
☐ |
|
10 |
Следя отчетите след активиране |
☐ |
|
11 |
Настроил съм и Developer traffic filter за QA |
☐ |
|
12 |
Имам процес за бъдещи промени |
☐ |
Заключение
Data Filters в GA4 са базова, но критична настройка за по-точни отчети. Internal traffic филтърът изключва служители и офиси по IP, а Developer traffic филтърът предпазва от замърсяване по време на QA и тестване. И двата следват един и същ принцип: дефиниране на правило, Testing режим, валидация и чак след това Active.
Ако GA4 данните ви стоят зад решения за маркетинг, UX или бизнес стратегия, филтрирането на вътрешния трафик е минимален стандарт за качество на данните. Отделете време да го направите правилно веднъж, за да не коригирате последствията месеци наред.
Препоръчани нови статии















