We’re done waiting ! After years of non-progress Google officially announced yesterday their massive step towards unification of data coming from applications and web platforms in GA : Web + App Properties.

Image Source : Google Blog

In a context where people are interacting when and how they like with a brand, being able to get insights from their cross-platform journeys has become critical for businesses to understand customer needs, and provide better experiences.

The new feature Google released is definitely a step in that direction.

Web + App Properties - What does it mean?

Basically, you’ll now have the opportunity to create a new property type in Google Analytics, which allows you to combine both App and Web data in one single unified property.

This means access to reports that use one single dataset of consistent metrics and dimensions for all your platforms, making it possible for you to see fully integrated reporting across Apps and Web.

Wonder which marketing channel is driving most users to your business, whatever it is on your website or your app? How many unique users you have? How many conversions happened on your website and your App? Well, you can now have all these answers in one single place.

Why should you care?

Today, if you have both an App and Website, you’re collecting and analysing your data in separate environments : Google Analytics for Firebase (GA4F) for your App, and Google Analytics for the Web.

Does it make sense for your business to keep looking at this appart while most KPI and needs are the same ? Very unlikely.
Web + App properties is a simple way to cover this, and it’s only the beginning.

Let’s introduce... Enhanced Measurement !

The crucial element that enables all of this is a new data model. Google will be moving away from its traditional Session measurement that Google Analytics has been using over the last decade. Instead of that, they are moving towards an Event model, quite similar to the one that is used already within Google Analytics for Firebase (App Tracking) or some other technologies such as Mixpanel, Amplitude & Segment. Basically : a whole different data-scheme.. Exciting !

It’s quite a big shift, and it seems that GA teams understood that it might be a heavy move for business to re-implement, so they’re trying to make the transition smoother with a new amazing feature : Enhanced Measurement.

Image Source : Google Blog

Simply said, this feature aims to detect some of the most common events that you may want to track, and give you the opportunity to automatically track those things, such as Page Views or Scrolls on pages - all this directly from the Admin panel. Say bye to the manual work of tagging some events on your side with extra code !

Note that for now, only a limited list of events are added, but we can expect that Google Analytics team might keep building this out to a much more extensive and easy-to-use tracking system.

Good news never comes alone : New Reports for Cross-platform Analysis !

Together with this, Google also offers more flexible tools to help you make sense of your data, and gather insights out of it : the new Analysis Module.

This module enables you to look into your data the way you want, without the limitations of pre-defined reports. Here is a non-exhaustive list of techniques you’ll be able to use :

• Exploration : Visualize your data easily through a drag & drop interface allowing combination of multiple elements (dimensions, metrics, ...)

Image Source : Google Blog

• Path Analysis : help you visualizing actions taken on the user’s Path.

Image Source : Google Blog

• Funnels : Understand & discover sequences of events your users are undertaking on your website and app.

Image Source : Google Blog

That’s only a preview of the many new reporting features that come with this update. More details about this in a next article.

Practical information

You might wonder how and when you’ll be able to try this out ?
Good news - the feature is currently being rolled out publicly (Open Beta) and should be accessible for most business that are eligible ( = that use GA for Firebase already) in the coming weeks.

All you have to do once you’re whitelisted is to activate the feature. For that, two options :

1. Create a new App + Web Property in GA
2. Upgrade an existing Firebase Project.

All you have to do now is trying this out, and enjoy !

No doubts that after reading all this, you’ll be as excited as we are about what’s next here. We’re currently deep-testing the feature, so stay tuned - more articles to come on this topic.

{snippet cedriclequenne-en}

Segment positions itself as a Customer Data Infrastructure or CDI. What that actually means is that they see themselves as the glue that binds any and all customer data points in order to create a holistic view of all interactions of a company with a customer. They don’t limit themselves to web data or CRM data. Their solution aims to bridge & unify all existing data silos.

In order to do so Segment spans a series of areas:

1. Data collection

Starting a Segment implementation track starts with building a tracking plan. This means we’ll be looking which elements should be tracked, which metadata should be attached to each element (Segment calls this properties) and how and when to identify users together with their associated traits. Segment uses a specific syntax that consists of different commands to track events or identify users. As the term CDI insinuates Segment is a core infrastructural element. Therefore implementing Segment requires the work of developers. Where more classic data collection technologies such as Tag Management Systems focus on deploying marketing tags only by piggybacking on the existing infrastructure (such as a dataLayer), Segment’s focus goes way beyond that (and thus requires a different setup). Segment is capable of ingesting data from all kinds of sources such as websites, applications, databases, CRM’s, advertising platforms, payment systems, etc.

2. Quality assurance & control

As Segment’s objective is to collect data once, stitch it together & dispatch it to a series of applications, it’s rigorous when it comes to data quality. Segment comes with built-in quality assurance capabilities called protocols (think of the likes of Hub’Scan or ObservePoint). Protocols verify any incoming data points and compare it against the initial tracking plan and expected results. As soon as non-compliant elements are being ingested by Segment approval to process the data will be requested. Segment users can choose to allow these data points or to omit them from being passed on to the applications connected to Segment’s CDI.

3. Unification

Segment’s main objective, next to collecting clean data, is to ensure unification. Segment uses a userID using an identify method to track users & unify data across all of their interactions. This means that separate interactions on different platforms such as web, application & even call center can be stitched & attributed to a single user.

4. Data library building

Once data passes the QA & control procedures data is ingested in Segment’s data library or schema. This library is then used to dispatch data to any output application. This is now the collection of master data from which all other platforms & applications will be fed.

5. Data dispatching

From the data library additional applications can be connected. Think of things like analytics solutions (Google Analytics, Mixpanel, Amplitude, etc), CRM systems (HubSpot, Salesforce, ect), advertising platforms (Facebook, DoubleClick, Criteo, AppNexus, etc), Raw data storage (Redshift, Bigquery, Snowflake, etc) and many others.

