Skip to content
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

GA4/GTM scroll/search issues #11618

Open
davidpmccormick opened this issue Feb 13, 2025 · 0 comments
Open

GA4/GTM scroll/search issues #11618

davidpmccormick opened this issue Feb 13, 2025 · 0 comments

Comments

@davidpmccormick
Copy link
Contributor

davidpmccormick commented Feb 13, 2025

Scroll

We have set up custom triggers and tags to detect when scroll depth hits 10%, 25%, 50%, 75%, and 90% and we currently only fire these deliberately on any pages at a URL that contains ‘stories’.

The triggers fire (without having an associated tag) on the non-catalogue pages, and on the first visit to a catalogue page, but they don’t for subsequent catalogue (i.e. ‘search’) pages. If we want information about scroll depth on search, we’ll need to fix this. I’ve found other people suffering with the problem. Simo Ahava mentions 'one thing that is questionable is how well this jives with a single-page app'

One possible off-the-happy-path solution

Another (maybe simpler?) solution – I couldn’t make this work, then tried a variation whereby a history change trigger would fire a reset_scroll_depth tag which served to wipe out the gtm.scrollDepth events in the dataLayer. But that didn’t work either. First off, the history change trigger only fired once, and while it did remove the gtm.scrllDepth events, this wasn’t enough for them to be picked up on subsequent scrolls.

I also tried implementing a tag that implemented its own history change (popstate) listener (e.g. window.addEventListener(‘popstate’, () => /* reset scroll somehow */ )); but I couldn’t get that to fire at all (I have no idea why).

Search

We have set up custom triggers and tags to handle when someone has searched for something. The implementation checks for when there has been a click on the word ‘search’, rather than anything to do with the url and query string (or form input changes). As such, it doesn’t detect something as a search when e.g. you have already searched for a term in the ‘All’ tab, then click the ‘Catalogue’ tab to get those specific results (since you didn’t click ‘search’). One possible solution in this Stack Overflow post.

GA4 'enhanced measurements' have built in search support, but (for most likley for the same client-side routing reasons outlined above) it doesn't work for second and subsequent searches.

@davidpmccormick davidpmccormick converted this from a draft issue Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

1 participant