Category Archives Google Analytics

How to Create Calculated Metrics in Google Data Studio with Blended Data Source

published by on 5th November 2018 under Google Analytics, Industry News

Or How to Create Bespoke Conversion Rates

Last week, GDS released a new feature called chart-specific calculated fields.
I decided to write a quick post to describe this as the documentation is pretty scarce…

The main interest of this feature is that it works with blended data sources. Even if you can’t create a calculated field at the data source level, this is pretty useful to for instance create conversion rates metrics of user or session-based segment XYZ versus all users or sessions.
Thus you can get conversion rates for anything, without having to create a goal in Google Analytics. For instance, you can see
- what’s the % of total sessions with event XYZ
- what’s the % of total sessions with view of page XYZ
- etc.

So here is how to create this from a Google Analytics data source:

1. Create your segment in GA

For instance, Sessions that include a specific event (below a click to Flight Information – that’s from an airline site)

GA segment

2. Create the blended data source

Below, I’ve blended a GA view with the same view but applying the newly created segment.

I’ve added the Sessions metric for both of them but renamed the sessions looking at the specific segment to avoid any confusion later on.

I’ve also added the Country dimension as a joint key, but this is optional.

So you should end up with at least 2 metrics in your blended data source; All Sessions and Sessions from Sessions including event XYZ:

Note that the data source without segment must be the first one (in the left) as it will take precedence over the data source using segment in the right. This is critical when/if using join key(s).

blended data source

3. Create a new component (chart)

create chart

4. Create the calculated metric

Click to select a metric, then CREATE FIELD:

click create field

Type the name of your new calculated metric and enter your function, then select the Type (Percent below as we are looking at a conversion rate):

create calculated metric

And voila!

chart 1

5. Copy to re-use

The calculated field is specific to the chart but you can just copy-paste the initial chart to avoid having to create the calculated metric again.

chart 2

Note: When using a table, don’t enable the “summary row” as it will sum up the conversion rates… (I believe this is one of the limitation of having the calculated metric defined at the component level and not at the blended data source one).

Hope this is helpful and let us know how you use this new chart-specific calculated fields :-)

Related posts

Measuring page load speed for single page apps

published by on 24th September 2018 under Google Analytics

Single page apps are always a battle for a robust Google Analytics implementation. From correct page titles, rogue referral problems, to when to fire page views, nothing is inherently simple. To add onto the list of complications with single page apps is the fact that Google Analytics will not provide page timings (once loaded between internal pages) for SPA’s. This includes if you increase the site speed sample rate to 100. This is because Google Analytics calculates the page timings using the Navigation Timing API.

For example, DOM loaded would be:

$(document).ready(console.log(( - 

To over come this problem, you will need to use custom metrics. The solution has three steps.

1) Set up a custom metric in GA.

Go to Admin > Property > Custom Definitions > Custom Metric.

Create a new Custom Metric, with the scope of Hit and the formatting type of time. Note: Specify time in seconds, but it appears as hh:mm:ss in your reports.

2) Set up a timer.

You will need to capture the time when you want to start the measurement of page load time.

An example solution to this might be by decorating all of your internal links. For example in Google Tag Manager we could set up a Custom HTML tag:

  time1 =

3) Send the time eclipsed (in sec) to Google Analytics on the virtual pageview event.

