Dnn.platform: bring the code in SiteAnalytics.config up to date

[dieterdtx]

Description of problem

The GA code in SiteAnalytics.config is using ga.js, which is Legacy code.
https://developers.google.com/analytics/devguides/collection/gajs

Description of solution (edited on 21 oct, input David Poindexter)

Change the code to analytics.js
https://developers.google.com/analytics/devguides/collection/analyticsjs

Additional context (edited to new solution)

It would perhaps be useful to also include 'anonymize_ip' as a default setting, as this is suggested for GDPR compliance by "various" sources. Feel free to scout around for validness of this suggestion.
https://developers.google.com/analytics/devguides/collection/analyticsjs/ip-anonymization

[EPTamminga]

This to be a good enhancement for a GA default.
Any Google Analytics specialists around who can comment?

[david-poindexter]

Google Analytics (GA) and Google Tag Manager (GTM) are two separate methods. The newer version of GA is actually documented HERE.

[dieterdtx]

@david-poindexter You're absolutely right, I even have used that one, I'm not sure why I so blindly took the wrong script, my fault.

I will edit my original post.

[dieterdtx]

It appears my original post wasn't so wrong after all...
https://developers.google.com/analytics/devguides/collection/gtagjs/migration

[EPTamminga]

@dieterdtx If I understand this correctly, it is possible to replace the GA code with the gtag code and specify to measure Page Views?

[dieterdtx]

@EPTamminga That's how I am reading it. As I see it gtag is more prepared to use for other features but can track simple page views just as well. If I check realtime view; the page views, including every metric that you expect appear to come through just fine.

[david-poindexter]

End the end, there are several ways to implement Google Analytics or Google Tag Manager. We need to make clear distinctions between these methods. We also need to take into consideration some of the differences in privacy, especially as it relates to GDPR. My vote would be to provide multiple connectors (one for each implementation method) or update the one we have to give the admin a choice as to which method they prefer to use. CC @mikesmeltzer (what are your thoughts on this?)

[bdukes]

I agree, in general, with @david-poindexter, but think it would end up being confusing to have multiple GA connectors. I think adding options to the GA connector would be an easier experience for the administrator, and then having a second connector for GTM would be provide an easier choice to consider.

[david-poindexter]

I would lean on towards this approach as well @bdukes - much clearer to the admin.

[mikesmeltzer]

We could simplify this even further and future proof ourselves by building a really basic implementation that wasn't a GA or GTM connector but simply a Universal Analytics Connector.

Behind the scenes it could be virtually identical to what we have today just without pulling from the file and from a Portal Setting (this would prevent the current issue of all portals doing the same thing).

It could have simply a multi-line textbox that lets you put the code that you want.

I'm thinking from a pragmatic standpoint that this would satisfy a lot use cases, be a minimal feature to add and stop the various workarounds of manually editing files, etc.

Thoughts?

[bdukes]

I like this approach (one caution I considered mentioning with the other approach is making sure we continue to allow customizing the script).

My only concern is that, for instance, Google Tag Manager requests that you add a script block to the head and a <noscript> to the body. Would we want to introduce the complexity of having multiple inputs that can be injected into multiple places within the markup of the site?

[mikesmeltzer]

Good point, Brian. There would have to be a fine balance on that as you wouldn't want scope to creep which I could see happening easily. Two fields, InjectInBody and InjectInHeader, would work but you are opening up the door to misuse (which I believe the SiteAnalytics.config is misused today too) by potentially having non-analytics things injected.

If we are looking at the ability to change between Google codes, etc. then we are probably getting into modifying the SiteAnalytics.config file, etc. in code (in the current state) which may open up other challenges like potentially over writing someones custom modifications, etc. unless we change the way it's built or do some tricky business.

Some food for thought... Are we even aware of any extensions (commercial or OSS) that implement a site analytics engine bedsides the Platform itself? I've never come across one, could be an opportunity to deprecate that functionality and do it a bit differently.

I'm not sure where the "happy spot" is. If we continue to include Google specific snippets in the Platform then we need a solution to keep them up to date and something that gives a tracking code that works for as many as possible (there is lots of GA questions on DNN online, people wanting to add specific things, etc..) vs. just giving someone the ability to add whatever code they want from a central location.

My belief is that the user is going to log into GA/GTM anyway to get their tracking ID which is usually in the same screen (or very close) as the complete tracking snippet they tell you to inject in your site..

Other thoughts?

[thenotandy]

This is the modified file that I am currently using for GTM. It works well, so far. https://pastebin.com/e8qqBnVg

[Tychodewaard]

@skamphuis and I created a GTM connector (David already linked). Use cases for me:

1. DNN instance that supports GA on portal 1 and supports GTM on portal 2.
2. The snippet has multiple parts so you can not just add it in the site settings like Hotjar. My customers need something really simple like just pasting the GTM-code not the entire snippet
3. If people search for GTM, they will type 'GTM'. Not 'GA with option to behave like GTM' :-) So, it is marketing for DNN as well.

Now for the versions of the snippet.
What if we load a stable/current/suppoorted version but we offer to change that? I know it might be quite a bit of work but this way we offer a version that works but allow innovators to use newer versions.

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!