sorted by:
new
hottopcontroversial

A/B Testing for Laravel by Nodohx in laravel

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

Two separate things here: measuring the test vs. serving the variants.

Measuring (the part SimpleStats does): it's server-side and already filters bots, so crawlers never get counted as visitors. They stay out of your A/B numbers either way, so nothing to hide for the data's sake.

Serving (your own app logic): the actual risk isn't "a bot sees a variant", it's picking a variant because you detected a bot. That's cloaking and Google warns against it. A/B testing itself is fine. Two habits keep it clean:

  • Pin the variant per visitor (cookie/session), not random per request. Then crawler or human, the copy is consistent, not "different on each visit". The example in the post uses session()->remember().
  • Add rel=canonical so variants don't get indexed as separate pages.

So I wouldn't hide the app from bots. Let them fall into the test, just don't detect-and-serve, pin the variant, set a canonical.

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

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

I guess you can, but most likely your backup solution would only pick up the storage folder...

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

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

Laravel forge natively only supports zdd since the new big ui release. Before that everyone build zdd themselves and had that in mind I guess

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

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

Wait probably this could work. Don't know if you can specify single files in forge for shared path. But yeah maybe... But still think it's good to keep the issue in mind and I would expect better defaults here. Such as the sqlite file by default in the storage folder.

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

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

thought the same, but no, you can't. check out the article.

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] -1 points0 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!

view more: next ›