Google has just announced an exciting new update to its Google Analytics product - integrated App and Web Properties. The new properties unify data across different user interfaces into one place, allowing for centralised analysis of your user interactions.
On the surface the change seems simple enough - enabling the tracking of both Web and Apps in a single new property type, namely "App and Web". Historically Google Analytics customers have had data in separate silos - Web data in Google Analytics and App data in Google Analytics for Firebase, so this is already a big win for businesses with different user interfaces to perform the same action.
This is far more than a skin deep integration though, the Web and App properties have a new data model for sending data to these new properties which sets the foundations for huge changes in future Google Analytics tracking and analysis capabilities.
These new property types, will be available to all Google Analytics (both standard and 360 customers), in a beta form, over the course of the next few weeks. We would suggest not immediately jumping ship from Standard Analytics, as we know that some features will be missing for launch and it is, after all, a beta product and subject to potential issues and changes!
[caption id="attachment_3168" align="aligncenter" width="750"] Combined Web and App user report (Source: Google)[/caption]
Web property or Web and App property?
Interestingly, Google isn't currently pitching this as a replacement for the current Web-based Analytics proposition (as they did with the release of Universal Analytics), rather as an additional integrated product for use when you have mobile apps and a website. So in that regard, Google hasn't (yet!) put a deadline on when you would need to transition across to App and Web, nor is it clear whether the traditional model is here to stay or if the roadmap has plans to move everyone to this new event-based data model.
Just because this property type is labelled "App and Web" doesn't mean you must have an application to take advantage of new property type and its data model. Once the new property type is at feature parity with the Web property I see little reason to avoid moving across, and suspect the event-based data model to be the norm in a few years time.
The new Web and App properties are effectively a hard reset of what we know of tracking within Google Analytics, Google hasn't tried to slowly integrate the new data model alongside their existing one. The new property types will require a completely different approach to tagging your website and applications. This will mean, to take advantage of App and Web properties, you will need to re-tag the website (or if you're using Google Tag Manager - alter your tagging there).
Why we're excited - a new event-based data model!
We get a little geeky when new "toys" are released by Google, however this one really does deserve it, this change is huge and is where we had hoped Google would evolve their Analytics offering. In short, Google is following the trend of flexible event-based models from other Vendors, and introducing a new flexible event schema.
The, often inflexible, Category, Action, Label, Value structure of current events is being thrown out and replaced with a new flexible event schema that allows for custom parameters to be defined for any given event. Essentially, there will be no need to wrangle your events into a fixed schema, instead we'll have flexibility over how we define and present our event data.
For example in the current interface, to track a download you might use an event such as:
Event Category: Download
Event Action: <Download Name>
Event Label: <Download URL>
However, this structure is often restrictive, what if you want to include some context of where on the page the download occurred, the file type etc? Currently this would mean widening the dimensions of Google Analytics with Custom Dimensions, keeping track of which dimensions are for which events in a separate reference and wrangling the data out in reports, not ideal. Or, what often happens, the attributes get prioritised and you drop the additional data for the event, losing what could be important data in favour of fitting with the existing structure.
This is exactly what a flexible event-based model is built to support, you're not confined to a fixed set of dimensions (Category, Action, Label) instead, when you trigger an event you define your parameters that are named appropriately for the event in question - no more referring to internal documentation to decipher the 50 different events on the website and how they're structured.
Using the download tracking example, you'll be able to do the following:
Event Name: Download
Name: <Download Name>
URL: <Download URL>
File Type: <Download File Type>
Context: <Download Context>
We're really excited with the direction Google are taking their Google Analytics product and only expect to see more developments over the coming months. Once we get our hands on the new features we'll share more - watch this space!
Read the official announcement from Google:
Auditing your Google Analytics account for query parameters can be tedious but helps keep page reports clear of unwanted row duplication. We talk about the effects of collecting unwanted queries on your reporting and how to fix it. We’ve also built a free tool to make the process easier.
When a form has been successfully submitted to HubSpot, HubSpot propagates an event that we can listen to and use to trigger marketing tags within Google Tag Manager. Below we create a Custom HTML Tag that listens for a form success, trigger a dataLayer event which can then be used to trigger a marketing tag to push this data into Google Analytics.
Service Provider and Network Domain dimensions are no more. Let’s get Service Provider data back online. We’ll show you how to re-enable ISP data using Google Tag Manager and an IP Lookup Service.
Track when users leave your site to visit your social media pages. Understand when your content is driving positive move to your social assets.
The use of social sharing widgets is commonplace. But who’s actually tracking interactions with these? Let’s make a count of how many people are clicking these buttons and record a social share rate to see how many readers amplify content on social media.
Anybody who uses DoubleClick Floodlight knows the slow process of implementing a new tag for each activity for a campaign interaction or conversion. If you’re using Google Tag Manager to add a tag, trigger and maybe some new variables for every new Floodlight – it won’t take long for your container to overfill with almost identical tags. While there’s nothing wrong with this style of implementation, there is another way.