Testing filter and setting changes in Google Analytics

Working with Google Analytics is often associated with Google Analytics testing. If you test too often and a lot, change the settings, add / remove filters without testing them beforehand - everything goes awry, and reports that otherwise look clean and correct turn into a mess.

In programming, there is always a development stage. At this stage, anything can happen (and usually happens). You do your dirty work, you screw it up, you do it all over again, and when at last everything looks clean and cool, present your creation to the public.

Although testing in Analytics is not so abstruse, it does its job and allows you to make sure that the reports and data that people in your company look at do not look like crap.
')
If you’ve been doing web analytics for a while, you’re probably in a situation where you need to exclude certain referrals and prevent them from appearing in reports such as Top Conversion Paths and Campaigns . The most common example is the exclusion from referrals of payment systems.

Suppose your site uses the PayPal payment system to process user payments. After making the payment and returning the user to the site, all the money brought by him will be assigned to the PayPal channel, and your report on “Main Conversion Paths” will look something like this:


This, of course, is wrong.

In short, using the example of excluding certain referrals in your Google Analytics account, I will demonstrate how I test changes to the settings of this service.

Copy the main view

The first thing we need to do is copy our main, “working” view with all of its goals, filters, and settings. Thus, we get something like a test site for our changes.



We will be able to make sure that the data and reports that everyone is looking at will not turn into rubbish.

In addition, if your site is crowded, it’s not so easy to track test messages in the “Real-time” report - we just won’t find our test requests in all this confusion.

Add a couple of new filters for tests.

Now that we have an exact copy of our main view, we need to tweak it a little bit for testing purposes. The easiest way is to create a filter that accepts calls only from our IP address and blocks all others. Thus, we will understand that everything that is displayed in the reports (including the “Real-time” report) was generated by us. This will greatly help us focus on debugging by cutting off all "real" requests.

If your main view had a filter that cut off your office (or home) IP - you need to remove it from the test view.


If you work in a large company where workplaces have the same IP address, this filter will not prevent your colleagues from contacting you. If you really need to make sure that not a single extra request passes, you can be smart and create another filter. For example, in my case, I create a filter that accepts only those calls that contain a URI with the “filter-testing” parameter .


Now we, respectively, need to make sure that all the “viewed” pages (associated with the dl parameter in the Measurement Protocol platform have this parameter).

yourwebsite.com/some-random-page.html turns into yourwebsite.com/some-random-page.html?filter-testing

Preparing a "test environment"

Open the report "Real time" in the newly created view. It will be just fine if we can have this report in full view all the time when we will send appeals. Personally, I prefer to open this report in a separate window and move it to another monitor (I have a 2-monitor workplace, like many of us). If this report is constantly visible - we will have the opportunity to follow the sent requests in real time.

Here is the window I use to send hits through the Measurement Protocol.


And here is the “Real-time” report window:

“Generate” calls and apply new settings

Now you can start sending calls. Again, it’s better to do it with the help of Measurement Protocol, like a boss (if you don’t know this platform, this is sad).

Since I need to make sure that a certain referral does not break my reports and does not launch a new session for site visitors (this is what he does), I take the example of a referral that I have as a result of switching from this site to my site.


Now, I need to send this calls a couple of times. To do this, I simply insert the received link into the address bar of the browser and refresh the page several times (just in case). This is necessary to ensure that this link Measurement Protocol works correctly.


Now it's time to apply our new settings. I go to the “List of Excluded Transition Sources” and add the referer mentioned.



Now, if you change clientid in the parameter of the Measurement Protocol URL (in order to start a new session)

cid=133064705.1470902689 

To any other value (I replaced one digit)

 cid=133064705.147902688 

You will see that the referral traffic that we “generated” a couple of minutes ago is now successfully converted to “direct” traffic with appropriate labels ("(direct) / (none)"), which in this case means: "our exception works correctly ".

Time:


And two:


If I need to test a couple of new filters, this method seems to me the most effective in order to make sure that they are correct and never to return to them again.

When the job is done, we can leave this presentation for future needs, or just delete it.