Testing changes to filters and settings in Google Analytics

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

There is always a development phase in programming. At this stage, anything can happen (and usually happens). You do your dirty work, screw up, redo everything again, and when at last everything looks clean and cool, present your creation to the public.

Although testing at Analytics isn’t all that smart, it does its job and makes sure that the reports and data that people in your company are looking at don't look like shit.

If you are doing web analytics for some time, you are likely to fall into a situation where you want to exclude certain referrals and prevent their occurrence in such statements as ' Top Conversion Paths' ( 'the Top Conversion the Paths "), and " Campaign " . The most common example is the exclusion from referrals of payment systems.

Suppose your site uses PayPal 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 “Main Conversion Paths” will look something like this:

image

This, of course, is not true.

In short, by the example of the exclusion of certain referrals in the Google Analytics account, I will demonstrate how I test changes in the settings of this service.

Copy the main view


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

image


We can make sure that the data and reports that everyone is looking at will not turn into garbage.

Moreover, if it’s crowded on your site, it’s not so easy to track test requests in the “Real-time” report - we simply 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 “twist” it a little 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.

image

If you work in a large company where workstations have the same IP address, this filter will not prevent hits from your colleagues. If you really need to make sure that no extra request passes, you can be smart and create another filter. For example, in my case, I create a filter that only accepts hits that include URIs with the filter-testing parameter

image

Now, accordingly, we need to make sure that all the "browsed" 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

We prepare the "test environment"


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

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

image

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

image

“Generate” calls and apply new settings


Now you can start sending appeals. Again, this is best done using Measurement Protocol, like a boss (if you are not familiar with this platform, it’s sad).

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

image

Now, I need to send this appeal a couple of times. To do this, I simply paste the resulting link into the address bar of the browser and refresh the page several times (just in case). This is necessary in order to make sure that this Measurement Protocol link works correctly.

image

Now is the time to apply our new settings. I go to the “List of excluded referral sources” and add the referer mentioned.

image


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

cid=133064705.1470902689

On 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 the corresponding labels ("(direct) / (none)"), which in this case means: "our exception works correctly ".

Time:

image

And two:

image

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 return to them again.

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

Also popular now: