Re: Manage analytics through tag manager?
| От | Dave Page |
|---|---|
| Тема | Re: Manage analytics through tag manager? |
| Дата | |
| Msg-id | CA+OCxowOnVCLfNiFnhSnRNG-GMVnZDJhpZGxYOnNpngQxyJzKA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Manage analytics through tag manager? (Magnus Hagander <magnus@hagander.net>) |
| Ответы |
Re: Manage analytics through tag manager?
|
| Список | pgsql-www |
Hi
On Wed, Jul 1, 2020 at 8:28 PM Magnus Hagander <magnus@hagander.net> wrote:
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.
Right. That's exactly why I started this thread by explaining what I need.
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.
Yes.
But if that's *all* we care about around them, we could just have a tiny collector dumping that data into a postgres database...
So the options are:
- Change the way we call the system we're already using with a five minute patch, to one that easily allows us to send outbound clicks to the same system we're already using, and then easily turn it off again once we have useful data that can inform our design choices, or.
- Build a new mechanism from scratch that will require additional code in both the website frontend and backend, at least one potentially large table in the database, and the associated additional load as pages that currently get served entirely from varnish start making callbacks to the main server. Once we have the data we then have to go and remove all of that setup again (or at the very least, the frontend part), and if we later need additional data from elsewhere on the site (or different data entirely), we have to then modify the site to put the frontend code back in the new place of interest, or rewrite/extend the code we have to log something new.
The former is clearly orders of magnitude easier to implement and allows us the flexibility to measure different areas of the site or even entirely different metrics with just a few clicks, and turn it off again just as easily.
The latter avoids sending the additional click data to Google, which makes little to no difference because they're already getting the regular analytics data anyway, and which almost certainly contains everything that is important to them.
I have no issue with a longer term project to change the analytics to another service that can give us useful information (the nature of which we may not actually know until we come to try to improve a particular are of the site), but 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.
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-www по дате отправления: