Google Analytics has a paid tier but I remember someone on reddit joked like the price is probably too high because they don't even show it publicly...

In fact, you don't even provide a demo page of your own analytics, so how exactly is a anyone supposed to judge whether or not you're the "best", not to mention be comparable to something like Plausible, which has always shown its own analytics as a demo experience.

There's definitely a market for this kind of analytics (many similar products have been launched in the last 2 years), but you should probably rethink your strategy a little bit.

At the moment, the site feels quite bland (maybe it is a side project, I don't know) and you should perhaps focus more on explaining how you achieve certain things (E.g. How exactly are you compliant?).

First, there's a Javascript snippet you add to your site to set up Beam. That Javascript snippet loads additional Javascript from beamanalytics.b-cdn.net. If you add the Beam provided Javascript to your site, every time a user visits your site, their IP address will be shared with beamanalytics.b-cdn.net. If the user didn't consent to sharing their IP address with beamanalytics.b-cdn.net, you do not have a lawful basis[1] for sharing the user's IP with beamanalytics.b-cdn.net.

Second, there's this notion that because Beam hashes IP address that "anonymizes" the data[0][2]. According to GDPR, this is actually "pseudonymisation"[3]. If you know what hash function is used, you can still tie back the hashed data to the original user. Pseudonymized data still meets the GDPR definition of personal data[3] so applying this hash doesn't actually do anything in terms of helping with GDPR compliance.

  [0]: https://beamanalytics.io/data
  [1]: https://gdpr-info.eu/art-6-gdpr/
  [2]: https://news.ycombinator.com/item?id=35539476#35546091
  [3]: https://gdpr-info.eu/art-4-gdpr/

Loading data from a third party can be GDPR compliant, but isn't always. One legal basis for processing personal data is "legitimate interest"[0]. Legitimate interest is incredibly vague. In short, it allows you to process data as long as doing so is necessary or of critical important to your business.

As an example, in order for someone to visit your website, you need to receive and process their IP address. That's just how TCP works. Since you have a "legitimate interest" to process their IP address so they can visit your site, you don't need to ask for consent before processing their IP. Similarly, since DDOS prevention is critical for maintaining your website, you are allowed to process IP address for DDOS prevention as long as you intend to process the IP only for DDOS prevention.

For your specific question, a website loading an external font resource would likely fall under legitimate interest since the font is necessary for the website to function.

Since user analytics is not necessary or critical to a business, you cannot share IP address with a third party if the intent of doing so is so you can perform analytics on your users.

[0]: https://gdpr-info.eu/art-6-gdpr/

Google Fonts was ruled to be non-compliant: https://www.theregister.com/2022/01/31/website_fine_google_f...

You can work around this by just uploading the font to your own website.

I think a pure-play hosting service is probably fine for hosting fonts and relying on legitimate interest, but that's not Google, who is not being paid directly for hosting the fonts, and who actively wants to use the users' information for marketing purposes that the user clearly does not want.

In practice, I doubt someone will go through the legal trouble for something like jQuery. If you want to be sure, self-host your resources; it's not like using CDNs will give you any speed advantage anymore with modern browsers isolating websites.

If you pay the CDN, and they're not using your customers' data to make money, then probably not.

If you don't, or they do, then it's a violation of EU law if you do not allow (at least) EU users to easily control the use of that CDN. If you are making money, and you try telling the regulator that for your business, that you need (legitimate interest) to have jQuery hosted by a CDN that is using EU personal data illegally, then you might get a fine if they are reachable by the EU, because very few judges are going to believe that bullshit.

https://www.simpleanalytics.com

They mention this in the pricing page:

> After your trial expires, your plan downgrades automatically to the basic free version.

But it's not explained what are the features of that plan.

https://umami.is/

What you mean with release :-) Le't see if I can do it.

It's on another repo because for self-hosting we "white label" it stripping the logo and so on.

"Proxying Beam Analytics through Cloudflare"

"Use proxying to avoid adblockers distorting your data"

How does bypassing content/tracking/ad blockers fit into your privacy narrative?

• https://goaccess.io/

• https://www.awstats.org/

Both of them are free/open-source.

This... isn't possible

Is there more documentation on "custom events" (listed on the pricing page)? I assume this is just an API I can arbitrarily ping. Can that be used for cohort/funnel analysis instead of a /page; e.g. for a single-page app?

That’s why I still prefer analytics solutions that can be self hosted.

Is it because, working for a big company, there's a sales target on my back and you want to use that to extract the maximum tolerable pricing from my group, just because you can?

Is it because my use case is so complicated you think that you need to offer me value-added services that help you achieve the margins you want?

Why is it that you, even just as an individual with a startup idea, have already fallen into this kind of pricing behavior? Where did you learn to do this? Do you already have VC-backed sales people telling you to do this?

