Authorize the option of a privacy focused, GPDR & CCPA compliant alternative to Google Analytics in the policy ?
Hi EF Team!
This ticket is a follow up of helpdesk#2630 (closed)
As we re-evaluate GA for our projects, we are trying alternatives and looked at Umami. Umami is OSS and privacy focused, fully GDPR & CCPA compliant without any specific setting. It does not collect any personally identifiable information and anonymizes all data collected. Users cannot be identified and are never tracked across websites. (It also is simpler, more straightforward and needs little resources) and to us it would fit the bill feature wise. I think it would make more sense for the Foundation to validate such a solution for projects instead of stating Google Analytics with specific settings is the only option. Would the Eclipse Foundation consider adding this as a preferred option in its policy? Is that a topic we (Obeo) should bring to the board ? WDYT ?
Activity
added GDPR label
added team:webdev label
marked this issue as related to helpdesk#2182 (moved)
@cbrun Thanks for reaching out on this topic.
I'm fully supportive of exploring alternatives to Google Analytics, especially since I've already set an annual goal for my team to improve web analytics accessibility for projects, with a focus on privacy.
Currently, we are considering replacing Google Analytics with a self-hosted Matomo instance for project analytics. We plan to create a custom plugin that will allow us to grant access to our PLs and committers to this service.
It's important to know that one of the key requirements for this project is to ensure that all committers and PLs have access to project website analytics and these users should only have access to analytics related to their respective projects.
While researching, I found that Umami has a modern API that could help manage teams and users: https://umami.is/docs/teams-api
However, the absence of SSO/Open ID Connect support is a concern. It wouldn't be ideal for our users to maintain separate credentials for access. However, I can see that SSO is slated for implementation in Q4, according to their roadmap: https://trello.com/b/LIIz6ypc/umami-2023-roadmap
Although we're leaning towards Matomo, we haven't started the implementation phase. This means that we still have some time to pick a different solution such as Umami if we think it's a better option for us.
Now that I am aware of Umami, I intend to dedicate some time to exploring it further. I'll deploy a local instance to experiment with its features and assess whether it aligns with our requirements.
@cbrun If you have experience using Umami and are willing to share insights, I'd be interested in scheduling a call to discuss the platform further. Please let me know if you're open to this idea. At the same time, I could discuss some of the constraints that we have to see if you have solutions for those!
As for bringing this to the board, I believe it's worth considering. I suspect that doing so may help prioritize this initiative.
Thanks for the quick response, I'm excited to learn you are working on it!
Matomo seemed more complete than Umami when I looked at it. I favored Umami because of the "no cookie tracking," which means there is no specific consent. We've seen that a decent percentage of users will not consent because of privacy issues (especially in Europe), and that percentage might change. With Umami, we have no strong guarantee that the user is detected as a "returning user"; it might be counted several times as a "new" one, but considering what we are looking at is general trends and variation, that seemed a good tradeoff in regard to "being blind to some of the European users."
I'm open to the idea of discussing this during a call, feel free to ask, but we started using Umami on a couple of websites a few weeks ago and don't have much more feedback than "it works fine based on our pretty basic needs."
A thing I found pretty useful to us, for instance, and that makes even more sense in the EF context, is the ability to add custom events, just by adding an attribute in the HTML (on an anchor, for instance). In doing so, we can also count downloads (the event is sent when the user clicks) without having to process log data from the underlying download servers/mirrors.
-
Would the Eclipse Foundation consider adding this as a preferred option in its policy?
With that question, I assume you are referring to their cloud offering. Based on my review of their pricing page, https://umami.is/pricing it seems we'd need to pay $9 per month per project to ensure that all project committers and PLs have access to the data (Unlimited team members).
That requirement is why I am favouring a self-hosted instance solution at the moment. Unless we change that requirement, I feel that it would be hard to scale that option...
With that being said, I'm definitely open to hearing any ideas on how we could address this challenge.
//cc @pwhited3w @droy
Edited by Christopher Guindon Oh no I wasn't referring to the cloud offering, I would definitely go for a self hosted too in your position or tell the project they can use that with their own hosting/or cloud offering. My understanding of the current policy [1] - section 7 - is "it's either google analytics with a specific configuration, or nothing", from this I infer we have no authorization to add umami on one of the Eclipse hosted website. Correct me if I'm wrong as I'm not sure if what umami provides qualify as 'user data'.
-
Hi @cbrun, I'm currently exploring our options this quarter around your request to approve compliant alternative to GA. I would like to share with you my thoughts to see if you have any feedback for me that could be useful!
It's worth noting that I recently came across https://counter.dev/, which seems like another intriguing free cloud offering option.
Right now, I'm evaluating the costs of expanding our website analytics platform list with free options (like Umami and counter.dev) versus investing in a self-hosting solution (like Matomo or Umami) that would require a significant upfront investment from the foundation for rollout and maintenance but would give us more control over data and permissions.
From my initial testing, Umami and counter.dev are both straightforward and user-friendly (counter.dev is exclusively cloud-based). Umami offers both self-hosted and cloud options, with the latter being free for only one user. To adopt Umami Cloud, we'd need to adjust our policy to allow projects to have only one user with data access.
Umami self-hosted seems to meet our needs except for the missing OpenID Connect support. Without this, users would need to maintain a separate password for Umami alone, which isn't ideal.
On the other hand, Matomo self-hosted does support OpenID Connect, and they say they offer a robust API for managing users, websites, and permissions, assuming we develop a sync script similar to what we have for GitLab and GitHub. While Motamo, offers more features it would also be the most costly option for the foundation to maintain and support.
At the moment, I'm leaning toward giving projects more flexibility with expanding our list of approved platforms, rather than enforcing an on-premise solution for all projects.
Do you have any comments or concerns regarding my assessment and investigation so far that you believe I should take into account before reaching a decision?
Edited by Christopher Guindon
added statein discussion label
mentioned in issue helpdesk#2182 (moved)
moved from helpdesk#4406 (moved)
-
Hi @cbrun - We published a new version of our Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy in December https://blogs.eclipse.org/post/christopher-guindon/policy-update-eclipse-foundation-hosted-services-privacy-and-acceptable and I am happy to report that Umami was added to the list of Approved Tools for Collecting Website Statistics!
Thanks for your suggestion!
assigned to @cguindon
