The Problem with RTP eStore and Analytics
For over a decade Active Network’s RTP|One eStore has only been configurable for classic Google Analytics (GA) tracking (ga.js). This would be fine if was still 2011 and we were all still raving about the Motorola Droid, but its not and we’re not. Today Universal Analytics is Google’s latest and greatest freemium-based product and pricing model. Benefits to upgrade to Universal include better user session encryption, mobile app tracking, enhanced ecommerce tracking, and a handful of other helpful new reports and configurations settings.
All this is great, but at the end of the day you can still technically use Classic GA, if you are a single website using a single ecommerce platform (like RTP). If you are a robust destination marketing/sales machine that requires multiple ecommerce platforms selling various products like lift tickets, lodging, food, season passes, parking, event tickets, gym memberships, and golf rounds, you likely require at 2 or more other ecommerce software platforms. Many of those other systems are also commonly built to work with Universal GA.
Some of the GA reporting works fine if you run both GA methods simultaneously, but not attribution data which is the source of the user session (paid, social, email, display, referral). This is not good at best, and a huge data loss at worst. Additionally by using both Classic and Universal GA in parallel, you will spawn redundant child sessions, inflate bounce rates, and render most of your session data inaccurate.
Long story short: RTP only allowing Classic GA is bad.
We use Universal Analytics everywhere else
Our initial hope was that RTP would eventually come to terms with the rest of the world migrating to Universal GA and they would say ‘wow, we need to get our s#!t together and support our clients analytics needs’, but its been 5 years and absolutely no software development in the ‘right’ direction concerning analytics and the eStore.
The eStore is self-hosted and our clients have access to the code. It was time to take it upon ourselves to rewrite the code, since it was obvious that RTP had no plan to update Google Analytics tracking support.
Then the fun started …
More Options: Standard eCommerce is nice, Enhanced eCommerce would be better
Since we were already planning to convert RTP’s ecommerce script from a manual Classic push to standard ecommerce, we figured that we might as well go all out and create an additional option for enhanced ecommerce tracking.
… What if we could use GTM
In a perfect world, we would love to use Google Tag Manager and its dataLayer to control all of this tracking. It allows our clients (and us) to easily manage, maintain, and support 3rd party tracking scripts and inject dynamic ecommerce values, track Video embed interaction, scroll depth tracking, and an arsenal of other awesome features we haven’t blogged about yet.
GTM, Google Analytics eCommerce and RTP eStore – The Working Solution
What didn’t work and why
This was a labor of love (on behalf of our clients) which took lots of trial and error.
We initially tried to utilize RTP’s native analytics manager, but eventually realized that it was inconsistently reporting ecommerce results from the dataLayer push due to that function now loading within the main asp.net page form (which is not advised).
After this realization, it quickly became obvious that our only option to get this working 100% with Tag Manager was to completely remove it and the dataLayer from RTP’s administrative framework and place it directly into the source code of the theme itself.
The solution that did work
Once relieved of RTP’s antiquated analytics setup and it’s limitations, we were looking at a fairly straightforward GA and GTM configuration. The biggest hurdle now was to rewrite the existing classic ecommerce push function to it’s dataLayer equivalent.
Credit: While many other resorts we work with have been interested in converting RTP to Universal, SunValley was absolutely hellbent on on the solution and graciously offered their store to be used as ‘guinea pig’ in this endeavor. Thanks to them and their Developer at Stronach Consulting for helping this data-dream become a reality!
Step 1: (Mostly) purge native analytics fields
// **SCRIPTFILE** – DO NOT REMOVE THIS LINE
Yes, really. WTF RTP?!?!
Step 2: Load GTM
Google recommends loading the GTM container <script> in the <head>, and the <noscript> at the top of the body. It was now added directly to the theme’s master page template.
Step 3: Add your converted ecommerce dataLayer.push
Again this needs to happen outside of any <form> element. You can probably load this in 10 different places and really optimize your workflows, but we decided to load it in the same master page template that we originally added GTM to, to keep it simple.
Since we are technically allowing the dataLayer to be presented on every page (standard practice), we needed a few conditions to make sure anything related to ecommerce wasn’t empty and creating any errors on pages where transactions where not taking place (meaning anything not equaling the confirmation page).
This was achieved by adding a few simple ecommerce conditionss: first a condition to make sure there has been a transaction, then a second condition to verify a transaction and order id exists.
Then we built out the transactionProducts loop using the pre-existing RTP transaction variable objects loading in the conversion page. Then wrapped it up with call back to the loop and push to the exiting dataLayer global variable initially declared.
Once it was working for standard ecommerce, repurposing it for enhanced ecommerce was just a matter of renaming the key names specific/required for the ‘products’ loop…
…And modifying the ecommerce purchase action with all the required enhanced keys and values.
Proof is in GA Pudding
We’ve now got Universal Google Analytics tracking on the website front end, other 3rd party booking funnels, AND RTP’s eStore. The data is accurate and consistent. All is well.