Even though this is a very short introduction and it only addresses a fraction of Segment’s capabilities, it’s clear that Segment is a new breed of products focused on building data pipelines that consolidate all data point around a single customer in order to derive actionable insights & put them into play. Are you looking for clean & unified data at user-level in order to feed systems that provide insights on the customer journey or build applications to enhance it, then Segment is your go-to platform.

{snippet glennvanderlinden-en}

If you ended-up reading this article, you probably know what an iFrame is and the struggle it can bring when it comes to tracking. If it’s your case, then you can jump to the concrete material of this article and the first alternative.

For the others, here is a definition of an iFrame (source: https://techterms.com): “An iframe (short for inline frame) is an HTML element that allows an external webpage to be embedded in an HTML document. Unlike traditional frames, which were used to create the structure of a webpage, iframes can be inserted anywhere within a webpage layout.” In a nutshell, an iframe is a page within a page.

Why would you need to insert a page within a page? you might ask. Well, first, you should not. IFrames are horrible to track and will probably affect your data quality before you know it.

Why do we still encounter iFrames if they are so vicious and awful to track? Economies of scale or easiness will probably be the two main reasons for iFrames survival. To give you a concrete example, a typical iFrame can be a form. If a development agency built a form for a website and needs the exact same for another one, they will probably insert the original form in an iFrame to be fast and just adapt the layout to the parent frame (main website).

In this article, I will provide you with what I believe are two effective ways to track iFrames after hours of struggle trying to track them the best way possible. Hopefully I can spare you the hassle and make your life easier.

1. iFrame decorator

The first option for tracking iFrames comes from Google Tag Manager guru, Simo Ahava, who shares the same opinion as I do on iFrames.

In his solution, Simo uses a customTask that leverages a setInterval() and decorates the iFrame whenever he finds one. Using a custom script, every x seconds (you can choose the interval yourself), the TMS on the parent frame will look for iFrames in the page that matches the CSS selector you mentioned in the script. When he finds it, he will decorate the iFrame path with the cross-domain linker parameter. This means that the URL of the iFrame will have the _ga= cross-domain linker parameter, which will be used by the cross-domain tag on the parent frame with the allowLinker set to true.

If everything was not clear, this visual representation should help you:

The full script can be found in Simo’s article.

2. postMessage using dataLayer.Push

In this second alternative, we use a more radical approach than the first one. Indeed, where we had a Tag Management System on both the parent frame and the iFrame in the first example, here we will send every hit to Analytics from the parent frame, even the interactions that are coming from the iFrame.

To do so, we will use a Javascript function called postMessage. This function is composed of a message and a targetOrigin. Concretely, we will send a message from the iFrame that will be read by the parent frame. We will thus send our tracking information to the parent frame and push it to the dataLayer. In order for the parent to be able to read the message sent from the iFrame, we will need to install a listener on our parent frame.

Here is a visual representation of the solution:

In terms of data quality and robustness, the second option is probably the best one, but it will require some additional efforts from your development team/agency.

Remember that iFrames should be avoided whenever you can, but if you need to deal with one, hopefully those two proposed solutions can help you manage it without losing too much hair in the process.

{snippet gregoirelehardy-en}

The ranking of your app will depend a lot on the selection of the keywords. This is true for Apple Store and Google Play.

We would recommend you to really take the time for this step because the most common mistake is to directly select keywords that generate most of the traffic and only focus on those. While this keywords are also targeted by thousands of applications. This has an impact on the probability to rank high in the app stores for those specific queries especially if you have a quite new app without any ranking historical data.

The approach we recommend you consist in making a ponderation of three factors:

1. La difficulty for your app to be ranked in the store with regards to those keywords (Chance Score). This metric is an estimation of the probability for your app to be ranked in the top 10 with regards to that query. This score is measured on a scale of 0 to 100 with 100 as an indicator of the easiness to be ranked for that query. So if you have a score of 95 it means you have a high chance to be ranked on that query because not a lot of apps use it.
2. The score of the keyword (Search Score). This score is an estimation of the volume of search for that specific keyword. It is also measured on a scale of 0 to 100. If a keyword has a score of 100 it means users a lot this terminology.
3. The number of applications that target this keyword.

In the example hereunder, we are hesitating between three keywords (x,y,z). For each keyword, we have each element mentioned above (chance score, search score and the number of applications targeting that keyword). By taking the ponderation into consideration, the keyword X should be used to improve ranking in Apple store while for Google Play it is keyword Z

You are probably thinking “thanks for all those definitions but where do I start, which tool? Which keywords to test first?”

I would recommend you to start with keywords/queries at your disposal. If you have a Google Search Console or Google Analytics, you can start with keywords that generate of click with a good click-through rate. In case your Google Search Console is linked to Google Analytics, you can even go a step further by selecting keywords based pages/session. If you really do not have access to those tools, do not worry, you can start with other tools such as Mobile App Action. The tool allows to find keywords and included the three parameters we mentioned above. In addition, it allows you to monitor your competition and the icing on the cake is that there is a free version of the tool.

Other tools that could help you analysing the traffic generated by specific queries :

• Appkeywords (for the selection of keywords)
• App Annie (allows you to analyse keywords and monitor competitors)
• Overpass (help you to find keywords on App store, & Google Play with the possibility to select the goal: awareness, score, suggestion)

In summary, you need to take time to select keywords that will be used in you ASO strategy since based on the type (iOS, Android) of the app the segment to optimize, you will be limited in terms of characters ( as discussed in the article 1 1 & Article 2 of this series). Moreover, this helps you to maximize your potential to rank high in stores.