The Measurement Protocol is feature-specific to Universal Analytics, allowing companies to send data to be tracked and stored in various digital assets into a single Google Analytics (GA) interface.
Employing this method, smart companies have closed holes that have historically remained open without an easy way to stitch together key data within one single place, built and customized for analysis.
Use cases for employing the Measurement Protocol are nearly limitless. We've helped several of our clients to capitalize on this feature so that they now have greater insight into customer value and are using this information to inform their marketing strategy. A few recent examples:
For an online gaming client of ours, visibility into marketing success was previously limited to onsite metrics (sessions, pageviews, time on site, etc.) that a particular channel may have driven. Far, far away, in third-party domains, lived all the insight related to revenue driving user conversions.
Through the Measurement Protocol, data related to bets placed by an individual user is now available within GA, together with data stored by default in GA, relative to that user.
Our client has therefore revamped their marketing strategy, focused now on the channels, sources and campaigns generating the most revenue for the business.
For an online education client of ours, visibility within GA into the prospect/student lifecycle ended at form submit on the website.
The remainder of the journey for these leads was tracked solely through the university's CRM.
Through the Measurement Protocol, data related to lead quality (i.e. has a given lead been contacted) have they submitted an application, etc., is now being sent into GA to be analyzed alongside acquisition data. Our client can therefore effectively optimize their marketing strategy towards acquiring actual students vs. lead volume.
So how does it work?
Data must be sent in a certain way.
Data from your secondary digital asset (e.g. a CRM) must be sent as an event/hit into GA, accompanied by a few required parameters. The data must be sent in a specific format called for by the Measurement Protocol.
Data should be sent through an HTTP POST request. Measurement protocol requests must contain the event or pageview information as well as the following required parameters:
1.'v' (the measurement protocol version, e.g. '1')
2.'tid' (the tracking ID or the GA property ID, e.g. 'UA-123456-1')
3.'cid' (the client ID unique to a particular user, e.g. '1234567890')
4.'t' (the type of interaction collected for a particular user (hit type), e.g. 'pageview')
So that these hits sent into GA do not impact your bounce rate, it's recommended to pass an additional parameter with all requests that indicate its non-interactivity.
This can be achieved by including the parameter 'ni' with a value of '1' with all requests, i.e. ni=1.
Learn more about this parameter and parameters required that are suggested to be used with the Measurement Protocol here.
You may also review examples of common hit types.
About the 'cid'
The 'cid,' or client id, is a unique, randomly generated number by GA and is used to identify an individual user.
It is created by Google to store the user's browsing information and is normally stored in a first-party cookie (the _ga cookie for Google's Universal Analytics) on websites. On a mobile app, it may be generated randomly on the install.
If a user does not clear their cookies, their 'cid' will be tracked across multiple sessions on your site, meaning GA will recognize them as a single user. Should they visit your site from a new device or internet browser, Universal Analytics will generate a new 'cid', i.e. new user.
You may reference the _ga cookie and associated 'cid' within the Google Developer's Console, under the 'Resources' tab. As an example, this 'cid' was generated for me during my visit to Jellyfish.net today:
Since the 'id' is created for all new users to your site or is restored for return users, its value is available throughout a user's entire session and can, therefore, be sent with any site data your company sends elsewhere, e.g., a CRM.
To get started, your company should amend 'elsewhere' (the digital asset you'll be using to send data into GA using the Measurement Protocol) to receive and store the 'cid' parameter.
With that, the 'cid' available is included within requests sent to GA. This allows you to stitch together down-funnel user data with acquisition data stored in GA.
What's the 'uid'?
If your site has a login functionality, read this section!
The 'uid' or user id is not a required parameter, but if you use a login functionality, your team may utilize the 'uid' for data stitching instead of the 'cid.'
Why bother? Well, consider the accuracy your team may achieve by assigning users a unique id upon login vs. any visit to your site. Unlike the 'id' an id associated with a user's login will persist across cookie clears, browsers and devices.
The value for 'uid' must be generated by you, unlike the 'cid' which is generated by Google automatically.
Despite using the user id parameter, the 'cid' remains a requirement for Measurement Protocol hits. Therefore, it's recommended to pass a random number for 'cid' in all requests sent to GA so that the value of the 'uid' parameter can be solely used to stitch the data.
Formatting the data
For every piece of information you want to send, an individual request must be sent into GA.
Measurement Protocol requests should resemble a URL query string where each parameter has a key and value. For example, the following request would be sent to GA automatically when the event hit 'example' was completed in your digital asset for the user '1234567890.174874989.'
A secondary request is sent when any further event hits are registered for that user.
There are resources available to help you construct your own requests, such as the Google Analytics Hit Builder. The tool allows you to construct and validate Measurement Protocol hits using the Measurement Protocol Validation Server.
Keep in mind hits sent from the Measurement Protocol may not always be visible within real time reporting, events reporting should be used to validate data against data available in the digital assets you are sending it from.
If you have unanswered questions related to the Measurement Protocol after reading this post, please reach out. We'd love to hear from you.