Why is this such a common practice?

Maybe that's why I use other services that at least treat me the same as everyone else.

GDPR compliance is not to be confused with privacy.

You don't have Data Protection Officer (even if you have one, you ought to publish their details). Neither does Plausible.

Your privacy policy lacks details, e.g.: where you process data and what is data retention.

You are incorporated in not an Adequate Country, meaning you face challenges becoming GDPR-compliant without additional measures that span beyond SCCs. Similarly to Fathom (BC is not under PIPEDA, hence is not adequate).

Privacy-friendly? Probably. GDPR-compliant? No.

1. We are incorporated in the UK. I could be wrong but I think the European Commission did indicate that the UK was an Adequate Country?

https://commission.europa.eu/law/law-topic/data-protection/i...

2. For the details that our privacy policy lacks, I think they can be found in our Data Policy. Any further issues, please let us know.

https://beamanalytics.io/data

3. On the Data Protection Officer, I think one is only needed if sensitive data on a large scale is processed.

https://commission.europa.eu/law/law-topic/data-protection/r...

The definition of sensitive data can be found on this EU site and Beam does not process any of this type of data.

https://commission.europa.eu/law/law-topic/data-protection/r...

"its core activities involve processing of sensitive data on a large scale ---> OR <--- involve large scale, regular and systematic monitoring of individuals"

Any analytics provider is fundamentally doing "large scale, regular and systematic monitoring of individuals".

I built this to track my own sites but I am curious if anyone else cares. I created a landing page to see if there’s any interest.

https://protectivemetrics.com

The product is working on a few sites of my own and is hosted on a raspberry pi in my home office. I’d need to do some work to make it available for others, but I don’t want to invest more into it unless there’s any interest.

Quoting from WP 243 Annex provided by the EU:

"The notion of regular and systematic monitoring of data subjects is not defined in the GDPR, but clearly includes all forms of tracking and profiling on the internet, including for the purposes of behavioural advertising. However, the notion of monitoring is not restricted to the online environment."

The link is here

https://ec.europa.eu/information_society/newsroom/image/docu...

We anonymize and aggregate all data so can't track or profile any users, or do such monitoring offline.

2. Your subprocessor uses AWS. No way to stay compliant if you transmit visitor IP to US cloud (even if they use European servers).

3. Sadly, wrong. You should immediately consult privacy professional. DPO is necessary. There are 3 tests.

https://ico.org.uk/for-organisations/does-my-organisation-ne...

Answer to question 2 is yes btw.

You are not compliant without DPO and because you are using AWS, even if indirectly.

1. Glad we're in agreement!

2. We agree it is not GDPR compliant to transmit IP address data to the US. This is why we salt and hash all PII data so no IP address data is sent to the US. Please see our data policy.

https://beamanalytics.io/data

3. Thank you for your suggestion. We have already consulted privacy professionals and have been assured no DPO is required.

Thank you for this conversation about GDPR. We appreciate your interest in Beam's work.

Can you share more detail on this? On this page[1], I see this:

  hash(pepper(salt(ip address + user agent data))) = anonymized hashed data

[1] https://beamanalytics.io/data

There was a case of Doctolib in the EU. French authority investigated Doctlib for using AWS.

They got off the hook because data was encrypted in the EU, outside of AWS and the encryption keys were inaccessible to AWS.

Similarly Sendinblue uses GCP and AWS as dumb storage of externally encrypted backups.

There are valid use cases. But these are very limited.

In theory Amazon could license their brand and software to an independent (!) European company to offer a EU-AWS.

Basically if an American judge/agency can order Amazon to hand over European private data and they have the ability to comply without involving a European court the service is not GDPR compliment.

Now in practice this isn't how things are done but to the best of my knowledge the law hasn't changed (yet) and national dpas are starting to tighten the screws (slowly).

If I recall correctly there are EU-US talks to create Privacy Shield #3.

Every so often I see something like this:

https://www.mayerbrown.com/en/perspectives-events/publicatio...

I suspect the UK is planning a number of changes that may change this, so even though I'm British, for the avoidance of doubt I prefer companies actually hosted in the EU and that will agree to conduct business in Europe (and thus under EU courts, rather than GB ones).

> 3. On the Data Protection Officer, I think one is only needed if sensitive data on a large scale is processed.

You are totally incorrect about that.

https://ico.org.uk/for-organisations/guide-to-data-protectio...

1. The GDPR is regulation from the European Union

2. PIPEDA has an Exemption order for BC (British Columbia, Canada) and applies "in respect of the collection, use and disclosure of personal information that occurs within the Province of British Columbia".

Firstly, the Exemption order states "Whereas the Governor in Council is satisfied that the Personal Information Protection Act, S.B.C. 2003, c. 63, of the Province of British Columbia, which is substantially similar to Part 1 of the Personal Information Protection and Electronic Documents Act, applies to the organizations described in the annexed Order;"

