Plausible Analytics is an open source alternative to Google Analytics. Our mission is to reduce corporate surveillance by providing an alternative web analytics tool that doesn’t come from the AdTech world. To learn more, you can check out the live demo of our product and read more about us.

We are looking for a senior product developer who can confidently ship new features and evolve our system architecture at this growth stage. Our team is small (3 devs) and your impact will be big.

We use Elixir/Phoenix, React, PostgreSQL, ClickhouseDB, Terraform/Ansible

For more details, see: https://plausible.io/jobs/product-engineer

The production environment that crashed due to Clickhouse OOM was our hosted product a while ago :) After that, we haven't had any downtime on our Clickhouse DB for over a year.

The issue with disk space stems from a bad default configuration. Clickhouse used to have EXTREMELY noisy debug level logging enabled by default with no rotation. This has been fixed in our hosting repo[1] so you get sensible defaults.

If you don't want to worry about downtime, planning disk space or compute capacity, then that's exactly what we offer at https://plausible.io. We process and keep the visitor data on our Hetzner servers in Germany.

1. https://github.com/plausible/hosting

Google has made sure that analytics for Google Ads works best within their own walled garden. Same with Facebook and Twitter with their Pixel products.

Instead of using the Referer header or utm parameters as intended, these large corps send obtuse random IDs (gclid, t.co/ links) which only they can correlate to an ad, search query or tweet using their internal database.

So until there is anti-trust action in this space towards more oppenness and competition, you're stuck with the ad provider if you want tight integration between ads and analytics.

Hi HN! I'm the technical founder of Plausible Analytics [1], I've been the only full-time developer on the project since the beta in 2018. We are growing steadily and need to start upgrading our infrastructure to keep up with the demand. We're looking for help with:

  - Deploying and running our production workloads
  - Creating and testing our disaster recovery protocols. From single node failures all the way to whole datacenter failover scenarios
  - Defining our monitoring, alerting and incident response practices
  - Enabling horizontal scale-out of our application services and database systems
  - Automating operational tasks
  - etc

The company is fully bootstrapped and independent from any investors. This means we can grow at a sustainable pace without having to satisfy external growth targets and timelines. We can take time to get things right and ship stuff that we're really proud of.

We are currently just 3 people which means there's little bureaucracy and politics like in larger companies. Things go smooth, you won't be sitting in meetings all day. It's a pure engineering role with ample time and space to actually focus on doing good work. There are pros and cons to how we work but we really enjoy working in a small remote team with tons of autonomy. This is how we plan to keep it.

If you're interested, do check out the full job description here: https://plausible.io/jobs/infrastructure-engineer

[1] https://plausible.io/

As with everything we will integrate and test with our large customer base on the hosted version and then release it for self-hosted as well. Next release is planned in Q2.

1: https://github.com/plausible/analytics/pull/1466

I didn't find much beyond sponsoring official community events[2]. The impression I got was that there are no paid core developers for PostgreSQL, is that correct? If so, what's the best way to support the project financially?

1. https://plausible.io/giving-back 2. https://www.postgresql.org/about/donate/

I think Matomo is quite similar to Google Analytics which many people feel is bloated and confusing from the user's perspective. The idea with Plausible is to simplify web analytics and make it more understandable compared to what GA/Matomo offer.

Granted, Matomo does have more depth and features in some areas. It can be the better choice if you want to go very deep into analytics and need some power features that Plausible might not support.

We wrote a little (clearly biased) comparison with Matomo[1]. I hope we're not too harsh on it because Matomo is a great project and still a good fit for many people. But obviously we feel like a modern and simplified take on web analytics fits better for the majority of website owners.

1. https://plausible.io/vs-matomo

I'm the maintainer of the project and it's so heartwarming to see it being recommended on this forum.

All the projects mentioned here are great. What I think sets Plausible apart is that we've managed to create a profitable business around a 100% AGPL-licensed codebase (i.e. no dual-license for enterprise version). This means we can keep investing into the product and adding new features without being in the 'thankless OSS maintainer' role that so often ends in burnout.

We're currently working on importing historical data from Google Analytics into Plausible[1] which should make switching even easier for many folks. Stay tuned.

1. https://github.com/plausible/analytics/pull/1466

Interesting you say that. There's no reason Plausible could not be used like AWStats. Parsing logs is just a different ingestion mechanism and we already provide self-hosting via Docker. On principle it wouldn't be too difficult to drain your logs into a Plausible instance or just run it on the same host along your web server.

We ran a test last summer and found the stats from our JS-based tracker much much much more usable: https://plausible.io/blog/server-log-analysis

So this is why we haven't put too much effort in log analysis. The stats we got from AWStats were mostly bot traffic with no good way to get rid of them.

Have you run AWStats and Plausible side-by-side? Do you not have ~90% bots in your logs?

Just a heads up, I think registering a plausible event in the `onclick` handler could introduce a race condition. If the page navigates and unloads before the request to Plausible is sent, you might miss the click in analytics.

The code here is a bit obtuse, but for our Outbound Link tracking feature we set a 150ms delay for navigation [1]. It should give enough time to complete the request to Plausible.

I am planning to tackle this limitation by seeing if we can implement custom event tracking with `navigator.sendBeacon` instead.

1. https://github.com/plausible/analytics/blob/master/tracker/s...

https://itsfoss.com/making-the-business-source-license-open-...

We also have a separate repository with examples and code for how to host Plausible Analytics with docker-compose: https://github.com/plausible/hosting

The hosting repo includes everything you need including databases, MaxMind GeoIP database, reverse proxy for SSL, etc.

We don't host with docker-compose ourselves because we want to scale our databases independently from the app server.

I'm not sure I understand your question. Secrets should never be committed to source control, whether the repo is public or not. Being open source does not change how we manage secrets in the slightest.

Does that answer your question?

https://papercups.io/

https://www.getoutline.com/

https://write.as/

https://www.flagsmith.com/

https://posthog.com/

For https://plausible.io we added a daily salt to the hash for this exact reason. By deleting the salt at the end of each day, the hash becomes impossible to reverse and visitor data can be considered anonymous.

We lose unique visitor tracking beyond one day, but for most sites this is a small price to pay to remove annoying consent banners.

IP address is the only piece of data that we touch that is considered PII under some regulations including GDPR.

The IP address is fully anonymized by hashing it together with a daily changing salt. Old salts are deleted to as to prevent re-identification: https://github.com/plausible/analytics/blob/master/lib/plaus...

According to GDPR Recital 26, anonymized data does not fall within the GDPR at all because data is no longer considered “personal data” following anonymization:

> The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.

We don't show the number sessions/visits at the moment. Most seem happy with the 'unique visitors' number and we don't want to add extra data to the UI unless it's truly useful.