Keytiles system GDPR & Privacy policy

Content of this page

About visitor tracking related data collection and handling policy - in general

Keytiles is developed in Europe, where GDPR was born. And we at Keytiles are taking this very seriously!

The website owners to get good quality, statistically relevant information / feedback about their content performance do NOT need to know who you are at all!

The Keytiles system

  • Does not collect / store / log any sensitive information
    About your website visitors or any other information which suitable to identify the visitor as a person himself. 
  • Never connects visitor activity cross-websites or different devices.
    This is not allowed and not possible - guaranteed by system and component design.
  • Never shares any information anyhow with 3rd parties
    We do not need that as our business model is built around subscription fees and not around gaining extra profit using your tracking data

Keytiles is a paid service. The website owners are paying us and our business model is 100% based on these subscription fees. We do not need any "hidden agenda" (e.g. trying to build profiles out of your visits you make on many websites) to run Keytiles as a business.

What information is available for Keytiles during collection of visit data?

When a visitor of a tracked website generates a hit (by visiting a content of the tracked website) Keytiles will know / have access over the following information:

  1. The IP address of the visitor's machine
    which is basically personal data - due to GDPR 
  2. The hit-related information
    to see complete list the best idea is to quickly check our Hit Collection API specification

About IP addresses

As Keytiles is a HTTP based service due to the nature of the HTTP protocol our system of course has access of this information.

But Keytiles does not store (or even log) the IP address in the exact form as we got it. Because at the very first moment of the hit processing we do apply IP address anonimization method, which means that the last element of the IP address is zeroed out - from this moment tracing back the IP to concrete endpoints => customers => persons is no longer possible even with the ISP data at hand

About hit-related data

Take a look into our  Hit Collection API specification (the data Keytiles system gets during a hit) - you find all the fields and their documentation there. This is the information Keytiles knows about a hit.

In the above API specification we are marking a few fields with "IMPORTANT NOTE: This is a sensitive field! ..." markers. These are fields where the inbound value is a) free text basically b) Keytiles might store in the database.

Hit-related data - generated by our own JavaScript tracking code

When the hit data is collected and sent by our own JavaScript tracking script (we provide for website owners to build into the page) then our tracking script is always using randomly generated identifiers in these fields. So there is no violation of using sensitive information for sure.

Quick list of fields related to some kind of visitor related IDs:

Hit-related data - generated by NOT our own tracking code

The  Hit Collection API is provided for data container (tracked website) owners for integration purposes. This means that basically customers of us can also use it to send in hit data, and these customer-developed codes are out of our hands... Of course we explicitly forbid the "not appropriate data sending" in those marked fields in our Data Tracking - Terms & Conditions document (violation of these principles result in immediate actions from our side) we can not so we do not take responsibility for any consequences caused by the intentional or unintentional misuse of our API endpoint done by customer-developed codes!

Identifying returning visitors, capturing visitor's browsing history

As any other analytical tool Keytiles also has a key concept around being able to recognize somehow if a visitor of yours is re-visiting your website - referred as returning visitor - furthermore which pages of yours were visited during one continuous visit-session.

To reach these goals we do store information on the visitor's device, namely the following:

Cookies placed/used by Keytiles JavaScript tracking code

To be able to recognize returning web browsers (your visitor is using) Keytiles is using Cookies at first place.

It is very important to note that we are NOT using 3rd party Cookies!

Unlike many other 3rd party analytics tool provider - all Cookies created by Keytiles service belong to your website domain and not to any of our domains like e.g.! And this means that any of our customers (website owners) - if they wish - can provide mechanisms for visitors to manage these Cookies.

Cookies deployed by Keytiles tracking script are all prefixed with "kt_" prefix so it is easy to find them.

Cookies are created/used by Keytiles tracking script:

  • kt_uniqueWebClientId
    A randomly generated UUID style string value we use to uniquely identify the web browser (of your visitor) now and in the future.
    As a) this is a random string it does not contain any sensitive information and b) this is on a per Container level (not shared among multi containers)
    means it is not suitable to trace back the person behind it not even on guessing level, so this Cookie is safe from GDPR perspective
  • kt_userConsentDenied
    Created only via Tracking Script API .setCookiesUserConsent() method call - storing the fact the visitor does not agree to store any information on his/her device.
    Given the fact this is a boolean value naturally does not contain any sensitive information and not suitable to trace back the person behind it so
    this Cookie is safe from GDPR perspective

Info in Local/Session Storage placed/used by Keytiles JavaScript tracking code

In order to provide some more (non critical but nice to have) features Keytiles tracking script is creating the following entries. Please note that they are all prefixed with "kt_" prefix so it is easy to find them.

  • kt_tileIdByUrl
    This is a map of urlHash => tileId with max 128 entries. This is used to save server resources by being able to send in the referrerTileId (user came from) when visitor visits a content of the website - in case the visitor came from another internal content.

Browser fingerprinting

Keytiles tracking script is using browser fingerprinting techniques to be able to identify the visitor's device (at least with a good chance) even in the case if cookies are disabled.

This information is not a sensitive information - as this fingerprint can not be used anyhow to identify a person behind it.

Furthermore the browser fingerprint is always generated again and again on the fly - it does not store or save any information on your visitor's device

Therefore this mechanism is perfectly safe from GDPR perspective.

Can I get rid of Keytiles cookies and locally stored data?

Yes of course! And on the top of that it is very easy!

You have two options for this:

  1. With the help of the TrackingScriptAPI provided by the Keytiles tracking script. For more information please refer to the TrackingScriptAPI reference
  2. Doing this by your own (from JavaScript) - all Keytiles related cookies / local storage entries are prefixed with "kt_" prefix so it is easy to find them - as we stated already here and here.

OK but will Keytiles still function without the cookies / local storage if I disable them?


The only impacted area would be the "Identifying returning visitors" topic as there the kt_uniqueWebClientId cookie brings 100% chance for successful identification. But even if we lose it the browser fingerprinting mechanism (which is backing the pseudoUniqueWebClientId value in the sent hit-data) would still provide a "close to 100%" efficiency. So statistically speaking this is not a relevant difference.

No other functionality of Keytiles is impacted from your side.

Where is my tracking data stored? Who has access?

Keytiles is using Hetzner Cloud and so far we are running in Datacenter located in Germany, Falkenstein 

Apart from our technical colleagues nobody else has access to the servers (well, under certain circumstances like hardware failure or similar Hetzner's staff can access the servers physically of course, but this is natural)

We are not sharing the data - not even partially - with any other 3rd parties.

Any more questions?

In case you have any questions please contact with our support at