Secondly, which part of BC's Personal Information Protection Act would undermine it's adequacy ruling under the GDPR?

Finally, let's get into Fathom's pageview/event collection script and explain how it works:

1. There is no collection, use and disclosure of personal information that occurs within the Province of British Columbia

2. EU traffic is automatically routed via EU Isolation and processed on German-owned servers. This allows us to stop US government snooping on EU traffic

3. Fathom Analytics is incorporated in BC. But nobody in BC has access to our EU Isolation infrastructure. I'm the CTO of Fathom Analytics and I have access to our EU Isolation infrastructure. I'm not in BC. Additional access to EU Isolation is from Germany only. Heck, not even GitHub Actions has access to EU Isolation, we self-host GitLab to keep things completely isolated. We put a lot of time and effort into this.

I'll wait back to hear back from you on which parts of the BC's PIPA undermine the adequacy ruling. Our lawyer here in Canada is incredibly well versed in Canadian privacy law, so we can definitely loop her in if there's any confusion here.

I hope that addresses your point and helps inform other people who may be reading this.

> To date, Alberta, British Columbia, and Quebec have privacy legislation that takes commercial activities in those provinces out of the federal jurisdiction through the "substantial similarity" exemption to PIPEDA. Federal privacy law defers to provincial law if a province meets the substantial similarity test, providing a baseline of privacy regulation across Canada. This division of authority is important, because for provinces recognized as substantially similar, their laws have not been given the stamp of "adequacy."

I might have framed my statement too strongly. Fathom can be GDPR compliant assuming additional contractual clauses are in place. That is what is mentioned in the linked IAPP assessment.

> 3. Fathom Analytics is incorporated in BC. But nobody in BC has access to our EU Isolation infrastructure. I'm the CTO of Fathom Analytics and I have access to our EU Isolation infrastructure. I'm not in BC. Additional access to EU Isolation is from Germany only. Heck, not even GitHub Actions has access to EU Isolation, we self-host GitLab to keep things completely isolated. We put a lot of time and effort into this.

The same could be said about Amazon, Google, and Azure employees and their data centre employees in Europe. What matters is effective control. You are not in BC but the company, and your position and responsibilities are governed by the laws of the province of British Columbia.

Although, in the case of Canada, SCCs will be actually effective as there are no surveillance laws similar to the US.

So my question to you is: Which part of the Personal Information Protection Act in BC would undermine the EU's adequacy decision towards BC? The reason I'm pushing on this question is because the "stamp" occurs for a reason. Please let me know where the PIPA would lead to the European Commission labelling BC as inadequate.

2. We're mixing things up here with Amazon, Google and Azure. Those companies are subject to FISA 702[1] and EO12333[2]. We are not subject to these surveillance laws here in Canada. I've spoken at length about this before, about how the US government could compel one of these companies to secretly spy on people using their EU infrastructure. So our company is not in the same position.

I'll wait for your specifics around the PIPA.

[1] https://en.wikipedia.org/wiki/Foreign_Intelligence_Surveilla... [2] https://en.wikipedia.org/wiki/Executive_Order_12333

RE: 1

I am looking at this document: https://www.bclaws.gov.bc.ca/civix/document/id/complete/stat...

I assume this is up-to-date.

I will take one example: the Right to be forgotten. I don't see provision that satisfies the right to be forgotten: https://gdpr.eu/right-to-be-forgotten/

You seem to have a more in-depth understanding of PIPA. Can you point me towards a similar requirement in PIPA?

Looking at C-27, it appears that even PIPEDA is playing catch-up. But that was CPPA.

Btw. I am not suggesting Adequacy is always decided on privacy laws being EXACTLY like GDPR. Given the only reference to adequacy I found thus far was based on a 2001 review, I am not sure what would be appropriate criteria here beyond access to "an appropriate" level of legal protection.

The text in IAPP article refers to the adequacy of PIPEDA. Not Canada. It is actually interesting that there is no adequacy with Canada, but only with Canadian PIPEDA.

RE 2:

Right, I was referring to the fact that customers of Fathom sign contract/get into agreement with a company in British Columbia under its laws. It is mostly irrelevant where their CTO resides (it would be relevant if you resided in a non-adequate country, as your privacy policy would have to account for relevant data transfers).

The background of Schrems II was that the US government can compel US companies to track foreign nationals and it would be lawful under US law. This is where the argument of "company in X under Y laws" comes into play. For example, Amazon is a US company. An EU subsidiary is still subject to it's parents control. If that parent is a US company, it's subject to US surveillance laws. Hello Schrems II.

So I'm not fully following why we're having a discussion around processing happening in Canada when personal data (IP Address) hits our EU Isolation infrastructure.

