Thread: Manage analytics through tag manager?

We currently use Google Analytics for analysing traffic on the website, and have done for many years. Whilst discussing some ideas to improve the user experience with Jonathan, it became clear to me that ideally we need outbound link tracking, i.e. what link did a user click that took them away from our site. This is useful to know so we can tell, for example, what download option a user ended up choosing, which can better inform us on how to improve the layout of the download pages.

Whilst it is possible to do outbound link tracking directly in Google Analytics, it can be invasive, requiring onclick attributes on every link. It is (in theory) possible to dynamically add those using a script in the base template or similar, but I've never actually been able to get that to work when I've tried.

Instead, I'd like to suggest we change to using Google Tag Manager directly in the site in place of Analytics. Tag Manager uses a couple of similar JS snippets to Analytics so would require minimal changes to the site. However, it can then be used (amongst many other things) to enable Analytics site-wide as it is now, and to automatically send outbound link clicks to Analytics globally or for subsets of pages and target URLs with no further code changes.

On Tue, Jun 30, 2020 at 1:55 PM Dave Page <dpage@pgadmin.org> wrote:

We currently use Google Analytics for analysing traffic on the website, and have done for many years. Whilst discussing some ideas to improve the user experience with Jonathan, it became clear to me that ideally we need outbound link tracking, i.e. what link did a user click that took them away from our site. This is useful to know so we can tell, for example, what download option a user ended up choosing, which can better inform us on how to improve the layout of the download pages.

Whilst it is possible to do outbound link tracking directly in Google Analytics, it can be invasive, requiring onclick attributes on every link. It is (in theory) possible to dynamically add those using a script in the base template or similar, but I've never actually been able to get that to work when I've tried.

Instead, I'd like to suggest we change to using Google Tag Manager directly in the site in place of Analytics. Tag Manager uses a couple of similar JS snippets to Analytics so would require minimal changes to the site. However, it can then be used (amongst many other things) to enable Analytics site-wide as it is now, and to automatically send outbound link clicks to Analytics globally or for subsets of pages and target URLs with no further code changes.

Given the number of sites that completely break and fall over when one blocks GTM, I have to ask: I assume this can be done in a way that has zero impact on those who are sensible enough to block it?

On Tue, Jun 30, 2020 at 1:07 PM Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Jun 30, 2020 at 1:55 PM Dave Page <dpage@pgadmin.org> wrote:

We currently use Google Analytics for analysing traffic on the website, and have done for many years. Whilst discussing some ideas to improve the user experience with Jonathan, it became clear to me that ideally we need outbound link tracking, i.e. what link did a user click that took them away from our site. This is useful to know so we can tell, for example, what download option a user ended up choosing, which can better inform us on how to improve the layout of the download pages.

Whilst it is possible to do outbound link tracking directly in Google Analytics, it can be invasive, requiring onclick attributes on every link. It is (in theory) possible to dynamically add those using a script in the base template or similar, but I've never actually been able to get that to work when I've tried.

Instead, I'd like to suggest we change to using Google Tag Manager directly in the site in place of Analytics. Tag Manager uses a couple of similar JS snippets to Analytics so would require minimal changes to the site. However, it can then be used (amongst many other things) to enable Analytics site-wide as it is now, and to automatically send outbound link clicks to Analytics globally or for subsets of pages and target URLs with no further code changes.

Given the number of sites that completely break and fall over when one blocks GTM, I have to ask: I assume this can be done in a way that has zero impact on those who are sensible enough to block it?

I just tested on a couple of sites using it, and blocking didn't seem to affect use of the sites at all.

On Tue, Jun 30, 2020 at 2:22 PM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Jun 30, 2020 at 1:07 PM Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Jun 30, 2020 at 1:55 PM Dave Page <dpage@pgadmin.org> wrote:

We currently use Google Analytics for analysing traffic on the website, and have done for many years. Whilst discussing some ideas to improve the user experience with Jonathan, it became clear to me that ideally we need outbound link tracking, i.e. what link did a user click that took them away from our site. This is useful to know so we can tell, for example, what download option a user ended up choosing, which can better inform us on how to improve the layout of the download pages.

Whilst it is possible to do outbound link tracking directly in Google Analytics, it can be invasive, requiring onclick attributes on every link. It is (in theory) possible to dynamically add those using a script in the base template or similar, but I've never actually been able to get that to work when I've tried.

