Content of this page
- # About visitor tracking related data collection and handling policy - in general
- # What information is available for Keytiles during collection of visit data?
- # About IP addresses
- # About hit-related data
- # Hit-related data - generated by NOT our own tracking code
- # Identifying returning visitors, capturing visitor's browsing history
- # Browser fingerprinting
- # Can I get rid of Keytiles cookies and locally stored data?
- # OK but will Keytiles still function without the cookies / local storage if I disable them?
- # Where is my tracking data stored? Who has access?
- # Any more questions?
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.
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
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:
- The IP address of the visitor's machine
which is basically personal data - due to GDPR
- The hit-related information
to see complete list the best idea is to quickly check our Hit Collection API specification
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
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.
Quick list of fields related to some kind of visitor related IDs:
- uniqueWebClientId - check the Cookies section below!
- pseudoUniqueWebClientId - check the Browser fingerprinting section below!
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!
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:
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. keytiles.com! 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:
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
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
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.
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.
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.
Yes of course! And on the top of that it is very easy!
You have two options for this:
- With the help of the TrackingScriptAPI provided by the Keytiles tracking script. For more information please refer to the TrackingScriptAPI reference
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.
Your data is not in the Cloud! We are renting dedicated root servers from Hetzner.
The servers are located in Germany, Falkenstein - where Hetzner's data center is located.
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.
In case you have any questions please contact with our support at firstname.lastname@example.org