Google Analytics can be said to be a single serving if you can master the filter function. The filter function of Google Analytics is actually highly functional despite the small amount of information. Let’s start by understanding and mastering the five recommended filter settings introduced in this article.
Exclude the influx of site officials
First of all, it will be a basic filter setting in the basics. If you are a company that has a fixed IP address, I think that there are many settings that filter by IP address. However, when the relevant person accesses from outside the company network, or in the case of a company that has not acquired a fixed IP address, the hurdles to exclude the inflow of the site related person will suddenly increase.
Here, we will explain the filter settings that exclude the inflow of site officials by methods other than such IP addresses.
In the method explained here, it is necessary to set “Client ID” in the custom dimension of Google Analytics as a preliminary setting. If you are using Google Tag Manager, please refer to How to get Google Analytics ClientID using GTM .
If you have come this far, it is easy, and in the filter settings, you can specify all the client IDs of the parties involved in the exclusion settings. It is troublesome to exclude them one by one, so if there are multiple parties involved, it is better to exclude them all at once using regular expressions. Alternatively, create a custom dimension like “User Classification” and specify whether the user classification is “General User” or “Site Personnel” to make the filter easier to understand.
Exclude access to another host
In the case of sites where a large number of people are involved in production and development, in addition to the published URL, a staging environment or development environment is prepared for only those involved in production to check the operation. . If the same Google Analytics tag as the one installed on the public site is also installed in the development environment, the number of page views will suddenly increase at the timing of development, and even if there is no conversion on the public site There is a possibility that unintended conversions may occur during operation checks during development.
The above problem can be prevented by creating a separate Google Analytics for the development environment and installing a tag for it, but depending on how the site is built, you may have to add the tag for the development environment. There is also a risk that the production will be released as it is.
Also, due to referrer spam, etc., there is a possibility that the publicly available Google Analytics tag will be installed on an unintended site.
To avoid such a situation, set a filter so that only URLs to hosts that are actually in operation appear in the report. One thing you need to be careful about is when you are using cross-domain settings. If you have cross-domain settings, you need to write the following filter with a regular expression.
Integrate referral sources for Facebook traffic
The reference source used for the inflow from Facebook is [Memorandum] [Google Analytics] According to the reference source “facebook related summary”,
| Referrer | Inflow method |
|---|---|
| facebook.com | via timeline |
| l.facebook.com | Via advertising (desktop) |
| lm.facebook.com | Via advertising (mobile) |
| m.facebook.com | Via Facebook Mobile |
There are a total of 4 patterns. Although there are 4 patterns, whether or not it is via advertisement should be classified by media rather than referral source, and whether it is mobile or not can be judged by Google Analytics device category, so these 4 referrers It will be easier to understand in the report if it is integrated.
Please refer to the following settings when configuring this setting.
The value entered in “Search string” is
^(lm|l|m).facebook.com$(Please copy and use this).
Set media for inflows via RSS to rss
In the case of running a blog or news site, the number of inflows via RSS is very important for measuring the number of fans (degree of repeater acquisition). RSS readers are divided into native apps and web services. Native apps cannot be categorized in this way because the referrer is “direct”.
If you want to measure inflows via RSS, including native apps, you need to set up a Google Analytics custom campaign for the URL delivered by the RSS reader. Furthermore, which RSS reader is the flow from? When accessing RSS data, it is necessary to determine which RSS reader is based on the IP address and user agent of the request source and dynamically rewrite the value of utm_source. (If you’re using a blogging system such as Hatena Blog, most of the time the blogging system doesn’t support it, so you have no choice but to give up.)
However, if you use the filter setting method this time, the inflow from “livedoor Reader” and “Feedly”, which are web service type RSS readers that are considered mainstream at the moment, will be almost suppressed, and it will be easier to implement. Is possible.
Please refer to the following settings to configure this setting.
In addition, the value entered in “Campaign source” is
(reader.livedoor.com|feedly.com)(Please copy and use this). If there is another RSS reader with inflow, it can be handled by increasing it in the same way.
Integrate mobile and desktop page paths
It is just a filter setting related to smartphone support that is popular now. If you are using a responsive format for smartphones, there is no problem because the URL for the same content is the same on PC and mobile. However, if the URL for the smartphone version is different from the URL for the PC version, or if the URL for the smartphone version is built in subdirectories instead of dividing by subdomains, this is an effective filter setting.
When building a smartphone version URL in a subdirectory, when looking at the report of “Behavior > Site Content > All Pages” in Google Analytics, even though it is the same content
- /index.html
- /sp/index.html
It will be displayed divided into two like this. In this case, when narrowing down by the condition of “visiting a specific page” in Google Analytics, I forget about the URL of the smartphone version, and omissions come out in narrowing down, and I want to see the number of PV for each directory. When it becomes , it can not be completed on Google Analytics, and the work of exporting to Excel etc. will occur each time.
So let’s integrate these URLs using the Google Analytics filter settings. Also, if you just integrate it, you will be in trouble when you want to know the number of people who have viewed the smartphone version of the page (not access from smartphones), so you can add the custom dimension “page compatible device”. Let’s create something like this so that you can judge whether you are actually looking at the PC version of the page or the smartphone version of the page.
The example below assumes that the smartphone version URL for ” http://www.example.com/hoge/index.html ” is ” http://www.example.com/sp/hoge/index.html “. This is a setting example for a site with a simple site configuration.
summary
When applying filters to real accounts, make a copy of the view and test that the filter works as intended before applying it to the main view. Also, don’t forget to keep a backup view with no filters applied.
