Essential Techniques for Measurement Protocol: Validation and Queue Time
The consulting and engineering teams at E-Nor continue to take advantage of Measurement Protocol to meet a range of tracking needs that our clients bring to us. We also continue to discuss critical Measurement Protocol concepts on our blog so you can get closer to a universal understanding of user engagement, even when the tracking context presents specific challenges, such as limited connectivity for mobile app users (think cruise ship…).
Validate Measurement Protocol Hits Using Google oauth Playground
You may have already had the chance to reference our Measurement Protocol Parameter Reference for required and optional parameters in a Measurement Protocol hit, but how can you actually verify that your Measurement Protocol hits are well-formed as you’re writing them into your coding logic?
Use the Google OAuth 2.0 Playground to validate any HTTP request, including the measurement protocol hits. Google OAuth Playground will validate if the hit is valid or not. A hit is valid if:
it has the minimum number of parameters.
all parameters are included in the right format.
Very easy to use, the Google OAuth Playground confirms and reports all the needed information about the hit, including extra details that could be helpful for developers, including request headers and get or post request method.
To validate a Measurement Protocol hit using Google OAuth Playground:
The response now indicates that our Measurement Protocol request was good.
Verifying and Filtering Measurement Protocol Data in the Google Analytics View
You may still want to verify directly in Google Analytics that your Measurement Protocol data has been recorded. In a Google Analytics property that is recording data through Measurement Protocol and other mechanisms (such as gtag.js), you’ll need to use filters and segments to isolate your Measurement Protocol data.
If you populate the ds parameter in your Measurement Protocol hit, you can segment or filter based on the Data Source dimension:
Using the Data Source dimension to segment Measurement Protocol data in a Google Analytics views
If you don’t send the ds parameter with your Measurement Protocol hit, you can filter and segment based on any unique parameter or custom dimension that you do send.
Queue Time Parameter for More Accurate Offline Interaction Timestamping
Queue Time (qt) is an optional parameter, but it can be really useful for the purposes of:
recording hits with the time at which they actually occurred if the sending of the hit has to be delayed.
ordering hits.
Queue Time: Record a Measurement Protocol Hit with the Time of Interaction Rather than the Time of Hit Send
The fundamental functionality and benefit of queue time is that it allows you to send a hit to Google Analytics later than the corresponding action but still report that action with the time that it occurred.
Queue Time can be critical for reliable tracking in that mobile app scenario (if you’re using Measurement Protocol to track a non-iOS or non-Android mobile app, for example). As a few specific considerations for queue time:
You provide the time delta in milliseconds.
The value must be greater than or equal to 0.
Values greater than four hours may lead to hits not being processed. This is the most important point, as you could lose a significant amount of data if you set the queue time for more than four hours.
Also, using the Google Analytics batch (https://www.google-analytics.com/batch) endpoint, instead of the collect (https://www.google-analytics.com/collect) endpoint, in addition to the Queue Time parameter, will give more control over the sending order because you can send up to 20 hits at a time per batch request with 16k bytes as maximum payload.
Ships Ahoy
One challenge that the E-Nor engineering team faced was tracking user interaction with an app that was likely to be used aboard ships.
Measurement Protocol with Apps for Android, iOS, and Operating Systems
In the case of an app developed for a non-Android and non-iOS operating systems, such as Microsoft or Blackberry mobile devices, you need to use Measurement Protocol for Google Analytics tracking. In the case of the iOS or Android version of the app, the Firebase SDK can usually take care of all underlying logic for sending hits with the optimal parameters; however, you may still want to use Measurement Protocol for Android or iOS if there is a possibility of losing the connectivity for more than 28 hours (24 hr/day +4 hours latency). Using the SDK, data must be dispatched and received by 4 AM of the following day, in the local time zone of each Google Analytics view (profile). Any data received later than that will not appear in reports. With Measurement Protocol, you can send data whenever connectivity is restored. Because the maximum queue time is four hours, the timestamps in the data may not reflect the actual time of user interaction, but at least the data will be recorded.
The tracking steps included:
Check for connectivity.
If connectivity is good, send a Measurement Protocol hit without the queue time parameter.
If connectivity is not good, store the user interaction locally (as XML, or with any suitable persistence mechanism), making sure to save the timestamp at which the interaction actually occurred.
Recheck for connectivity at regular intervals.
If connectivity is good, send a Measurement Protocol hit with the qt parameter representing the difference in milliseconds between the time the timestamp of the user interaction and the time the hit is sent.
For instance, the Measurement Protocol hit below would record a user interaction as having occurred 88 minutes – or 5,280,000 milliseconds – before the time of good connectivity at which the hit is sent:
What if the user is offline for more than four hours?
The maximum value that you can specify for the queue time parameter is four hours, or 14,400,000 milliseconds. If your users are on the high seas with no connectivity for several days, you can code your own logic to send the Measurement Protocol hit whenever connectivity is restored, but you can’t set qt to more than 14,400,000, or you risk dropping the hit. Abiding by the four-hour rule, you may have user interactions reported as occurring later than they actually did, but, importantly, you’ll still know that they did occur.
Have questions about measurement strategy? Contact us today.
