My Step-By-Step Blueprint For Learning and Mastering Google Analytics 4 (GA4)

Get the FREE e-book on Google Analytics 4 – GA4 (126 Pages)

Yes I want the FREE ebook

Last Updated: May 24, 2022

Introduction to Fiddler

Fiddler is basically a proxy server. It is primarily used by web developers for testing and improving website performance and security.

I use Fiddler only for debugging Google Analytics issues and that too only when I have got a special case. The majority of the time, I use Google developer console.

Just like Google developer console, Fiddler can also simulate the production environment and thus make it possible to test code on a live website without server access. But unlike Google developer console, Fiddler can do many more things which I will explain in this article.

Fiddler records all HTTP requests and responses between a web browser and a web server. This also includes all the hits (pageview, screenview, event, transactions, etc) sent by a web browser to the Google Analytics server.

Installing Fiddler

Fiddler is a free desktop tool and very easy to install. You can download this tool from here: https://www.telerik.com/download/fiddler.

I use Fiddler 4. So all the screenshots included in this article are from this version.

Get this 70 page detailed checklist containing screenshots, step-by-step instructions and links to articles

Do you want to set up Google Analytics 4 (GA4) fast and correctly?

Yes I want the ebook

Understanding the concept of a web session

Before you use Fiddler, it is very important that you understand what a web session really is and how browsers and servers communicate with each other. The entire Fiddler tool has been developed around the concept of a web session.

A web browser (like Chrome) and a web server (the machine which hosts your website) follow a set of rules to communicate with each other. This set of rules is known as Hyper Text Transfer Protocol or HTTP.  If there is a secure connection between a web browser and a web server, then the set of rules they follow to communicate with each other are known as Hyper Text Transfer Protocol Secure or HTTPS.

You can easily see the protocol used by a website by looking at its URL. For example:

For example, my website uses HTTP protocol to communicate with my web server. Whereas Google uses HTTPS. A web browser communicates with a web server by sending HTTP requests for each requested resource. This resource can be a text file, CSS file, JavaScript file, image file, etc.

The web server communicates back by sending an HTTP response for each HTTP request.

Each HTTP request is made up of a request line and request headers (also called HTTP request headers). Similarly, each HTTP response is made up of status line and response headers (also called HTTP response headers). A web session is a series of interactions (HTTP requests and responses) between a web browser and a web server in a given time period.

Here is how HTTP request looks like: 

This request was made to my web server (where my website is hosted) by a user’s browser. Now since the request was made to my web server, my server has to communicate back (it has to obey HTTP protocols) to the user’s browser. It does so by sending an HTTP response.

Here is how HTTP response looks like:

This response was sent by my web server to the user’s browser. Now if you want to see these HTTP request and response headers, you just can’t see them by viewing the source code of a web page. You won’t find them there.

Follow the steps below to see HTTP request and response headers in Fiddler:

Step-1: open Fiddler, type website address in the ‘quick execute’ box and press enter:

Step-2: Select a session from the session list. You will then see HTTP request and response headers under the Inspectors Tab > Headers on the right-hand side of the Fiddler window:

Types of Web Sessions in Fiddler

Fiddler session list shows different types of web sessions like:

• text session – the session in which text file was requested from the web server.
• css session – the session in which css file was requested from the web server.
• image session – the session in which image file was requested from the web server.
• javascript session – the session in which JavaScript file was requested from the web server.
• cookie session – the session that set cookies.
• Google Analytics session – the session in which hit data (pageviews, screenview, event, transaction, item etc) was sent to the Google Analytics server.
• and many more

Keep in mind that what Google Analytics called as session (or visit) is different from what Fiddler called as session. In the case of Google Analytics, a session is that web session in which hit data is sent to the Google Analytics server. This is not the case with fiddler. So don’t get confused with Fiddler sessions.

Viewing Fiddler Session List

As mentioned earlier, to view the Fiddler session list, you need to open Fiddler, type website address in the ‘quick execute’ box, and press enter. However, keep the following things in mind:

1. Make sure that ‘Capture Traffic’ option is enabled under the File Menu:

Otherwise, your session list won’t appear.

2. Make sure that you clear your browser cache before you view the session list so that all HTTP requests are sent and captured.

In the session list, you can see the web session summary for each session:

The first column of the web session summary contains the Fiddler ID number (the number used to uniquely identify a particular web session in Fiddler) like 1, 2,3,4,5, etc.