Instead, I'd like to suggest we change to using Google Tag Manager directly in the site in place of Analytics. Tag Manager uses a couple of similar JS snippets to Analytics so would require minimal changes to the site. However, it can then be used (amongst many other things) to enable Analytics site-wide as it is now, and to automatically send outbound link clicks to Analytics globally or for subsets of pages and target URLs with no further code changes.

Given the number of sites that completely break and fall over when one blocks GTM, I have to ask: I assume this can be done in a way that has zero impact on those who are sensible enough to block it?

I just tested on a couple of sites using it, and blocking didn't seem to affect use of the sites at all.

That's good.

I'd still say we need a very clear reason for it if we're going to collect more information about our visitors. That is, we need a plan for what we're going to do with the data. If we don't have that, we should not collect it. 

(Same applies to Google Analytics of course -- and I think at some point we said we were going to re-evaluate our use of that and see if we already had enough information "on our own" for the things we actually do (since most of the details from GA I don't think we use), but I don't think we ever got around to it..)

 

--

 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

On 1/7/20 10:07, Dave Page wrote:

On Tue, Jun 30, 2020 at 6:42 PM Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Jun 30, 2020 at 2:22 PM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Jun 30, 2020 at 1:07 PM Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Jun 30, 2020 at 1:55 PM Dave Page <dpage@pgadmin.org> wrote:

We currently use Google Analytics for analysing traffic on the website, and have done for many years. Whilst discussing some ideas to improve the user experience with Jonathan, it became clear to me that ideally we need outbound link tracking, i.e. what link did a user click that took them away from our site. This is useful to know so we can tell, for example, what download option a user ended up choosing, which can better inform us on how to improve the layout of the download pages.

Whilst it is possible to do outbound link tracking directly in Google Analytics, it can be invasive, requiring onclick attributes on every link. It is (in theory) possible to dynamically add those using a script in the base template or similar, but I've never actually been able to get that to work when I've tried.

Instead, I'd like to suggest we change to using Google Tag Manager directly in the site in place of Analytics. Tag Manager uses a couple of similar JS snippets to Analytics so would require minimal changes to the site. However, it can then be used (amongst many other things) to enable Analytics site-wide as it is now, and to automatically send outbound link clicks to Analytics globally or for subsets of pages and target URLs with no further code changes.

Given the number of sites that completely break and fall over when one blocks GTM, I have to ask: I assume this can be done in a way that has zero impact on those who are sensible enough to block it?

I just tested on a couple of sites using it, and blocking didn't seem to affect use of the sites at all.

That's good.

I'd still say we need a very clear reason for it if we're going to collect more information about our visitors. That is, we need a plan for what we're going to do with the data. If we don't have that, we should not collect it. 

Let's be clear here - we are not, and do not collect information about individual users (unless they sign up for an account of course). 

We collect anonymous usage information that is free of any form of PII that informs us on things like popularity of different pages so we can gauge what works and doesn't work content-wise, browser/device usage so we know what to test with, navigation patterns so we understand how people use our site, and the bit I think is valuable to add; outbound link usage, so we can understand (in the particular case I'm working on) what the popularity of different download options are, particularly those where we do not have any stats at all because they're hosted at third party sites.

    Not sure if with this reply you were also considering what I mentioned in the thread about GA concerns in general, but just in case: concerns about GA are not on what information we'd collect, but rather the information that, thanks to us, Google is collecting. Because this information can be cross-referenced with that from other sites, ads and probably many other sources.

    I'm all in to have usage and statistics information for the website --as long as they don't include PII of course, and only those that are used and reasonable-- but there are many other tools than GA to do this.

Most of that cannot be gained through the very limited amount of server logs we have, and even that which can is not meaningful because they are purged very quickly and only kept for a short while for diagnostics because they do contain PII.

    Actually there is probably much of the information being used now that may be gathered from the logs. But anyway probably other existing tools are better than this.

On Tue, Jun 30, 2020 at 6:42 PM Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Jun 30, 2020 at 2:22 PM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Jun 30, 2020 at 1:07 PM Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Jun 30, 2020 at 1:55 PM Dave Page <dpage@pgadmin.org> wrote:

We currently use Google Analytics for analysing traffic on the website, and have done for many years. Whilst discussing some ideas to improve the user experience with Jonathan, it became clear to me that ideally we need outbound link tracking, i.e. what link did a user click that took them away from our site. This is useful to know so we can tell, for example, what download option a user ended up choosing, which can better inform us on how to improve the layout of the download pages.

