Let's Kill Cookies: My POC for a Less Creepy Way To Track Engagement

The dilemma with cookies

Many small to medium websites struggle with having to fulfil GPDR requirements. On one hand they want to measure user engagement, on the other side they suffer from wasting the first impression on showing a cookie acceptance banner.

Are cookies actually necessary?

In fact, if we don’t want to track the user and only want to record user reactions to our website/app functionality instead, we can drop cookies, banners, and the rest.

This story is about building a proof-of-concept for an alternative way to cookies when measuring user engagement.

What is user engagement?

Before we start coding anything though, we need to clarify the goal.

Studies confirm (see e.g. O’Brien et al.) that the more a user interacts with a website the higher the probability that said user will choose to close a transaction (buy, make appointment, subscribe, etc.). So, people will want to keep you on their website by showing you more content, making you curious or offering more options. To see whether your strategies are working you need data and the ability to analyze your results.

For small businesses, where most potential customers arrive at their site via search engines, being able to optimize content and interactions can be quite essential. Some basic examples of interaction events (metrics) worth analyzing are:

• Was there a referral when they arrived at your site? What is the landing page?
• Did a “contact-me” button press lead to contact completion?
• What content topics are seen more and which not at all?
• Did they leave the site after viewing only one page (bounce rate)?

Some of these could reveal flaws in your structure, presentation, or quality of content.

Constraints

There is no free lunch, as such when we decline to record the identity of the user there are strong limits as to what we can deduce.

The first and most important limitation is that the user will be modelled through a session which materializes through the IP address. This brings all known inconsistencies. The same person may interact with the site from the desktop and from a mobile device and they will appear as different sessions. Many people may appear as a single session when originating e.g. from a corporate organization. And so on.

Nevertheless, my experience of using this approach has convinced me that it is worth the investment.

What is the difference to old-style webserver log file analysis?

The ability to record interactive events from the page when users click on buttons, tabs, panes etc. In fact, for single page applications it is the de facto way to go. For content-based sites, adding interactive levers also improves site dynamics and when done well, also user retention.

The backend

For this proof of concept, I put together a simple LAMP (Apache/MySQL/PHP) backend that is deployable to most sites because most hosting services will support the architecture by default. It would be easy though to port it to a cloud-based backend to make it scale-up.

A technical description and the POC software are available at this repository. It is worth mentioning that only one table is required to store the data and that field optimization makes it very compact (about 75MB in size for a million records).

Recording events

The logging API consists of a single entry-point, defined as follows

log.php?log=[event name: String]&r=[referral: String, optional]&l=[landing page: String, optional]

where referral and landing are optional.

Example 1 — A logging request signaling the homepage has been reached can be done with a script snippet like this

<script>
  const ref = encodeURIComponent(document.referrer);
  const landing = encodeURIComponent(window.location.href);
  fetch('app-events/log.php?log=homepage&r=${ref}&l=${landing}');
</script>

provided the package has been deployed on  /app-events/ under the website doc root. No need to read any response, as the log API returns nothing.

Example 2 — Signaling "contact me" button results

<script>
  const contactEvent = () => {
    // contact me 
    if(!confirm("Would you like to open your mail client?")){
          fetch('app-events/log.php?log=contact-nok');
          return false;
    } 
    fetch('app-events/log.php?log=contact-ok');
  }
</script>

...

<a href="mailto:[email protected]?subject=Please contact me" onclick="contactEvent()">Contact me</a>

The dashboard app

The POC includes limited but useful reports. They are

• Events last 24 hours
• Last 30 days
• Monthly
• Referrals
• Topics last 24 hours and Ranking

All tables are sortable, most reports include graphs, the app is responsive. Most table rows support drill-down functionality.

The app itself is a minimum dependency ReactJS package that is configurable to be easily deployable for different sites. The package repository is here.

Hope you find this interesting and maybe even useful. Comments and suggestions are welcome!