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:

1. 1. Open Google OAuth 2.0 Playground.
   2. Choose the API you want to use (Google Analytics in our case) and click Authorize APIs.

1. 1. Ignore step #2 and move directly to step #3 (Configure request to API).

1. In the Request URI field, add this sample hit and send the request:
   
   https://www.google-analytics.com//debug/collect?v=1&t=event&tid=XX-XXXXXXX-X&cid=5555&ds=crm&z=123456&ec=OffSiteTransaction&ea=CRM&el=TransactionSuccess&ev=100&qt=560&cd1=126555C-1715551RTest&cd7=CreditCard&cd8=Platinum&cd9=100&ti=1234-1234&tr=100.00&pa=purchase&pr1id=standard-current-account&pr1nm=standard-current-account&pr1ca=foreign-exchange&pr1ps=100.0&pr1qt=1
   The response will indicate that the request was not valid.

We forgot to specify a valid tid parameter, that is, a Google Analytics property ID. Let’s try again with a valid tid parameter:

Queue Time Parameter for More Accurate Offline Interaction Timestamping

Another of our previous blog posts considered Integrating the User Journey with Google Analytics: Three Offline Business Cases. What about a tracking scenario that is offline in the sense that the user is interacting with a mobile app on a device that may be suffering from spotty internet access?

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 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.

The tracking steps included:

1. Check for connectivity.
2. If connectivity is good, send a Measurement Protocol hit without the queue time parameter.
3. 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.
4. Recheck for connectivity at regular intervals.
5. 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:

Have questions about measurement strategy? Contact us today.