When the virtual pageview event occurs (which triggers your virtual pageviews), retrieve the difference between the current time ( and the time which the timer was started (time1).

Using Google Tag Manager, a Custom JavaScript variable (e.g. SPA load time) can be created as below:

  return ( - time1)/1000

This value then needs to be sent with the pageview, against the custom metric index set up in step1.

SPA pageview example

Using the custom metric along with calculated metrics (e.g. {{virtualPageTimings}}/{{pageViews}}, you will be able to calculate your average virtual page timings.


To make the measurement more accurate, set up a secondary custom metric to count the number of virtual pageviews. This will make sure that landing pageviews are not taken into consideration.

To do this, create a custom metric with the scope hit and the formatting integer.

Then with every virtual pageview, send the value 1 against the custom metric index. E.g:

SPA page load speed 2

This allows for the calculated metric:



Using this calculated metric will then give you a good idea of how long a SPA page took to load, from the time which a user clicked on a link through to that page.

This is just one aspect of what is needed to be taken into consideration when working with single page apps. Feel free to reach out if you require any assistance tracking your SPA.

GDPR: Scope, Consent & Impact on (Analytics) Tags

published by on 9th May 2018 under Digital Strategy, Digital Trends, General, etc

It’s coming and let’s face it, whilst we’ve been warned since 2016, very few started thinking about it more than 6 months ago if not later…There are a lot of resources out there trying to translate what GDPR means and how it will impact businesses’ organisation and data management but very few manage to give clear and practical guidance. This post is an attempt to provide concrete answers about the user consent mechanism and its impact on web analytics. Of course, the usual caveat: “I’m not a lawyer and you should seek legal advice to assess your own situation and blablabla”….But even if you seek legal advice, you may end up knowing more about the GDPR than your legal adviser, especially here in NZ!


 Step 1: Do You Need To Comply With GDPR?

There are two conditions to meet to fall under the GDPR:

1- Do you actively target EU-residents?
2- Do you collect personal data, including pseudonymous data?

If you answer “no” to the first or both questions, then you’re in luck. Otherwise, sorry but you’ll need to go under the hood of you data collection and management processes and adjust them…


1. Do you actively target EU-residents?

There has been a misconception that if you don’t process or collect data inside EU, you are not affected by GDPR. This is partially true (or wrong, depending on your mood…). GDPR applies to any sites that collect data about data subjects that are physically in the Union, regardless of the data controllers, (i.e. the site) and/or processors’ locations. Given that you can’t really control who is visiting your site, any sites are actually virtually impacted by GDPR. However the Regulation will look at how actively the site is targeting EU-residents to determine if it falls under the GDPR.

Recital 23: “In order to determine whether such a controller or processor is offering goods or services to data subjects who are in the Union, it should be ascertained whether it is apparent that the controller or processor envisages offering services to data subjects in one or more Member States in the Union. [...] factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.”

So for instance, if you are offering payments in Euros and/or specific shipping rates to European countries (including UK), you explicitly target your offer to EU-residents. Therefore you must abide by the GDPR. Similarly, if you have advertising campaigns specifically targeting a member State of the Union.

The same applies if the site doesn’t sell anything but still monitors users’ behaviour (see recital 24).


2. Do you collect personal data, including pseudonomised?

You may think that you are safe because you don’t collect personal data but the GDPR has a rather broad definition of what constitutes personal data:

Recital 26: ”Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. [...] To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments.The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.”

Recital 30: Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them

This means that IP addresses and Client IDs (created by the _ga Google Analytics cookie) are considered as personal data by extension, even if you don’t have direct access to these data as they are not surfacing in GA reports.

One way to address this is to mask IP addresses using the IP Anonymization feature. This would make the identification of a specific subject much harder. Note that you will need to either remove or adjust your current IP-based filters in GA accordingly.
Then for users who do not consent to get their data collected for Analytics purpose, you can still track their session by setting the _ga cookie to expire at the end of the session (or even no cookie at all), which makes their identification impossible (the Client ID becomes truly anonymysed), unless they provide personal pseudonmysed data, like a User ID, but in this case you will need to ask for their consent for Personalisation purpose anyway. And remember that GA doesn’t allow you to collect any actual personal data (e.g. name, email, phone number, address, etc.).

By now, you should have a better idea on whether or not you need to comply with the GDPR.
If so, you will have to get the consent from users.


Step 2: Create a Consent Mechanism

During my research, I haven’t been able to see a consent modal design, which would fully answer GDPR requirements, i.e.:

  • Be granular by data collection purpose (I’ve seen an example where all data processors were listed, which would end up as a very long list for many sites)
  • Offer free choice, without the opt-in/opt-out button being preselected
  • Explain in plain English what the data processing is for, by purpose
  • And most importantly, address the inter-dependency issue between some data processing purposes

Piwik Pro and Tealium both offer built-in consent management solutions but they fail to fully address these points.

Tealium Consent Manager:

Consent Preferences Manager from Tealium

Tealium proposes a highly customisable consent manager, but not sure if you can customise each tag’s settings according to the consent. It looks like the analytics tags would be all disabled if the consent for Analytics is not given, which would be unnecessary if you can configure them so they only collect anonymised data. And this doesn’t really address the inter-dependency issue (not that there is any between the purposes shown in the example above).
As a side note, I would recommend to ask for consent for the Social Media purpose only when users first click to share on social media, and provide an option to save their selection (so create a specific cookie for social sharing consent).

 Piwik Pro Consent Manager:

Consent form from Piwik Pro

I like the “Agree to all” button but not sure how it addresses dependencies between data processing purposes. And I imagine the saving option should not be available if at least the Analytics purpose is not enabled since by definition you are not allowed to store any data if no consent is given.

Adobe Dynamic Tag Management (soon to be revamped to “Launch”) doesn’t provide a ready-to-use consent management solution but you can add extensions such as TrustArc’s or Evidon’s (not free though).

As for Google Tag Manager, there is no built-in consent manager either but you could easily inject some custom HTML tag as described in this post from AnalyticsMania.

Google has also updated its information portal for publishers and advertisers, suggesting different solutions to add a consent function to your site.

Still, the best solution would be to create its own customised consent modal as no situation is the same…

Below is my attempt to create a consent modal for a first-time user on landing page:

FIRST consent modal
“More details” link would redirect to the privacy policy page describing the purpose in more details and listing all data processors. To address the inter-dependencies between purposes, the Analytics and Personalisation purposes would be enabled if the Personalisation and Advertising purpose are enabled, respectively.


Step 3: Adjust Your Data Collection According to User’s Consent Level

The best article I’ve read so far about this is the excellent post by Jente De Ridder from Humix, who proposes a practical solution to make GA GDPR compliant via GTM. It’s logical and well written and probably answers most of web analysts questions.

The diagram I propose below is largely inspired by Jente’s solution, with a few additional notes on the granular consent mechanism.
For instance, one requirement from GDPR is to “be able to demonstrate that the data subject has given consent to the processing operation” (recital 42). Therefore you can send an event to GA to pass the consent level. This event will then be very useful to identify “new users” from consent level 0 (by definition all users with consnent level 0 are new users) from other “”usual” new users.

Additionally in the GA UI, you will need to adjust your Data Retention period to a determined period as required by the GDPR:

Recital 39: “The personal data should be adequate, relevant and limited to what is necessary for the purposes for which they are processed. This requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict minimum.”

I hope this can help visualising the challenge and visualising one solution more easily, if nothing else.

GDPR consent mechanism


Closing Thoughts

I believe we will certainly see a decrease in the audiences size of the (remarketing) advertising campaigns but with good wording, we can end up with a win-win situation: the user understands why we collect data and why it may be beneficial for him/her while the brand shows its care for data privacy respect and may improve advertising campaigns with a better qualified audience and smarter incentives.

Ultimately, even if you are not directly impacted by GDPR (e.g. you don’t target EU-residents in the Union), I would still encourage you to proactively think about how you collect, store and share users data (especially if EU-citizens constitutes a significant share of your audience – think about immigration-related sites, job listings, or real estate sites, etc.) as New Zealand will most likely cooperate with the EU and update its privacy regulation to get closer to the GDPR. Showing that you have a strong privacy policy can also be perceived as a competitive advantage for users, who are more and more vigilant about how their data is being collected, used and shared…

Some Resources:

Monitor Your Cross-Domain Tracking with Google Tag Manager and Google Analytics Custom Alert

published by on 15th January 2018 under Google Analytics


This post is not about setting up cross-domain tracking for Google Analytics but let’s have a quick reminder on what it is and how to set it up.

Cross-domain tracking is basically adjusting the GA settings to be able to aggregate traffic on and in the same GA property. This is done by allowing the _ga cookie to be shared between these domains. To do this we need to:

  • Append the _ga linker parameter to the destination URL when coming from the origin domain – and vice versa. The _ga linker parameter looks like _ga=1.199239214.1624002396.1440697407 and consists in the GA client id + timestamp + some other special ingredients…It should be generated and appended (automatically with the autoLink method or manually) to the destination URL just before the user gets redirected to the destination URL to prevent any issues related to links sharing. More information on the linker here;
  • Set the allowLinker field to ‘true’ to tell GA to parse the _ga linker parameter;
  • Set the cookieDomain to ‘auto’ (this should already be the case);
  • Add the domains (, in the Referral Exclusion List in your GA property settings.

See here for a simple description on how to do this in GTM.


The Solution

So, to my knowledge, having this _ga linker in the destination URL is the sine qua non condition for your cross-domain tracking to work. No other way around.

Which brings us to the quite simple solution explained below to monitor when this is broken. Yes, even if you initially set it up correctly, cross-domain tracking can be broken for many reasons: an update to the site preventing the autoLink method from working, a redirection or a server-side setting stripping out the _ga linker parameter, etc. And when it’s broken, this is vicious enough for you to notice that only weeks after it actually broke. You would basically see an increase in sessions (as a new session would start when landing on from and in sessions attributed to Direct.

So, to be aware on the day (or the day after) it happens, you can setup the following solution, which requires GTM and consists in:

  • Sending an event to GA when the Page URL is on (or and the referrer is (or and the Page URL doesn’t contains the _ga linker parameter;
  • Setting up a custom alert in GA to let you know if this event has been sent.

To do this we need:

  • A variable for the _ga Linker URL Query
  • A trigger per domains to track (2 in my example)
  • A GA event tag
  • A GA custom alert


1- Create the gaLinker Variable

Go to the variable section in GTM and create the URL type variable as below:

gaLinker variable

You also need to enable the in-built Referrer and Page URL variables if not already done.

2- Create the Google Analytics Event Tag

I’ve added the built-in variables Referrer and Page URL for the event label so I can quickly see where the issue is coming from.

I’ve also chosen to set this event as a non-interaction hit so it doesn’t impact the bounce rate.

GA event for broken cross-domain tracking

3- Create the Triggers

In this example, we have 2 triggers:

- one for broken cross-domain tracking from to
- one for broken cross-domain tracking from to

If you have a third domain, then you’ll need 3 triggers:
- one for broken cross-domain tracking from or to
- one for broken cross-domain tracking from or to
- one for broken cross-domain tracking from or to

The triggers basically check that:

  • The referrer is (or;
  • The destination URL is (or;
  • The _ga linker parameter is not defined in the destination URL.


trigger from domainA to domainB

trigger from domainB to domainA

The entire tag configuration should look like below:

Full tag config


4 – Create the Custom Alert in GA

Now that we have setup this event, we need to create a custom alert in GA so we can receive an email when this event is reported.

So, go to the GA View settings and click on Custom Alerts:

GA Custom Alerts under View settings

Then create the daily alert like below:

GA custom alert

And that’s it.

Hopefully you won’t receive any of those but if you do, you’ll know it and fix it faster!

Related posts

FIRST Is a Google Data Studio Certified Partner

published by on 8th January 2018 under Events, General, Google Analytics

Happy new year all!

And to start this year on a great note, we are happy to announce that FIRST has earned the certification for Google Data Studio.

We have used Google Data Studio since its launch in 2016 and it has quickly become one of our favourite data visualisation tool to share insights and do some data exploration with ease.

Google Analytics Partner


If you haven’t done so yet, have a play with it.

Happy data visualisation!

Related posts