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. 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. O’Brien 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 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. session 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 . 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). repository 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. — A logging request signaling the homepage has been reached can be done with a script snippet like this Example 1 <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 under the website doc root. No need to read any response, as the log API returns nothing. /app-events/ — Signaling "contact me" button results Example 2 <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:me@mydomain.com?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!

Apache

Fetch

Crunching Large Datasets Made Fast and Easy: the Polars Library

Store API Credentials Safely: Obfuscation Before Encryption is Key

Nominated for 2022 - HackerNoon Contributor of the Year - Big Data

Nominated for 2022 - HackerNoon Contributor of the Year - Encryption

Nominated for 2022 - HackerNoon Contributor of the Year - Api

Too Long; Didn't Read

Make resilience your competitive advantage

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Crunching Large Datasets Made Fast and Easy: the Polars Library

Here's Why You Should Never Blindly Accept Cookies from Every Website

8 Biggest Google Ad Trends You Need to Know in 2024

9 in 10 Serverless Apps Are In Deep Trouble In Frontend Security

A Guide on Using the Cookie Store API

Crunching Large Datasets Made Fast and Easy: the Polars Library

Here's Why You Should Never Blindly Accept Cookies from Every Website

8 Biggest Google Ad Trends You Need to Know in 2024

9 in 10 Serverless Apps Are In Deep Trouble In Frontend Security

A Guide on Using the Cookie Store API

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps