Entry pages show only root "/"

[woile]

Hello people, thanks a lot for the app. I was wondering if you could help me here, I have a static website and I've added the tracking code, the thing is the "Entry pages" section is always showing the /. Any idea what might be the issue? Here's the dashboard: https://counter.dev/dashboard.html?user=Woile&token=uDRZvvv2oM7q8Rga

And here's my blog: https://github.com/Woile/woile.github.io/blob/cc3787c410415c0f728daba0d90f4dc9a546585b/conf.py#L1239-L1243

I've checked the network tab and there's a call being made from the blog posts, like this: https://woile.dev/posts/helm-3-crafting-a-chart/

Thanks!

[ihucos]

Hello,

entry pages as the names suggests really only gives information about the first page you visit. I visited your site going to https://woile.dev/archive.html and now /archive.html is in the entry pages - so it seems to work as intended. There are occasional questions about this so this is probably not clear enough in the user interface

Cheers

[woile]

Thanks for the explanation, indeed some extra information would be helpful.

[woile]

Hello @ihucos again, sorry to bother, but I'm trying to reproduce and I still cannot see other website. I shared a link to a post, and I only see the / going up.

I tried to reproduce your suggestion of archive.html.

These are my steps:

1. Open incognito browser
2. Go to link directly
3. Observe network tab

The request to counter is done, but it's not reflected in counter.dev

Is there something I'm missing? Regards!

[wouterj]

Hi @ihucos. I'm trying out counter on my GitHub Pages hosted website and I can confirm this issue. Looking at my network tab, I can see the Referer header of the request to /track is always my domain (instead of the actual page I visit).

Wouldn't it be better to pass window.location.href to counter.dev/track as a query parameter as well?

[Tezar]

The cause is that most of the modern browsers adheres to the new referer policy, which is strict-origin-when-cross-origin (i.e. pass ONLY domain part in referer when making outgoing requests).

There are more ways to change this behaviour and/or support explicit definition in tracking params. Far less intrusive option for now that just works is to change referrerPolicy of the fetch request.

Add { referrerPolicy: "no-referrer-when-downgrade"} as second param of the fetch in the tracking snippet.

e.g.

<script>if(!sessionStorage.getItem("_swa")&&document.referrer.indexOf(location.protocol+"//"+location.host)!== 0){ fetch("https://counter.dev/track?"+new URLSearchParams({ referrer:document.referrer,screen:screen.width+"x"+screen.height,user:"your_user",utcoffset:"1"}), { referrerPolicy: "no-referrer-when-downgrade"})};sessionStorage.setItem("_swa","1");</script>

[ihucos]

Thank you so much, will look into it! A lot of people complained about this.

[ihucos]

Hmm, I am running it as a test just for tracking counter.dev itself and my firefox complains with this:

Referrer Policy: Less restricted policies, including ‘no-referrer-when-downgrade’, ‘origin-when-cross-origin’ and ‘unsafe-url’, will be ignored soon for the cross-site request: https://simple-web-analytics.com/track?referrer=&screen=1920x1080&user=counter&utcoffset=1

So it might not work for a very long time

[ihucos]

I am running it as a test just for tracking counter.dev itself [...]

Test aborted

[Tezar]

https://github.com/ihucos/counter.dev/issues/37#issuecomment-1014968643 Good to know. Unfortunately I haven't been able to find any definitive timeline for the will be ignored soon. From the alternative policies none is applicable for this problem, so only pernament solution seems to be able to pass referrer in the GET params.

[wouterj]

Unfortunately, that appears to be also not that straightforward. See https://github.com/ihucos/counter.dev/pull/40#issuecomment-951045530:

One of the ideas behind counter is that the client is responsible for defining what an unique view is and basically only send an http request once. There are multiple layers or fences if you want to ensure that. At first we save something in the sessionStorage, in case that fails we rely on HTTP caching for the request to not actually arrive to the server. Now with that change we would fix the apparently unreliable Referer header but we would also have a different url for each different page being requested to the counter server in the case where localSession fails. This different URLs would "bust" trough the HTTP cache that was set up as an additional "defense line".

[ihucos]

Testing something new: https://github.com/ihucos/counter.dev/commit/01b7cced2a23df9a6f0ddd7a234ebda4f080cac8

[ihucos]

No luck with the upper mentioned commit

[ihucos]

Hmm, I don't like the options so far:

• Continue with a broken feature (I get regular emails)
• Remove the feature
• Use custom headers by supporting prefligh request (OPTIONS) - affects scalability - don't know how much
• Pass in the entry page parameter as GET request - affects quality of service - don't know how much

[ihucos]

I have a plan:

• Continue keeping the head in the sand about this issue
• First implement another issue https://github.com/ihucos/counter.dev/issues/76
• Then actually have a separate HTTP request to counter.dev to pass in the page visited. This request will not only be issued when the page is visited first but on every pageview. So we could also have a "pageviews" metric apart from the "visits". And actually track some more stuff. But I'll have to be considerate to remain in the "sustainable" side of things as this service is offered for free of charge. Soo possibly move to something fasthttp based to save some CPU on the HTTP handling. With that approach we could also measure other things like: https://github.com/ihucos/counter.dev/issues/51

[ihucos]

I made some tests and have code to make it generally working:

What I haven't really figured out and would actually like some input is how to roll out the feature. It can now track pageviews. But we don't have that data for historic views (e.G. "This year" or "All"). Should the old widget with the bogus entry pages be shown in cases where the pageviews are not being tracked from the beginning? I'd prefer to just fully replace the entry pages widgets with the new pageviews widget. But then if you for example start tracking that today the historic for - e.G. "all" - will also only show entries for today. Which can seem a little odd - but that improves over time.

[ihucos]

Finally 🎉

We have pageviews now - instead of entry pages.