What we collect
Privacy is a fundamental human right. Everything we collect goes through an anonymization process by default, giving you and your visitors peace of mind.
The analytics data is geographically routed through your end-users nearest servers in encrypted form. It is then safely stored within the EU using enterprise-grade security, which simplifies things both legally and infrastructure-wise. Our software is fully compliant with privacy regulations such as GDPR.
Our business is funded by charging for the product, not by hoarding vast amounts of personal data for advertising purposes. That means our business model is aligned for user privacy, and we have no incentive to collect unnecessary data as it increases our liability.
What data does Panelbear collect?
Our analytics script only collects the information listed below.
This is the unique identifier for your web property. We use this to associate the incoming data with your website. This ID is not bound to a single website, giving you flexibility in case you change domain names or have multiple ones for the same website.
We collect the hostname for which the analytics events triggered, for example:
This is the path to the page being visited. For security and privacy reasons we do not include the query string or hash fragment. For example the page "/profile?id=1187&name=Eve" will be cleaned and stored as
The page referrer tells you how the visitor arrived at the current page. For security purposes it is not always included by the browser, and we sanitize it further to not include query params or the hash fragment.
Used to determine the campaign source. It can be set in the URL by using one of the common query params:
utm_source. For example
The campaign query param is used to identify a specific product promotion or campaign, for example
The medium query param is used to identify the medium by which the visitor was referred, for example
We derive the browser family from the user agent, for example
Safari. It's important to note that we do not store the raw user agent.
We derive the device type from the user agent, for example
We derive the OS family from the user agent, for example
We collect the width of the device used to display your content. It's truncated to the lower bound 100th pixel as part of the anonymization process, for example
1240px would both be stored as
Timestamps are essential to be able to provide you the dashboards and visualizations on Panelbear. Without them, you wouldn't be able to know how your site performs over time (i.e. this month vs the previous month).
To power the site speed dashboard, we collect insights on how fast your website loads across different countries, devices and pages. It is measured using standard browser API's, if available, and stored with millisecond precision for timing data, or kilobyte precision for transfer size data.
The performance metrics collected include:
- DNS lookup time
- Connect time (TCP)
- SSL time
- Time to first byte (TTFB)
- Download/response time
- DOM and page load time
- Transfer size (headers + compressed document size)
We derive the visitor's country from the request IP as a ISO 3166-1 Alpha-2 code. For example Germany will be stored as
DE. We do not store any location information more granular than the country.
The preferred language as reported by the visitor's browser. For example
The timezone as reported by the visitor's browser. For example
The effective connection speed of the user's device. This helps you understand the strain your website might put on their data volume or how long it might take to load on their device. The collected metric is determined using a combination of recently observed round-trip time and downlink values, as reported by the browser. Some examples are
How does Panelbear count sessions?
We developed a unique two-layer session tracking mechanism that automatically "forgets" about visitor devices, while still giving you useful data.
It's different from plain browser fingerprints, because the resulting session IDs have zero personal data encoded in them. They are completely random 128-bit UUIDs, without a cookie linked to them, and they are not browser fingerprints or user hashes. This is in part possible because the algorithm automatically destroys any link between the visitor that generated the data and the session IDs.
The reason we created this method is because it gives everyone complete peace of mind. Even in case of an absolute disaster and we leaked the session data, you couldn't brute any IP address, User Agent, or sensitive data out of the Session IDs. There's simply no personal data encoded, or hashed into them.
We believe our session tracking mechanism is one of the most advanced out there. It's performant, accurate, and strips out personally identifiable information from the resulting session data. This gives us peace of mind too, as we're not able to trace the data back to an individual. We're simply not interested in it.
For transparency, below you'll find a simplified view of our session tracking algorithm:
- When a new event arrives at our servers, lookup the current 256-bit cryptographically secure random salt, which rotates at least every 24 hours, and is neither logged nor persisted to disk.
- Take two dimensions from the incoming event related to the visitor's device (IP address, user agent), and one dimension related to the website (Site ID).
- Compute an ephemeral bridge key by generating a SHA-256 of the selected dimensions and daily salt. Keep it in-memory, and set it to expire in 30 minutes. To clarify, this is not the resulting session ID.
- Lookup the session ID with the bridge key in an in-memory cache. If found, extend the TTL by another 30 minutes (the session is active). Otherwise, set the session ID to a completely random 128-bit UUID.
- The resulting session ID now contains zero personal data, and within 30 minutes of inactivity or 24 hours, the device bridge key will be destroyed. This leaves no link between the visitor device, and the session ID.
We do not store IP addresses as part of the visitor session data, and do not make use of tracking cookies.
That said, every HTTP request automatically includes an Internet Protocol (IP) address in the request headers, this is how the internet works, and it's not particular to us.
Just like any other service that takes security seriously, we do use IP addresses to prevent abuse using rate-limiting and to power many security features that protect our customer's data. This includes temporary access logs, and active logged-in session verification. Additionally, IP addresses are used to derive other highly anonymized data such as the visitor's country and as part of our anonymous session tracking mechanism.
To clarify, we do not store raw IP addresses for purposes other than security and prevent abuse, and they are not stored any longer than necessary. We do not sell this data to any third-party.