Re: Manage analytics through tag manager?

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL WWW <pgsql-www(at)postgresql(dot)org>
Subject: Re: Manage analytics through tag manager?
Date: 2020-07-02 09:01:33
Message-ID: CA+OCxowOnVCLfNiFnhSnRNG-GMVnZDJhpZGxYOnNpngQxyJzKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

Hi

On Wed, Jul 1, 2020 at 8:28 PM Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Daniel Gustafsson 2020-07-02 11:56:11 Re: Manage analytics through tag manager?
Previous Message Magnus Hagander 2020-07-01 20:44:29 Wiki service work