New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Analytics treats in-page anchor jumps as pageviews #51
Comments
Hey @Justineo :) We consider adding a way to disable automatic page view collection (and triggering them manually). <Analytics beforeSend={function (event) {
if(event.url.includes("#")) return
return event;
}} /> Something like that would work, but sadly there is no way to find out if it was a crosspage navigation or same page hash navigation. |
I think this workaround won't work as the page view event does not expose enough information. The page view from We need both the URL before navigation and after it to see if history change is caused by in-page anchors but in current implementation we only got analytics/packages/web/src/types.ts Lines 1 to 4 in 73e33e7
|
Hello, I'm following up on the status of this issue. Has there been any progress? |
@Justineo |
I think this is a common use case and shouldn’t require such workaround. Technically we can rewrite any client side logic but I think it should be handled by the analytics SDK itself. |
We just rolled out a new version that now doesn't track same-page hash navigations anymore! Thanks 🙏 |
There seems to be a potential bug in
/_vercel/analytics/script.js
:It is comparing
pathname
with the target URL apart from thesearch
part. But for target URLs like/foo#bar
it will be count as a new page view. And I'm also aware that if we strip hashes as well this may break the use case for those SPAs with hash router. So I think we should expose an option to let users to configure their routing behavior.The text was updated successfully, but these errors were encountered: