Considerations for Google Analytics and PANTHEON_STRIPPED
Information on why PANTHEON_STRIPPED is placed in the utm_source URL parameter.Discuss in our Forum Discuss in Slack
Variables that are converted to
PANTHEON_STRIPPED cannot be read with PHP, and original values will not appear in the
Issue: PANTHEON_STRIPPED Displays in the utm_source URL Parameter in Google Analytics
This is typically caused by PHP in your site’s code reading in
PANTHEON_STRIPPED as part of the url that it sees, and then using that in a page response in such a way that shows up in a customer browser, it will then be dutifully reported to Google. Pantheon makes every effort to prevent this, but it is not possible to predict all possible PHP behavior. In most cases, it's safe to simply ignore
PANTHEON_STRIPPED in your traffic results, as usually customers will have hit the site with a valid parameter first, and the
PANTHEON_STRIPPED values are duplicate "self-referrals".
You may also experience unexpected behavior when you overload Google's
utm_ parameter namespace. The URL parameters that Google Analytics uses are specific to their platform and are not intended to be extended by site developers. Using it as a general tracking parameter with patterns like
utm_mytrackingparameter is discouraged. Please refer to Google Analytics URL Builder for a list of the valid
Redirection and PANTHEON_STRIPPED
If you redirect a request that contains
utm_ parameters, Pantheon's edge should be able to preserve the original values. It's always better for campaigns to avoid sending customers to a page that redirects (e.g. to the www domain, or to https, or to an updated url), but sometimes this can't be helped.
You can see this for yourself by testing how Pantheon's own public facing website behaves. Try requesting the homepage over http with a
curl -I http://pantheon.io/?utm_campaign=documentation_example
HTTP/1.1 301 Moved Permanently Cache-Control: max-age=3600 Content-Type: text/html Date: Fri, 12 Feb 2016 00:19:51 GMT Server: nginx X-Pantheon-Endpoint: 2c1830ae-a962-46b8-844a-5cbd437bb525 X-Pantheon-Styx-Hostname: styx94699a92 X-Styx-Build-Date: Tue Sep 8 20:14:49 UTC 2015 X-Styx-Build-Num: 975 X-Styx-Build-Sha: 75058451cd2e622496298f556cda4ba5248e3ab6 X-Styx-Req-Id: styx-633d1e17bd17cbbd335145ca26c855bd X-Styx-Version: StyxGo Content-Length: 0 X-Varnish: 891633459 912361636 Age: 15 Via: 1.1 varnish-v4 Vary: , Cookie X-Pre-Strip-Debug: utm_campaign=documentation_example Location: https://pantheon.io/?utm_campaign=documentation_example Connection: keep-alive
Note that the resulting
Location header, which is where a browser would bounce to, still has your
utm_campaign value in addition to being on https. That's great. We also include a special
X-Pre-Strip-Debug header to help with debugging.
However, as far as Pantheon's application environments are concerned, the value coming in was
Query keys will still be passed to the application container, but the values will be changed to PANTHEON_STRIPPED to indicate that the URL is being altered. Looking in the
nginx-access.log you would see something like this:
nginx-access.log:10.223.193.24 - - [26/Jun/2015:17:12:52 +0000] "GET /utm_campaign=PANTHEON_STRIPPED HTTP/1.1" 301 5 "https://www.google.com/aclk?sa=l&&ctype=4&clui=3&rct=j&q=&ved=0CB4QwgUoAg&adurl=https://example.com/features%3Futm_source%3Dgoogle_adwords%26utm_medium%3Dcpc%26utm_term%3Dmam%26utm_campaign%3Drlsa_mam%26utm_content%3Drlsa_mam_broad" "Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F70 Safari/600.1.4" 0.002 "184.108.40.206, 220.127.116.11, 10.189.246.4"
Please note that this behavior only holds for HTTP redirects with a status code of 301 or 302, and only if the resulting redirect URLs parameters remain the same as on the way in. It is possible for your PHP code or CMS to pick up
PANTHEON_STRIPPED and place it in a link that users are invited to click, or to issue a redirect that re-formulates the structure of the url to the point that we cannot restore the original parameters.
We recommend distributing campaign URLs that are in their final, non-redirectable form and avoid using PHP redirects.
Finally, to optimize caching performance, make sure any parameters are in the supported format, as those that are not in the format utm_ or are preceded by double underscores will instead act as query keys and be served and cached as distinct pages. You can build campaign links in the correct format using Google’s URL builder tool.
For more information, see Caching: Advanced Topics.
Which query parameters are optimized?
Any URL query parameters (GET requests) matching the following criteria will have its value replaced with
utm_*-- Matches standard Google Analytics parameters
__*(two underscores) -- Matches conventional content insignificant query parameters
How do I test my Google Analytics or Google Ads (AdWords) URLs on Pantheon?
You can use curl or wget to perform a simple test to see if PANTHEON_STRIPPED is appearing in URLs generated with the Google URL Builder:
# example using curl and grep curl -i "https://live-mysite.pantheon.io/landing_page.html?utm_source=test-source&utm_medium=test-campaign&utm_term=test-term&utm_content=test-content&utm_campaign=test" | grep utm
What if I have a link in the wild that’s not in its final, non-redirectable form?
To resolve these links before they hit the application, place the following within
settings.php (Drupal) or
// Remove query strings and tracking parameters from URLs $strip = array('/[&?]__.+?(&|$)$/', '/[&?]utm_.+?(&|$)$/'); $_SERVER['REQUEST_URI'] = preg_replace($strip, '', $_SERVER['REQUEST_URI']);
Adjust the regex as required to match your link's parameters.
Why doesn't Google Analytics match Pantheon's traffic metrics?
Google Analytics focuses on measuring visits while our request log more comprehensively measures traffic. For more details, see Traffic Limits and Overages.