HSTS is generally enforced by the server responding with a HTTP header similar to the below that says “get the HTTPS version instead due to HSTS”.
There is also a list of sites that the latest browsers can refer to that should be using https with every request. This list is used when a user has a fresh install or has recently wiped their local data.
How it affects Google Analytics
In the past, when HSTS wasn’t enforced on the www.google-analytics.com server, you’d only see one request to utm.gif (for sites using Asynchronous Google Analytics code) or collect (for sites using Universal Analytics code).
Now with HSTS headers being sent back to your browser you’ll notice two requests in Chrome’s network tab (Ctrl+Shift+i) for both versions of Analytics tracking code.
With this recent change, developers and Analytics debuggers alike may come to the wrong conclusion and think that hits are being double counted; but that’s not the case.
Look into chrome://net-internals/#events when reloading the page and you’ll see that one request is made to Google Analytics and it’s being redirected immediately to the HTTPS version.
As the server immediately responds with a “go look over there” message, Google Analytics won’t process the hit.
You’ll see the multiple network requests on sites that use the plain HTTP protocol, as sites which use HTTPS should be requesting the HTTPS version of the Analytics domain.
Do you need to do anything?
You won’t need to do anything to your Google Analytics implementation as nothing’s “wrong”.
But if you, or your developers are going to be checking Analytics requests through the Network tab, bear HSTS in mind. Using Google Tag Assistant for Chrome knows that the redirect isn’t sending duplicate hits.
If you’d like to do some further reading, here are some links that’ll explain HSTS in more detail and how Google Chrome implements it.
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://www.chromium.org/hsts
And get in touch if you’d like to discuss HSTS and Google Analytics further.