Take These 8 Steps Now, Before Legacy GTM App Containers Are Phased Out

Subscribe to our monthly newsletter to get the latest updates in your inbox
If you've been following the news regarding Google Tag Manager (GTM) for apps, then you know that the legacy app containers are being phased out, and you're likely working on migrating to Firebase and the modern versions of the GTM app containers, if you haven’t already done so. But, if you’re like many of our clients, you’re incredibly busy and may not be paying close attention. Which unfortunately means you could also be heading for an analytics headache at the end of January 2020. First, let's be clear what we're talking about. Until June of this year, you had options when setting up a Google Tag Manager container for your app. You could use the modern container and Firebase events, or you could use the legacy version, which worked with the (legacy) Google Analytics Services SDK in your apps. The GA Services SDK was itself deprecated at the end of 2018 for Standard (Free) GA users, so relying on it wasn’t a good long-term strategy. However, in June Google announced that the legacy GTM containers would also be sunsetted. Now the only viable option is to use Firebase events and the modern GTM containers. In the long run, this approach is a good thing because it encourages the adoption of Firebase analytics, which Google has made clear will be the foundation for app analytics going forward. Are you affected?  You can check to see if you’re affected by signing into Google Tag Manager, accessing the container you are currently using in your app and selecting Container Settings from the Admin tab. If you see either of the following, it’s time to embrace the future! Originally, the legacy GTM containers were going to stop working on October 31, 2019, but Google granted a short reprieve and extended the date to January 31, 2020. Based on the latest sunsetting timeline, after January 31, 2020 you will no longer be able to make changes to your legacy GTM containers. This means you won’t be able to quickly respond to sudden needs that arise, like that Q2 2020 marketing campaign that's probably heading your way. Be aware that while the sunsetting of the GA Services SDK currently only affects users of Standard (Free) GA, this GTM container change impacts GA360 customers as well. OK, so you need to make a change. Here’s our 8-step action plan for GA360 customers:
  1. Learn about Firebase Analytics Get your dev team up to speed on Firebase, specifically Firebase analytics events. They will need to know how to implement the Firebase SDK along with the Google Tag Manager libraries for Android and/or iOS. Luckily the implementation of these two critical components is relatively easy, but getting everyone's head around the Firebase event model if they’re used to working with a Data Layer may take some time.
  2. Take an Inventory of Your Existing Implementation Take an inventory of your current app analytics implementation. Since you don't have much time, you may need to prioritize. Use this as an opportunity to identify the KPIs and events that really matter to your business and put those at the top of the list. And because you don't often get the chance to wipe the slate clean and start over, make the most of the opportunity — don't just blindly replicate everything you're reporting on today. Treat your existing implementation as a prototype, learn from it and be prepared to move on.
  3. Build a Data Dictionary Build a data dictionary documenting the MVP events you want to track in your new implementation. Think about how you want to see each event in Google Analytics, and record the event category, action and label, along with any custom dimensions and metrics you want to associate with that event. Then ask yourself where you’ll get the data to populate all these values. If it needs to come from the app, it will have to be passed as a Firebase event parameter attached to the event in question (or set in the app as a Firebase user property if it's sticky and associated with the user). Event by event, build a list of all the parameters you need the app to report, and if there's any potential uncertainty about what a given parameter represents, add detailed definitions.Review your data dictionary against the Firebase naming requirements to make sure you don't inadvertently collide with system-defined values or introduce a name that will cause your event to fail. (See the Firebase documentation for Android and/or iOS.) Firebase gives you a fair amount of naming flexibility, but that's not always a good thing: Pick simple, intuitive naming conventions and stick to them. Nothing confuses an analytics implementation like inconsistent naming — for both the developers and those consuming the analytics. (We generally recommend "camelCase" for custom names because the SDK-defined names use "snake_case.")
  4. Create an Implementation Specification Expand your data dictionary into a proper implementation spec by adding screenshots from the app and other contextual info that will help your dev team add the new Firebase event code quickly and accurately, so you measure what you intend to measure, where you expect to measure it. Implementing a well-defined Firebase event is not a lot of work for a developer, but iterating — touching code over and over again, filling gaps in unclear requirements — can be hugely inefficient and can make a mess of reporting as well.
  5. Create GTM Containers Before you hand off your spec to your dev team, take five minutes to create a new (empty) container in GTM for each app. Publish it, then download the container's json file from the Versions tab. Your dev team will need this file to implement GTM in the app, even if it's empty. (You can give them an updated version later when it's ready, but they will need a placeholder to get started.)
  6. Configure GTM While your dev team is adding the events to your app, your analyst team can start creating the new GTM tags. Generally you will want to create one "Google Analytics: Universal Analytics" tag for each event, fired by a trigger based on the name of the event. Each element of data that you'll gather from the app and send to GA will need to be configured as a GTM "Firebase Event Parameter" variable (or a "Firebase User Property" variable). The sooner you configure the tags, the better. If you overlooked anything while preparing your spec, creating the tag is very likely to uncover it. (In a perfect world, you would create all the tags before you hand off the spec, but since you don't have a lot of time, some parallel work may be needed.)
  7. Configure GA In Google Analytics, create one or more new "Web" properties with "Mobile app" views to mirror what you have now for your app(s). Does this mean you will lose your historical data in these new properties? Yes, but according to Google you're going to lose it anyway when the properties receiving app data from the legacy GA SDK are eventually turned off. (Currently on January 31, 2020 for Standard GA; TBD for GA360.) So use this opportunity to replicate what you need from your existing properties before they’re no longer accessible. (Ignore the new "Apps" and "Apps and web" property types for now. While these show great promise and will eventually become the future of Google Analytics, they’re still very much in beta and unlikely to meet most enterprise needs at this time.)
  8. Link to BigQuery To preserve up to 13 months of historical data (or up to 10 billion hits), GA360 users can set up a Google Analytics to BigQuery export. But since it can take up to four weeks for all of the historical data to be exported, it’s best to enable the export as soon as possible. You can also use the Google Analytics Reporting API to download up to two years of historical data.
  There you go: An eight-step action plan that can be accomplished in the next few months without too much discomfort. Sure, it's a bit of a hassle, but the ability to continue to report on your app analytics makes it worthwhile. And as mentioned above, in the longer term it’s a change for the best. Once you make the transition to Firebase and the current version of GTM, you'll not only have robust app reporting using the traditional Google Analytics toolset, you'll be well positioned for the future as Google further develops the Google Analytics for Firebase platform. If Adswerve can be of any assistance during this transition, please reach out. Whether you want to talk through your analytics strategy or just have a second set of eyes review your data model before your developers get busy, we do this kind of work for hundreds of clients on a daily basis — and we do it fast. Get in touch with us at sales@adswerve.com if you’d like us to do some of the heavy lifting.