Aliasing own domain to point to counter.dev

[Tezar]

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]

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]

Why not use cdnjs or include the script inline?

[Tezar]

@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]

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

[Tezar]

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]

@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]

[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]

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]

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]

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.

[Tezar]

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.