If you have any sources you can cite where the European Commission states BC as an exemption to Canada's adequacy ruling, please throw it back to me. I've not seen that.

Question: "How can any of your users verify that you're not selling their data?"

There's no way other than believing your word. And you have access to the DB. Therefore, given that your claims and the ones of Plausable, can't actually be verified by their users, any time, how is your service different from Google Analytics than? At least with Google Analytics one knows that there's no privacy.

In your case the user doesn't know it with certanty because he can't verify it, but he assumes that everything is performed correctly and privacy-friendly -- by taking your, and the owners of Plausible, word for it. It's based mostly on believe, that is.

(1) Have the picture of your face BIGGER. Then SMILE and be HAPPY, even a little enthusiastic.

(2) Don't drop your voice volume at the end of sentences. Speak VERY clearly: Enunciate the words clearly. E.g., write out the narration and practice reading it.

(3) Be sure the room and microphone give good sound quality. Have the sound volume HIGH, TOO high, and let the users reduce the sound volume at their end if they wish.

(4) If you know a women who would do you a favor, have her do the narration. Write out carefully a clear narration you want her to say. Better still if she is reasonably pretty, not glamorous but professional and still pretty.

(5) There is a lot of numerical data on your screen that is unreadable to 80+% of your target audience. If some text or data is unreadable, then reformat it or just omit it from the presentation. Generally don't put anything on the screen that is unreadable. In simple terms, use a large font 100% black on a white or at least light background.

(6) Early in the video there is a graph. There are two curves that are easy to see, but there is annotation on the two axes that is unreadable due to being too small and not dark enough. For such annotation, make it big, black, and easy to read.

(7) You may be assuming too much for your best targeted audience, the one with nearly all your candidate customers. E.g., I'm doing a startup, a Web site, have the code running as intended, likely will want some analytics, but so far have had no occasion to find out just what "Google Analytics" is. So, I'm a candidate customer, but to sell to me something or someone will have to give me at least a 101 level introduction to Web site analytics -- it is to your advantage for the part of your audience that needs the 101 introduction for that someone to be you.

Correct

> what happens if my hobby site gets an unexpected surge in traffic?

Nope. You don't even need to put in CC to sign up. You'll only get billed if you explicitly upgrade. That being said if you are consistently over for many months, we may cut off data ingestion and dashboard access!

https://clarity.microsoft.com/pricing

Otoh, my former compliance officer much preferred using MS's product since it explicitly states that it's GDPR and CCPA compliant, while regulator and court decisions against google analytics were piling up in one of the markets we served (EU).

The simple fact of sending PII such as IP addresses to a third-party for something that can trivially be done via analyzing existing server logs (without introducing a third-party) already puts this on shaky grounds from a GDPR point of view regardless of everything else.

The GDPR mandates that the entire data processing cycle maintain a high standard of data protection. This implies that personal data transfers to non-European nations are allowed only if they ensure an adequate level of data protection. Otherwise, contractual agreements (SCCs) between data exporters and importers may translate GDPR's provisions into an enforceable agreement with the foreign importer, ensuring their processing aligns with GDPR.

The US had an adequacy decision termed "Privacy Shield," which was revoked due to concerns surrounding the rule of law vis-a-vis US mass surveillance laws. Due to similar reasons, contracts with US-based data importers may also be invalid. Additionally, using EU-based services from US-controlled companies is increasingly becoming worrisome.

Beam's approach relies on a weaker variant, which leverages a hash function to derive a pseudo-random ID from user-identifying information, such as the IP address. Although Beam's technique circumvents the need for a large lookup table, an unscrupulous server operator could log the daily key and use it to recover the original data from hashed IDs.

The flaw in this approach is that it still hinges on identifying data. While it serves as a good compliance and security measure, it doesn't alter anything significant from GDPR's standpoint. The same applies to competitive solutions like Plausible or Fathom.

Disclaimer: Consult with your legal; I am just a product guy. Explored the field to do a similar product a while ago.

[0] https://gdpr-info.eu/art-6-gdpr/

> The flaw in this approach is that it still hinges on identifying data. While it serves as a good compliance and security measure, it doesn't alter anything significant from GDPR's standpoint. The same applies to competitive solutions like Plausible or Fathom.

This is where the technical compliance meets legal compliance. There is always a risk of breach and malicious actors circumventing even the most advanced technical solutions.

It is not full proof, but having SIGNED Data Processing Agreement can go a long way in case of such a violation. It won't help with technical lapses, but can save your business, by pointing at the legal obligation of your data processor for them to take some heat.

Having a partner from a country with a compatible legal system helps a lot in the execution of such an agreement. We no longer deal with non-EU/EEA entities and avoid anyone who uses US-cloud for data processing. The risk is just not worth it. Not to mention, this simplifies Transfer Impact Assessment.