Whilst it is possible to do outbound link tracking directly in Google Analytics, it can be invasive, requiring onclick attributes on every link. It is (in theory) possible to dynamically add those using a script in the base template or similar, but I've never actually been able to get that to work when I've tried.

Instead, I'd like to suggest we change to using Google Tag Manager directly in the site in place of Analytics. Tag Manager uses a couple of similar JS snippets to Analytics so would require minimal changes to the site. However, it can then be used (amongst many other things) to enable Analytics site-wide as it is now, and to automatically send outbound link clicks to Analytics globally or for subsets of pages and target URLs with no further code changes.

Given the number of sites that completely break and fall over when one blocks GTM, I have to ask: I assume this can be done in a way that has zero impact on those who are sensible enough to block it?

I just tested on a couple of sites using it, and blocking didn't seem to affect use of the sites at all.

That's good.

I'd still say we need a very clear reason for it if we're going to collect more information about our visitors. That is, we need a plan for what we're going to do with the data. If we don't have that, we should not collect it. 

Let's be clear here - we are not, and do not collect information about individual users (unless they sign up for an account of course). 

We collect anonymous usage information that is free of any form of PII that informs us on things like popularity of different pages so we can gauge what works and doesn't work content-wise, browser/device usage so we know what to test with, navigation patterns so we understand how people use our site, and the bit I think is valuable to add; outbound link usage, so we can understand (in the particular case I'm working on) what the popularity of different download options are, particularly those where we do not have any stats at all because they're hosted at third party sites.

Most of that cannot be gained through the very limited amount of server logs we have, and even that which can is not meaningful because they are purged very quickly and only kept for a short while for diagnostics because they do contain PII.

Now don't get me wrong -- I'm not against collecting proper metrics, and using the right tool for it. I'm just saying we shouldn't collect more information than we need (and by "we" I mean neither we nor google on our behalf (or another third party)). So I think we should really start with what we need, and take it from there.

And if what we need cannot be collected from the request data that we already have, then we should certainly look at other solutions. Whether they're Google Analytics or Tag Manager or a separate product we install on our own infra etc. I think in particular when you say "outbound link data usage" you mean people clicking links on our site that goes to a different site, right? That being requests that never hit our servers, it wouldn't be in our request data.

But if that's *all* we care about around them, we could just have a tiny collector dumping that data into a postgres database...

> On 2 Jul 2020, at 11:01, Dave Page <dpage@pgadmin.org> wrote:

>  ..for what I'm trying to achieve right now it seems like I'm being asked to jump through a 30cm hoop that's being dangled from the top of a 4 storey building.

To be fair, I think the shape and placement of the hoops would've been
different if it was made clear(er) from the start that the proposal was to
measure outbound traffic for a *limited period*.  At least I didn't understand
that until this email.

Settling on the future analytics needs for postgresql.org sounds like a topic
well suited for an unconference style discussion, maybe we'll end up changing
nothing but it's worth discussing. 

What we can do to address concerns with tracking in the meantime is to honor
the DoNotTrack header in the site template, and only load GA/GTM in case
navigator.doNotTrack isn't set.  Something like the (completely untested)
attached migth be all we need?  The diff also removes the ability to load GA
over http, which we clearly shouldn't allow (and since moving the site to all
https we don't anyways IIUC).

On Thu, Jul 2, 2020 at 12:56 PM Daniel Gustafsson <daniel@yesql.se> wrote:

> On 2 Jul 2020, at 11:01, Dave Page <dpage@pgadmin.org> wrote:

>  ..for what I'm trying to achieve right now it seems like I'm being asked to jump through a 30cm hoop that's being dangled from the top of a 4 storey building.

To be fair, I think the shape and placement of the hoops would've been
different if it was made clear(er) from the start that the proposal was to
measure outbound traffic for a *limited period*.  At least I didn't understand
that until this email.

Sorry, I thought that was clear as I said in my original message that I thought the outbound link tracking would be useful for the project I'm working on. On re-reading I see that my wording on that was somewhat less than awesome.

 

Settling on the future analytics needs for postgresql.org sounds like a topic
well suited for an unconference style discussion, maybe we'll end up changing
nothing but it's worth discussing. 

Agreed.

 

What we can do to address concerns with tracking in the meantime is to honor
the DoNotTrack header in the site template, and only load GA/GTM in case
navigator.doNotTrack isn't set.  Something like the (completely untested)
attached migth be all we need?  The diff also removes the ability to load GA
over http, which we clearly shouldn't allow (and since moving the site to all
https we don't anyways IIUC).

