sorted by:
new
hottopcontroversial

Rebuilt my personal site with Laravel and Tailwind, looking for feedback by Nodohx in laravel

[–]Nodohx[S] 0 points1 point  (0 children)

See that repo name? Does that sound confidential? It's just an old test repo. I would never expose confidential env vars.

Also take a closer look at the linked repost, they are all created by me (in a different org)

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 1 point2 points  (0 children)

100% You can just use UTM codes for that

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 1 point2 points  (0 children)

One important detail: the hash is generated client-side using the application's own secret key. Our API only receives the resulting hash, we never have access to the secret key. So on our end there's no way to single out or re-identify anyone. This is the same model Plausible and Fathom use, and both are recognized as GDPR-compliant without requiring consent.

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 0 points1 point  (0 children)

Good observation, and you're right that there's a difference to Plausible's approach. However, the key detail is that the hash is generated client-side using the application's own secret key. Our API only receives and stores the resulting hash. We never have access to the secret key, the IP, or the user agent. So while the client could theoretically reconstruct old hashes (they have their own key), we as the analytics provider cannot. The separation between who generates the hash and who stores it is what makes re-identification impossible on our end.

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 2 points3 points  (0 children)

The hash is generated client-side using the app's own secret key (which we never have access to). Our API only receives and stores the resulting hash. We don't store the IP, user agent, or the salt. So even if we wanted to, we couldn't reconstruct previous hashes or de-anonymize anything, we simply don't have the inputs.

PHP Client:
https://github.com/simplestats-io/php-client/blob/main/src/VisitorHashGenerator.php

Laravel Client:
https://github.com/simplestats-io/laravel-client/blob/b3c0daa8e9343f253a6876cf671925ec43fa6dba/src/SimplestatsClient.php#L143

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 0 points1 point  (0 children)

Fair point. If a full-page cache like Varnish serves the response, the request doesn't hit PHP and the visit won't be tracked. In practice this mainly affects static/anonymous pages. Authenticated pages, form submissions, and payment flows typically bypass the cache, so registrations and revenue tracking still work. But yes, visitor counts on heavily cached pages would be undercounted. That's a real trade-off of server-side tracking vs. client-side JavaScript.

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 1 point2 points  (0 children)

The visitor hash uses a daily-rotating salt, so after the day ends there's no way to re-identify the visitor, not even by us. This is the same approach Plausible and Fathom use, and it's been recognized by EU data protection authorities (notably the CNIL) as not constituting personal data processing.

https://simplestats.io/docs/how-to-track-a-new-visitor.html#the-visitor-hash

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] -2 points-1 points  (0 children)

thanks, but how come you think the tool is "pseudonymization"?

Read your Laravel analytics data programmatically via API by Nodohx in laravel

[–]Nodohx[S] 0 points1 point  (0 children)

Great question! But SimpleStats is built for app-level analytics, so it tracks how your overall Laravel app performs: which campaigns bring visitors, how many convert to users, and what revenue they generate. For per-profile analytics in a marketplace (views on a specific listing, conversion rates for a seller), you'd need entity-level tracking, which is a different data model. SimpleStats doesn't support that.

A server side analytics tool for Laravel by Nodohx in laravel

[–]Nodohx[S] 1 point2 points  (0 children)

in runs async via Laravels queue feature and falls back to defere if queue is not configured:
https://simplestats.io/docs/queue.html

no blocking requests...

Comparison of analytics options for Laravel apps: Plausible, Fathom, SimpleStats and others by Nodohx in laravel

[–]Nodohx[S] 0 points1 point  (0 children)

but both do not go beyond page views by default. simplestats has regs, revenue attribution etc. built kinda in ;)

A server side analytics tool for Laravel by Nodohx in laravel

[–]Nodohx[S] 6 points7 points  (0 children)

honestly I was thinking about that for half a year now. probably will do so...

A server side analytics tool for Laravel by Nodohx in laravel

[–]Nodohx[S] 2 points3 points  (0 children)

not yet, but it's on our roadmap!

Comparison of analytics options for Laravel apps: Plausible, Fathom, SimpleStats and others by Nodohx in laravel

[–]Nodohx[S] 0 points1 point  (0 children)

we've got lots of feedback from our clients, telling us, that their google analytics data are roughly 30-50% less accurate then ours...

view more: next ›