search

ihucos / counter.dev

Web Analytics made simple
https://counter.dev
GNU Affero General Public License v3.0
902 stars 39 forks source link

Aliasing own domain to point to counter.dev #49

Open Tezar opened 2 years ago

Tezar commented 2 years ago

Would it be possible to support aliasing under own domain, so one can fetch tracking script from analytics.owndomain.com which would be CNAMEd to counter.dev?

Would help against adblockers.

ihucos commented 2 years ago

Hello Tezar,

interesting, yes, that might be possible. So I understand you add dns entries to your own domain to point to counter.dev. Feel free to do it and I see to fix any issues that come along the way. I don't imagine this is sustainable though since I believe in the adblocker cat and mouse game the clients side has the upper hand? So it's a game I rather don't play. What I mean is that I imagine they can block list the call by other properties and don't necessary need to be dependent on the host.

hello-smile6 commented 2 years ago

Why not use cdnjs or include the script inline?

Tezar commented 2 years ago

@hello-smile6 ad-blockers/privacy extensions usually whitelists requests to same (sub)domains. Aliasing counter.dev behind your domain can help in that.

hello-smile6 commented 2 years ago

Oh. Why don't people just use server-side analytics and avoid an additional request?

Tezar commented 2 years ago

For server-side analytics you need to have access to access.log or equivalent. That is usually not the case for most webhosting providers. Sure, you can set it up if you have setup your own VPS, but imho while it's not unusual it's far from common. You also get granularity per IP address and you lose some useful info, such as resolution. Managing multiple analytics across more than one domain can become tedius. With counter.dev you just include script and it's on your dashboard.

So yeah, there are some useful tools for doing serverside, and it seems to me that there will be/already is renaissance among them with UX that doesn't look like from the 90's. But still, one superficial request is quite small price for the advantages one can use. But as always, your mileage may vary :)

ModischFabrications commented 2 years ago

@Tezar did you manage to alias it? I have the same problem, it would be nice to have a proven example before experimenting with DNS settings.

ihucos commented 2 years ago

[lunch-break-from-paying-job] Let me know if there is anything needed on the server side for this. [/lunch-break-from-paying-job]

andersme commented 2 years ago

I have tried this, however I received an error message saying you can't point a Cloudflare CNAME record to that of another customer. I think something has to be done on counter.dev's Cloudflare setup to enable this. I'm not sure though.

ihucos commented 2 years ago

Hmm, yes, that cloudflare disallows this would make sense. You might want to try to point it directly to the servers IP without cloudflare in the middle: 172.104.148.60

Usually this IP would be hidden to avoid direct DDOS attacks, but no need to anticipate that yet as adapting to it would be easy. One thing though is that with this the IP to country resolution might not work, which may affect the analytics dashboard.

ihucos commented 1 year ago

Has anyone had any luck with that. I'd actually like to measure somewhere how many visits do not get trough due to adblockers in order to more appropriately prfioritize this issue. But no idea really. Oh well, oh well.

ElastiCourse commented 5 months ago

Has anyone had any luck with that. I'd actually like to measure somewhere how many visits do not get trough due to adblockers in order to more appropriately prfioritize this issue. But no idea really. Oh well, oh well.

I just came across this issue. I have tried multiple methods to avoid Adblockers with not luck:

  1. CNAME pointing to https://cdn.counter.dev/script.js -> ERR invalid
  2. A record pointing to 172.104.148.60 -> Connection Refused (Has IP changed since last year?)

To my understanding. Counter.dev doesn't violate GDPR in anyway. It's sad to see it blocked in the same bucket as Google Analytics and AWS tracking.

Tezar commented 5 months ago

ad 1. CNAME is on domain level, i.e. you cant specify URL path, original idea was to point CNAME counter.yourdomain.com -> cdn.counter.dev and then request JS src like counter.yourdomain.com/script.js ad 2. IP is still up but ends up with "Bad host" for me

Problem with CNAME approach is that you end up on the cloudfare edge and it wil try to route your request correctly based on your Host header. But nothing is configured for the counter.yourdomain.com, so dead end.

With IP based it's kinda similar. You reach correct server, but it too looks up the hostname to serve correct files. No hostname mapped => blocked.

One solution would for be for @ihucos to setup origin server with wildcard servername rule, if webserver supports it. You would lose CND benefits but gain almost zero config setup, just add cname and you are done.

Second solution would be to setup reverse proxy (which can be quite straightforward with nginx) or some local script that would forward request from your setup. That way everything would be server<>server and from clients POV nothing goes outside your domains. Caveat is lost client IP address, but not sure if it is used or not (maybe for country location?). In that case some GET parameter would be needed to pass it though.