The second column of the web session summary contains the status code. Common status codes are 200 and 304. 200 means the HTTP request was successful. 304 means the requested resource has not been modified. So there is no need to re-transmit the resource.

The third column of the web session summary contains the protocol used: HTTP or HTTPS

The fourth column of the web session summary contains the hostname, like www.optimizesmart.com

The fifth column is the URL of the requested resource.

Then there are other columns like body, caching, content-type, process, comments, etc.

Searching Fiddler Session(s)

By default Fiddler list every HTTP request made to the web server. So you are more likely to see a pretty long list of web sessions. Now for debugging Google Analytics issues, you most likely want to analyse only Google Analytics sessions i.e. the web sessions in which hit data was sent to the Google Analytics server. Manually searching for Google Analytics sessions is quite difficult especially when the session list is quite long. You can make this task easy by following the steps below:

Step-1: Click on the ‘Find’ button on the Fiddler toolbar once the complete session list has downloaded:

This will open the ‘Find Sessions’ dialog box:

Step-2:  Enter ‘www.google-analytics.com’ in the ‘Find’ text field and then click on the ‘Find sessions’ button. Fiddler will highlight all the Google Analytics sessions for you:

You can also use regular expressions to find web sessions that match a particular pattern. For example, you can use the following regular expression to find all the web sessions in which Javascript file was requested:

Filtering Fiddler Session(s)

If you are using Fiddler just for the purpose of Google Analytics debugging, you may not want to see non-google analytics sessions in the fiddler list.

Follow the steps below to filter out all Google Analytics sessions:

Step-1: Click on the ‘Filters’ tab on the right-hand side of the Fiddler window

Step-2: Check the checkbox ‘Use Filters’

Step-3: Check the checkbox ‘Show only if URL contains’

Step-4: Enter the following string in the text box: www.google-analytics.com

Step-5: Delete the previous session list by selecting ‘Remove All’ from the drop-down menu:

Step-6:  Type a website address in the quick execute box and then press enter:

You will then see a list of only Google Analytics web sessions:

Marking Fiddler Sessions

You may want to mark a particular web session in the filtered session list for easy reference. Follow the steps below:

Step-1: Right-click on the web session you want to mark in the session list and then mouse over ‘Mark’ option:

Step-2: Select one of the mark options from the sub-menu. Say you selected ‘Red’. Your marked web session will now look like the one below:

Inspecting Fiddler Sessions

By inspecting fiddler sessions you can interpret:

1. Google Analytics tracking beacon
2. Universal Analytics tracking beacon
3. Tracking beacon for other event hit type.

A tracking beacon is the query string of the GIF request.  

For example, the following is the example of tracking beacon in Fiddler:

Interpreting Google Analytics Tracking beacon in Fiddler

To analyse a tracking beacon, follow the steps below:

Step-1: Delete the previous session list by selecting ‘Remove All’ from the drop-down menu.

Step-2: Type a website address say www.moz.com in the ‘quick execute’ box and press enter. Make sure that you already have a filter set up that filters out all the Google Analytics sessions.

Step-3: Select a Google Analytics session from the session list and then click on the Inspectors tab > Web Forms:

Through Inspectors tab > Web Forms, you can easily read each and every parameter of the query string (aka tracking beacon). By reading this tracking beacon, you can determine the hit and browser data that is being sent to the Google Analytics server. As you can see, the tracking beacon is made up of multiple parameters like: utmwv, utmn, utmhn, etc and each parameter has got special meaning.

For example:

• utmwv denotes the tracking code version.
• utmn denotes the unique ID generated for each GIF request.
• utmhn denotes the host name
• utmdt denotes the page title

You can get a complete list of the tracking beacon parameters from here: https://developers.google.com/analytics/resources/articles/gaTrackingTroubleshooting#gifParameters

The first thing that you would notice by reading the tracking beacon is that moz.com uses the old Google Analytics library (ga.js). This is evident from the query string parameters like: utmwv, utms, utmn etc.

The query string parameters are different in the case of Universal Analytics.

Get this 70 page detailed checklist containing screenshots, step-by-step instructions and links to articles

Do you want to set up Google Analytics 4 (GA4) fast and correctly?

Yes I want the ebook

Interpreting Universal Analytics Tracking beacon in Fiddler

To analyse a Universal Analytics tracking beacon, follow the steps below:

Step-1: Delete the previous session list by selecting ‘Remove All’ from the drop-down menu.

Step-2: Type a website address say www.okdork.com in the ‘quick execute’ box and press enter. Make sure that you already have a filter set up that filters out all the Google Analytics sessions.