I think we'd also need to check windows.doNotTrack to cover Microsoft browsers, but yes, I think that will work with GA.

In GTM you can do it in the config (i.e. through the container settings in the management UI). Browsers would still pull the code of course, but then any tracking would be disabled. 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> On 2 Jul 2020, at 14:23, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Jul 2, 2020 at 12:56 PM Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:

> What we can do to address concerns with tracking in the meantime is to honor
> the DoNotTrack header in the site template, and only load GA/GTM in case
> navigator.doNotTrack isn't set.  Something like the (completely untested)
> attached migth be all we need?  The diff also removes the ability to load GA
> over http, which we clearly shouldn't allow (and since moving the site to all
> https we don't anyways IIUC).
>
> I think we'd also need to check windows.doNotTrack to cover Microsoft browsers, but yes, I think that will work with GA.

Ah yes, my bad, window.doNotTrack (as you corrected in a subsequent email) is
required for IE and Safari.

> In GTM you can do it in the config (i.e. through the container settings in the management UI). Browsers would still pull the code of course, but then any tracking would be disabled.

Right, I still prefer to do it on our side and put us in charge of whether
tracking is invoked or not.

On Thu, Jul 2, 2020 at 2:33 PM Daniel Gustafsson <daniel@yesql.se> wrote:

> On 2 Jul 2020, at 14:23, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Jul 2, 2020 at 12:56 PM Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:

> What we can do to address concerns with tracking in the meantime is to honor
> the DoNotTrack header in the site template, and only load GA/GTM in case
> navigator.doNotTrack isn't set.  Something like the (completely untested)
> attached migth be all we need?  The diff also removes the ability to load GA
> over http, which we clearly shouldn't allow (and since moving the site to all
> https we don't anyways IIUC).
>
> I think we'd also need to check windows.doNotTrack to cover Microsoft browsers, but yes, I think that will work with GA.

Ah yes, my bad, window.doNotTrack (as you corrected in a subsequent email) is
required for IE and Safari.

> In GTM you can do it in the config (i.e. through the container settings in the management UI). Browsers would still pull the code of course, but then any tracking would be disabled.

Right, I still prefer to do it on our side and put us in charge of whether
tracking is invoked or not.

+1.

(Both on the turn it took with some more details in general, and specifically on preventing even loading the GA/GTM scripts if the browser is set to do not track) 

On Thu, Jul 2, 2020 at 1:50 PM Magnus Hagander <magnus@hagander.net> wrote:

On Thu, Jul 2, 2020 at 2:33 PM Daniel Gustafsson <daniel@yesql.se> wrote:

> On 2 Jul 2020, at 14:23, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Jul 2, 2020 at 12:56 PM Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:

> What we can do to address concerns with tracking in the meantime is to honor
> the DoNotTrack header in the site template, and only load GA/GTM in case
> navigator.doNotTrack isn't set.  Something like the (completely untested)
> attached migth be all we need?  The diff also removes the ability to load GA
> over http, which we clearly shouldn't allow (and since moving the site to all
> https we don't anyways IIUC).
>
> I think we'd also need to check windows.doNotTrack to cover Microsoft browsers, but yes, I think that will work with GA.

Ah yes, my bad, window.doNotTrack (as you corrected in a subsequent email) is
required for IE and Safari.

> In GTM you can do it in the config (i.e. through the container settings in the management UI). Browsers would still pull the code of course, but then any tracking would be disabled.

Right, I still prefer to do it on our side and put us in charge of whether
tracking is invoked or not.

+1.

(Both on the turn it took with some more details in general, and specifically on preventing even loading the GA/GTM scripts if the browser is set to do not track) 

Thanks. Can you or Daniel or someone else please give the attached patch a quick look over before I commit it? 

> On 2 Jul 2020, at 15:38, Dave Page <dpage@pgadmin.org> wrote:

> Can you or Daniel or someone else please give the attached patch a quick look over before I commit it?

Correct me if I'm wrong, but won't this only run tracking for those with DNT set?

+var DNT = navigator.doNotTrack || window.doNotTrack || navigator.msDoNotTrack || window.msDoNotTrack;
+if ((DNT == "1") || (DNT == "yes")) {
+    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':

> On 2 Jul 2020, at 15:56, Dave Page <dpage@pgadmin.org> wrote:

> Let's try again with the attached.

LGTM