Google Analytics has been deemed illegal by the EU DPA. Undicat is a British company, operated fully on European infrastructure.

Our data journey

See how we handle user data from the minute it leaves your user’s computer

We have built Undicat from the ground up with an extreme focus on the privacy of our users; we want to be extremely transparent about how our system works and what happens to our customers' data. All of Undicat's services comply with all the relevant privacy laws - we only process and save data that's essential and privacy-focused.

The following article will go into extreme detail about the journey of our customers' data from the point it enters our system and how we protect it to ensure our visitors' privacy.

So, let's say you've just put the Undicat Analytics script on your website or enabled one of our plugins within your CMS; the script is then live and ready to collect your website's analytics. And then one of your visitors loads your website in their browser.

In compliance to the Schrems II ruling, we have EU Isolation in place, meaning EU visitors' IP addresses never touch US-controlled infrastructure (see: Schrems II compliance).

If you read "IP Address" below, and are wondering about whether the IP Address of an EU data subject touches US infrastructure, the answer is: no, it doesn't. We only process EU data subject IP addresses temporarily on EU-owned infrastructure in accordance with our Data Processing Agreement.

Here's the full data journey, from start to finish

Step 1: Loading our cookie-free script

The Undicat Analytics script is loaded for our global content delivery network - this is to ensure rapid file loads from the server in the closest city to your location. Typical load times are around 20-40 milliseconds.

Once the script is loaded we determine the user's fingerprint and session:

  • Fingerprint Our script determines the fingerprint of the user based on various factors, including the specifications of the browser and the url of the current page.
  • Session The current session identifier is generated randomly then stored in the session storage - which is then loaded back in case of a page refresh.

Our script doesn't use cookies, we do not store any kind of data which could be traced back to your browser - this also means that you won't need to annoy your customers with cookie consent banners.

Once these details are generated a new pageview request is sent to our API layer.

This request will contain details about the page you have just visited, the website that referred you (both of which are encrypted on the front-end); in addition to your IP Address and User-Agent (containing details about your browser and device type) sent automatically by your browser.

Additionally, you can opt-in to "Forced Isolation", which will direct all your traffic (even from the US) through our EU-owned and operated infrastructure.

Step 2: The Firewall

We keep track of each IP Addresses request count performed over an undisclosed amount of time. This helps us preventing DDoS spam attacks.

At this stage all personal data is completely anonymised and encrypted, of which we don't keep any log in our system - as it would stand agains our views.

Step 3: Security Checks

After we cross-check your IP Address to multiple sets of known malicious IP Addresses - to further lower the change of a possible attack on our system, we first get your location using publicly available IP maps (this is the last we use your IP Address). Once we retreived your location we hash your IP Address as well; at this all your personal data is anonymised and encrypted to ensure that you are truly untraceable.

111.222.333.444 -> 0123456789abcdefghijklmnopqertxy

We don't keep any logs of this step - unless you match with any of the known addresses or our systems finds you guilty of attacking our infrastructure (meaning they're hitting us as part of a DDoS attack).

At this point

0123456789.abcdefghij.klmnopqertxy = 3 requests
abcdefghij.klmnopqert.xy0123456789 = 1 request

We keep these records of each IP hash for varying periods of time, at most for 24 hours counted after the first request.

The system will lock out any minor abuser on the application level for a brief period of time - meaning that the request is still let through the Security Layer and will be disregarded the next step.

If we detect more serious abuse at the application level, the IP Address will be permanently blocked, meaning that we will no longer let any request through our firewall. The IP Address Hash will also be added to our in-house database of malicious addresses.

Step 4: Saving the event

Once we've established that both the event and it's sender are valid, we're ready to store it in our database. Here's an example of everything we store in our database when we receive a simple pageview event.

Notice that since we are storing all data separated by their owner projects in separate Database Schemas, we do not need to store any kind of project specific information.


First we decrypt the body of the event, sent encrypted by the browser, then we insert the following payload into the database when receiving a pageview:

  id: 232332323234234,
  nonce: RbpGB1gXDuVPgFwUpGFyJ,
  timestamp: 2022-01-01 00:01:05,
  event: native-pageleave,
  fingerprint: 0a5aed68f9d5d8dd505de2a2b08fc8b7,
  session: ERCKe1DoddWJPJa28zmci,
  pathname: /blog
  ip: ac92303490286ad4252f2ec3eaeecc1b
  country_code: GB
  city: London
  time_zone: Europe/London
  os_name: Mac OS
  type: Desktop
  browser_name: Chrome
  utm_term: terms
  utm_medium: facebook
  utm_source: Facebook Campaign
  utm_content: Campaign Content
  fb_clickid: Facebook Ad Clickid
  language: en
  environment: production
  release: NULL

Notice that the above payload contains zero personal data that could be traced back to the user.

Other statistics

We keep separated statistics for many other parameters, including but not limited to pages, devices, countries and browsers.

The following is an example of how we store device specific statistics.

  device: desktop,
  number_of_events: 1,
  timestamp: 2022-01-01 00:00:00 (aggregated to current hour)

It works the same for all other stats.

Step 5: Counting session duration and bounces

When the user leaves the website our script attempts to send a 2nd network request using navigator's beacon; which will succeed most of the time - depends on the type and version of the browser. However, it will fire most of the time since it is supported by most of the more popular browsers.

When the 2nd request fires we receive only a subset of the previous informations; the event, the user's fingerprint, session - to identify the currently active session and the current date. From all these information we cal calculate and set the duration the user spent on the site - based on the current session id and propagate all the different statistics, dependent on the information.

We can then later on determine if the visit was counted as a bounce, based on criterias set by you.

Step 6: Everything is processed

That's it!

We jsut processed and saved your visit to any website using Undicat Analytics.

Here' how our data-journey looks like, visually

And as always, if you have any questions about how we process data, you can contact us.

Fill the form

By signing up you agree to our privacy policy

Simple, transparent and honest pricing

No contracts. No suprise fees.

Events / month200,000
Total sum:$2000/month
$2000/ month

Perfect for smaller businesses and for personal projects

Infinite data retention
Unlimited Seats
Unlimited Sites
$2500/ month

Perfect for larger businesses with a higher visitor count

Infinite data retention
Unlimited Seats
Unlimited Sites
$3000/ month

Tailored for agencies managing many sites

Infinite data retention
Unlimited Seats
Unlimited Sites

Can't find a suitable plan?

Contact us

We will find a suitable solution for you and your business