Step-3: Select a Google Analytics session from the session list and then click on the Inspectors tab > Web Forms:

The first thing that you would notice by reading the tracking beacon is that okdork.com uses the Universal Analytics library (analytics.js). This is evident from the query string parameters like: v, _v,a,t etc which are different from the parameters sent in case of the classic Google Analytics. Each parameter has got special meaning. For example: ‘t’ denotes the hit type, ‘tid’ denotes the property id, ‘dt’ denoted the page title etc. You need to remember the meaning of each parameter in order to read the tracking beacon.

The tracking beacon is sent for each hit (pageviews, screenview, event, transaction, etc).

Following is the example of Universal Analytics tracking beacon for ‘event’ hit type:

‘t’ denotes the hit type (which is ‘event’ in the present case)

‘ec’ denotes the ‘event category’

‘ea’ denotes the ‘event action’

Dropping certain HTTP request(s)

This is one of the main reasons I use Fiddler. Through AutoResponder you can also test new code on a live website without server access by replacing certain HTTP request(s). You can drop certain HTTP request(s) to determine whether a certain script is interfering with your website tracking. In order to drop certain HTTP request(s), follow the steps below:

Step-1: Select the HTTP request you want to drop from the session list.

For example, let’s say you want to disable enhanced ecommerce plugin in order to determine whether this plugin is interfering with your website tracking.

Select the web session which requests to load the enhanced ecommerce plugin from the session list:

Step-2:  Click on the ‘AutoResponder’ tab > Check ‘Enable Automatic Responses :

AutoResponder allows Fiddler to respond on behalf of a web server. Thus you can determine whether the client (browser) can correctly handle the server response.

Step-3: Click on the ‘Add Rule’ button. You will then see a new request listed:

Step-4: Click on the second drop-down menu below in the ‘Rule Editor’, select ‘drop’ and then click on the Save button:

You will then see ‘drop’ next to your HTTP request:

So what Fiddler will do now, that going forward, whenever it will see an HTTP request to download enhanced ecommerce plugin (ec.js), it will replace that plugin request with drop request i.e. it will drop the request to download the plugin.

In other words, enhanced ecommerce plugin will not download going forward and you can now check how your website behaves without enhanced ecommerce tracking setup.

Note: Whatever changes that you are making on the website via Fiddler will appear only to you on your browser. You can’t actually disabled enhanced ecommerce tracking of someone’s website without server access.

Step-5:  Delete the previous session list by selecting ‘Remove All’ from the drop-down menu, Type the website address (whose enhanced ecommerce tracking you have disabled) in the ‘quick execute’ box and press enter.

You can then see the dropped session in the session list:

Note:  A dropped session has a status code of 0.

Get this 70 page detailed checklist containing screenshots, step-by-step instructions and links to articles

Do you want to set up Google Analytics 4 (GA4) fast and correctly?

Yes I want the ebook

Replacing certain HTTP request(s)

By replacing an HTTP request by another request, you can test your modified code on a live website without server access. Let us suppose, you want to test your modified scroll tracking script on the live website before you send it to the web developer. To do this follow the steps below:

Step-1: Select the HTTP request you want to replace by another request from the session list. You need to select the request for the file which contains the scroll tracking script.

Step-2: Click on the ‘AutoResponder’ tab. Make sure that ‘Enable Automatic Responses’ checkbox is checked.

Step-3: Click on the ‘Add Rule’ button.

Step-4: Click on the second drop-down menu below in the ‘Rule Editor’ and select ‘Find a file’:

Step-5: Select the file from your desktop which contains the new scroll tracking script and then click on the save button:

So what Fiddler will do now, that going forward, whenever it will see an HTTP request to download the file which contains the scroll tracking script, it will replace that request with the file which contains the new scroll tracking code.

Note: Whatever changes that you are making on the website via Fiddler will appear only to you on your browser. You can’t actually modify the tracking script of a website without server access.

Step-6:  Delete the previous session list by selecting ‘Remove All’ from the drop-down menu, type the website address (whose scroll tracking script you have modified) in the ‘quick execute’ box, and press enter.

Mark HTTP responses that set cookies

You may need to identify all those web sessions in which a cookie is set by an HTTP response. You can do that by installing a Fiddler add on called ‘Privacy Scanner’.

Once you have installed this add-on, you will see a new menu in the Fiddler toolbar called ‘Privacy’ menu. Click on this menu and select ‘Enabled’:

Fiddler will then highlight all the web sessions in which a cookie is set by an HTTP response: