Google Analytics 4 (GA4) Property Structure article aimed to provide general information about the GA4 property structure. As in my previous article GA4 - Currency Parameter in E-commerce Transactions, I also pay attention to detailing certain topics based on the various situations I’ve encountered. In this article, I will again continue from the previous one by providing detailed information on filtering.
GA4 Data Filters
GA4 provides us with Data Filters at the property level, enabling traffic filtering through Internal Traffic and Developer Traffic filter types.
These operations can be performed either by inclusion (include) or exclusion (exclude). To set up data filters, you simply follow the steps under Property Settings > Data Settings > Data Filters 1.
Filters begin affecting incoming traffic from the moment they are created, so historical data will not be impacted by these filters. Additionally, unlike Universal Analytics [../../google-analytics-filters], these filtering methods affect all data within the property scope. Universal Analytics offered features such as creating views under a property and performing filtering operations at both property and view levels. This allowed us to retain views (raw) where filters were not applied. Unfortunately, at this time, such an adjustment is not possible for GA4. However, GA4 provides some levels of safeguards to address potential issues 1 2.
However, as I will detail shortly under the Internal Traffic section, IP addresses can be considered through data streams (stream).
Internal Traffic, generally the most commonly used filter type. It is used to mark or exclude traffic outside the intended audience by applying parameters and/or IP blocks through reporting processes, at the property or data stream (stream) level, and is typically managed by internal controls and relevant departments3.
GA4 automatically identifies internal traffic based on the internal value assigned to the traffic_type parameter. While the parameter name cannot be changed, different values can be assigned to it.
For example, separate definitions can be created for employees, providers, and other users outside the target audience who frequently interact with the website and/or mobile app.
| Parameter Name | Parameter Value | Target |
|---|---|---|
| traffic_type | internal_employees | Internal, general access |
| traffic_type | internal_providers | External, service providers |
| traffic_type | internal_suppliers | External, suppliers |
| traffic_type | internal_qa | Internal units |
| traffic_type | internal_other | External other units |
Based on the above definitions, traffic matching a specific value of traffic_type is marked accordingly.
The above operations are valid for actions performed via the event parameter. Additionally, for internal traffic filtering, IP-based rules can be used by following the steps: Data Streams > Used stream > More Tagging Settings > Define internal traffic > Create.
Again, using this filter, it is possible to set a default value of internal or a customized parameter for traffic_type.
Developer Traffic
Developer Traffic is another filter type that, although frequently used, is often overlooked.
The request to exclude test traffic—particularly when test activities appear in reports and lead to misinterpretation of data—is addressed from the outset using this filter.
For test activities outside of the relevant filter, data deletion requests must be made to ensure the deletion of associated data. Incidentally, I should note that certain restrictions apply in this process4.
For the Developer Traffic filtering process, setting the value of debug_mode or debug_event parameter to 1 is sufficient. Depending on the selected filter configuration, data may either be included in reports or excluded. However, regardless of the selected configuration, the relevant traffic can be viewed via the DebugView.
Filtering Through Activity Modifications
The parameters and values defined for created filters can be linked to activity customizations or new activity definitions (modify events or create custom events) to ensure data is filtered accordingly, or to create new activities associated with these parameters. For example, when operations are performed via a VPN, IP-based filters may not apply. In such cases, a filter valid only for specific products (e.g., those identified by a specific identifier such as item_id or item_name) can be created.
The relevant filter parameters and their values can be viewed both in activity reports and in the DebugView screen.
As shown in the images above, products with an item_name of test can be associated with specific parameters. Naturally, much more complex conditions can also be created.
When operations related to this product are triggered, a new event will be fired, and the corresponding traffic can also be filtered.
The relevant filter operations can be verified and analyzed by checking the parameters via DebugView. This enables transitions between filter states (testing to active), as will be discussed shortly.
Filter States
GA4 filter processes provide various states (state) for testing filters and determining whether filter data should be passed to reports.
Testing
When a filter is first created, it is processed in the Testing state. Data marked with this state can be displayed in all report formats through dimensions.
Active
There may be situations where data being tested should not be included in reports. Data in the Active state is excluded from reports, but can still be viewed via DebugView.
Inactive
Deactivates the relevant filter. Filters in inactive state do not affect data.
We can view data in testing mode alongside their respective parameters in real-time data streams. Additionally, through reports, we can separate filtered data from other data using filters5. For this purpose, selecting the relevant filter as a comparison (comparison) in standard reports is sufficient6.
Filters can be added separately as Internal and Developer, or combined for comparison purposes.
Together with this, detailed views of the relevant data can be obtained within Reports under the Reports section.
Filters in Discovery Reports
It is also possible to view data marked with filters in Discovery (explore) reports. When selecting the Test data filter name dimension for data marked with filters, and dragging it to either the Rows or Columns field, the data marked as Internal and Developer will be separated from other data5. Unfortunately, for Internal, data separation based on the directly assigned value is not possible7.
However, if a specific event is marked with a filter, operations can be performed through that specific event.
For example, in the visual above, the Filtered engagement is displayed with its parameters, which is triggered based on the engagement parameters. This engagement is indirectly associated with flagged data depending on the value of either the Internal or Developer filter parameters. Unfortunately, for the Internal filter, the defined parameters cannot be further broken down internally.
Footnotes
- How to create and test filters in GA4 ↩ ↩2
- GA4 Filters - Understanding Data Filters in GA4 ↩
- Julius Fedorovicius. (2021). How to Exclude Internal Traffic in Google Analytics 4 ↩
- Data deletion requests. Analytics Help ↩
- Filtering access to data subsets, reporting, or restricting access ↩ ↩2
- Create and edit comparisons in reports. Analytics Help ↩
- Data filters. Analytics Help ↩