Rename tracker to "reporter" (or similar)
I borrowed this terminology from Fathom (tracker.js is a fork of that project's script), but I don't think it's good name:
- "tracker" sounds anti-privacy
- The script doesn't actually track you – I deleted all the cookie-related code from the script
I think reporter.js would be more accurate.
If we did this, we should continue publishing tracker.js for backwards compatibility (e.g. users could upgrade to the latest version of Counterscale and not need to update their script references).
Reporter.js sounds too generic. counter.js based on project name sounds nice, but might be limited in scope.
Yeah counter.js is a good idea. Fits the name, could even work as a branding element (e.g. people see counter.js in the network tab, more obvious what it is).
Re: limited in scope – that's also fair. But I don't think the name has to limit what it does. For example, there could be a future where it collects basic latency/web vitals, and yeah that's not "counting" but IMO it's still fair game.
Will sit on this for a bit.
Yeah
counter.jsis a good idea. Fits the name, could even work as a branding element (e.g. people seecounter.jsin the network tab, more obvious what it is).
I agree. I also thought about count.js, insights.js, metrics.js cs.js (CounterScale) etc. But keeping a part of the brand name like counter.js seems better.
I would also vote for counter.js
In umami, you have an env var which define the name of the script. Also it's a good practice to have the deployment in your subdomain like stats.example.com
what about the name stats.js?
I've thought about this for a bit and I think choosing a different static name is the kind of thing that we could bike shed into oblivion. Instead, I'd propose the solution @bgervan highlighted where the name of the script can be configured via a Cloudflare secret/env variable, similarly to how auth is enabled currently. This would allow backwards compat (default would remain tracker.js), but users can set a different name to use for the script during install with the CLI.
Curious what others think about this approach
Sounds very reasonable to me