Most of us use the Google Analytics suite on a day-to-day basis, without really thinking about how it all works. We install the GA or GTM code snippet on our websites, make some configurations, change some settings and add some tags, after which we dive straight into the reports. But we rarely think about how all that data is sent to the servers, how it is processed and ultimately shown in the Google Analytics user interface. The following will be an informational post on the first part of that process: how data is sent to the Google Analytics servers.
Google Analytics Measurement Protocol
All GA tracking systems (analytics.js, GTM, App SDKs, etc.) use the same standard set of rules for collecting and sending hits to the server, called the Measurement Protocol. This protocol allows us to send hits from any device that is connected to the internet, so not just websites or mobile applications.
When we use the Analytics JavaScript or mobile SDKs on our websites or mobile apps, they automatically build the hits that send the data to GA. But when we want to send data from other internet connected devices, we will have to build the collection hits ourselves. In essence, a hit is a simple HTTP request that is made to the GA server. How this hit should be formatted and sent to GA is defined by the Measurement Protocol.
Building a Google Analytics Hit
Currently, there are eight different types of hits that can be sent through the Measurement Protocol, the most important being pageviews, events and transactions. Every hit that sends data to Google Analytics should contain two parts: the transport and the payload.
Transport
The transport determines where and how your data is sent. Where your data is sent is determined by the URL endpoint of the HTTP request. For Google Analytics, this endpoint will always be the same:
https://www.google-analytics.com/collect
The type of request determines how your data is sent to Analytics. Generally, you can send data using either POST or GET requests. Google recommends sending hits via POST request, since it allows for a larger payload than GET requests. A POST request combined with the URL endpoint for GA will result in a transport that looks like this:
POST https://www.google-analytics.com/collect
Payload
The second part of the hit, the payload, looks like a URL query string with different parameters that contain the actual data that is being sent. For example, a very simple payload for a pageview hit may look like this:
v=1&t=pageview&tid=UA-12345678-9&cid=12345&dp=%2Fhomepage
Every payload has to abide by certain rules concerning required values, parameters that can or cannot be sent together, parameter length, etc. All values have to be UTF-8 encoded, some parameters can only be sent with certain hit types and some values have a maximum length in bytes. Luckily, Google has built a Hit Builder that checks all these different rules so that we don’t have to remember and check them for every hit we want to create.
Using the Measurement Protocol Hit Builder
The Hit Builder is part of the series of developer demos and tools built by the GA team. It’s very easy to use and allows users to construct hits for every different type, including all the necessary information that should be sent to Google Analytics. The tool consists of two parts: the hit parameter details, that you have to fill in according to the information you want to send, and the hit summary, that checks if your constructed hit does not break any of the rules mentioned before.
Let’s assume that we have an internet connected device with four buttons. The buttons measure customer satisfaction in a store (from very unhappy to very happy) by asking how happy customers were with the service and letting them press the corresponding button. Each button will then send a hit to Google Analytics. Using the Hit Builder, we can select and enter every payload parameter that we might want to send for every event.
The first four parameters are all required by the Measurement Protocol. In the given order, they represent the protocol version, the type of hit, the tracking ID that you want to send the hit to, and the client ID to identify a particular user, device or browser. The client ID is not required when a user ID is added to the parameter list instead.
The parameters with the red icons are parameters that were selected to be sent with the hit. For this event, these are simply the event category, action, label and value. A full list of parameters that can be sent in a hit and some common examples can be found in the Google help pages.
When all parameters have been provided, we can simply click the “validate hit” button to see if everything in our payload is correct. If so, we can send a test hit to Google Analytics and see if it enters our real-time reporting and then copy the hit payload to finish our HTTP request.
Combined with the typical transport for Google Analytics, the full HTTP request will now look like this:
POST https://www.google-analytics.com/collect?v=1&t=event&tid=UA-12345678-9&cid=12345&ec=button&ea=click&el=veryhappy&ev=4
This request will send a single hit to Google Analytics. However, it is also possible to send a batch of multiple hits in a single HTTP request. This could be used when you don’t want to send a hit for every event, but instead send a collection of hits every hour or at the end of the day. Instead of using the /collect endpoint in your transport, simply use the /batch endpoint and put each of the different payloads on a new line:
POST https://www.google-analytics.com/batch?
v=1&t=event&tid=UA-12345678-9&cid=12345&ec=button&ea=click&el=veryhappy&ev=4
v=1&t=event&tid=UA-12345678-9&cid=12345&ec=button&ea=click&el=happy&ev=3
v=1&t=event&tid=UA-12345678-9&cid=12345&ec=button&ea=click&el=unhappy&ev=2
v=1&t=event&tid=UA-12345678-9&cid=12345&ec=button&ea=click&el=veryunhappy&ev=1
Applying the Measurement Protocol
As mentioned before, the Measurement Protocol can be used to send hits from any device that can be connected to the internet, not just websites and mobile apps. This means that tracking possibilities are virtually endless, limited only by your imagination and creativity.
Email tracking
One popular application of the Measurement Protocol is tracking how often an email or newsletter is opened by the reader. When designing a newsletter, your developer could include a pixel image at the bottom of the email that includes an HTTP request containing a Google Analytics event for email opens. Using those events, you could compare your opens to your sent emails to calculate open rates, and to your resulting email sessions for click through rates, all in Google Analytics.
POS tracking
The Measurement Protocol allows you to track in-store transactions in Google Analytics and align them with your online sales. As an example, your developer could write a script for your point-of-sale register that sends an HTTP request of the transaction type to GA every time someone makes a purchase in your store, or a batch request with all the transactions for a single day. The script can include the product name, price, tax, etc. Alternatively, you could use the Measurement Protocol to track in-store coupons that customers have downloaded online.
IFTTT
IFTTT (If This, Then That) is an online tool that lets you create applets by combining hundreds of different internet services. Users can choose an action from one service and let it automatically trigger an action from a second service. One of these services is called Webhooks, that allows any trigger to make a web request, like an HTTP request from the Measurement Protocol. It’s completely automated. Just set it and forget it.
This means that you can use any of the services connected to IFTTT to automatically send hits to Google Analytics. Send an event every time you make a post on social media or publish a new blogpost, when someone subscribes or unsubscribes from your MailChimp mailing list, or when you create or update a record in Salesforce. You might even track your personal life in Google Analytics by linking your smart home devices or your Fitbit account or by sending specific text messages to IFTTT, each triggering a different HTTP request.
Beacons and hardware
There are many examples of hardware that is ideal for triggering HTTP requests to the Google Analytics servers. Physical smart buttons and beacons or, as an example, the MESH Project by Sony, which includes buttons and sensors for motion, movement, temperature, humidity and brightness. These can be linked with IFTTT to send HTTP requests whenever one of these sensors is triggered.
Using these beacons in combination with a service like IFTTT, you could send events when someone presses a specific button, walks into your store, picks up or moves an item, or when the outside temperature reaches a certain point.
As you have read, it’s easy to create and implement hits, although sometimes some developer help will be needed. The Measurement Protocol opens up a ton of possibilities for tracking hits that could never be tracked through a standard Google Analytics implementation.
