tracking – Kownter https://blog.kownter.com Simple, private, self-hosted, cookie free website analytics...one day...maybe Thu, 10 May 2018 22:08:28 +0000 en-US hourly 1 https://wordpress.org/?v=6.7.2 Tracking return visits with The Anonymous Cookie https://blog.kownter.com/2018/05/10/tracking-return-visits-with-the-anonymous-cookie/ Thu, 10 May 2018 22:08:28 +0000 https://blog.kownter.com/?p=65 Read more]]> I’m still working through the pros and cons of using cookies.

On the one hand, they seem like they will allow some super-useful things at relatively low cost, such as tracking a returning visitor in order to show “visitors” and “unique visitors”.

But adding non-essential cookies (analytics are classed as non-essential) means that, in theory, if you’re in the EU you’re supposed to have informed, but not explicit consent for that cookie, which I read as: “you need a pop-up, but not a checkbox”.

A session cookie is, I believe, an “online identifier” and this is personally identifiable and subject to DPA or GDPR in the UK/EU (though I would argue that because you can’t perform a lookup on the session ID it’s not, but who am I to argue). So session cookies aren’t great for tracking (and wouldn’t scale). But nor is any other unique ID stored in a cookie and sent to the server.

There’s been a great conversation about this topic in a GitHub issue in Kownter’s competitor/collaborator  Fathom (I love them, it’s all good). And I’ve realised (yeah, took a while!) that you don’t need an ID in the cookie.  You can just set tracked_with_kownter = 1 or whatever, and that will identify a returning visitor to the site you’re tracking.

So the next step is: what can I put in the cookie that is anonymous, but useful?

 

]]>
More thoughts on HOW to track https://blog.kownter.com/2018/02/28/more-thoughts-on-how-to-track/ Wed, 28 Feb 2018 11:48:52 +0000 https://blog.kownter.com/?p=18 Read more]]> There seems to be a few possible ways to do the tracking and I think it broadly falls into two categories:

  • use JavaScript to send a request
  • request a resource (image, CSS) using an HTML tag or a CSS property

I talked before about the fact that requesting a resource wouldn’t send the details of the referring page. So I may have both as options with the resource request being easier to add in some cases, and the JS offering more functionality.

But some more questions have come up when thinking about this.

Do I need to send back valid response content?

I want the request and response to be as small as possible.  So can I send back an empty response?

A quick bit of research seems to show that I at least need to set the content type (Aside: I wonder how web servers determine this?).  And I’ll need to send an HTTP status code back.  But if I set that, can the response content itself actually be empty?

How do I prevent caching of responses?

Browsers are pretty good a caching resources these days. So what do I need to do to ensure that a resource response is not cached.

How do I prevent blocking page load?

In what circumstances does loading a resource block a page loading? I don’t want to do this. My request should be asynchronous if possible. So how do I achieve that in all cases?

Requesting CSS doesn’t look like a great idea.

Copying an image-generating bit of PHP looks like a good idea though.

I’m suddenly starting to see that this maybe isn’t as easy as it first seems.  Maybe this is why people don’t build their own analytics platforms.

]]>
Thoughts on WHAT to track and report https://blog.kownter.com/2018/02/26/thoughts-on-what-to-track-and-report/ Mon, 26 Feb 2018 09:05:06 +0000 https://blog.kownter.com/?p=13 Read more]]> I’ve been thinking about not just HOW to track, but WHAT to track. And these are related. My tracking method will, to some extent, dictate what I can track.  For example, using a simple pixel image or reference to a URL in HTML or CSS will not be able to send me the URL of the referring page.

And in meeting my goal of not using cookies and not keeping any personally identifiable information, I won’t be able to track users paths through a website.

This is perfectly OK for some applications. It’s not OK for everyone, but if you need that level of detail, we can still report the ratio of conversions against page views.

I wasn’t going to add event tracking, but maybe I’ll add events after all to help with this.  This WILL require a JS tracking code to be installed.

We’ll see.  Initially I’m happy with views per page over time, browser usage metrics and referring pages/traffic sources. None of these need personally identifiable information. It’s all anonymised and aggregate.

IP’s are personally identifiable information and will be logged in server logs (unless I turn this off), but I’ve seen it argued that, as long as your careful with log rotation and deletion (including backups), there’s a case for keeping this data temporarily without consent.

]]>
Choosing how to track https://blog.kownter.com/2018/02/23/choosing-how-to-track/ Fri, 23 Feb 2018 19:39:13 +0000 https://blog.kownter.com/?p=9 Read more]]> I’ve been trying to work out how best to do the tracking.  There seem to be two options:

  1. Request a resource using CSS or an image
  2. Make a JS call

The main disadvantage of the CSS/image approach is that it won’t be able to send a referrer so we won’t be able to see where the page that was loaded was accessed from.

There may also be a performance hit as the request might not load asynchronously. I’ll have to do some testing with this.

The JS method requires JS to be added to the site and loaded, BUT, it will allow the referrer to be passed on. (I’ll have to work out how).

There’s also a question about bots.  One slight advantage of JS is that it will not track bots that don’t use JS.  What I don’t know is do the bots that fail to load JS also fail to load other resources?  Will a crawler hit the tracking endpoint if CSS or an image is used?

I think I’ll probably end up offering both options. With the JS as an enhanced version if you want to implement it.

]]>