Is there a way in Adobe Analytics to prove that a user scrolled down to a certain point on a page and saw a piece of content? Thinking something along the lines of scroll depth like there is in Google Analytics. Is that available in Adobe Analytics?
Solved! Go to Solution.
Views
Replies
Total Likes
Adobe does have a plugin called getPercentPageViewed
Similar to other implementations, this plugin sends tracking as part of Page Views (but for the previous page viewed). Essentially sending the "max percent of the previous page" seen. This keeps server calls (and costs) down, but it generally means that you won't get the % viewed on the last page of a visit (which by extension means that single page visits won't have any data).
The other thing to consider is with responsive web pages, and so may different screen sizes (from very large with high resolution) to smaller handheld devices with limited screen real-estate; the concept of % is quite flexible....
Now, I know this would inflate server calls, so don't run out an do this without investigation into potential costs, but in theory, you could create a custom action to fire when the user scrolls down and sees a specific element on the screen....
To check if an element is in the viewport:
https://www.30secondsofcode.org/js/s/element-is-visible-in-viewport/
To detect "Scroll Event" which you can use to then check when the user scrolls if the element is visible:
https://developer.mozilla.org/en-US/docs/Web/API/Document/scroll_event
Then if you build this into a Rule, you would likely want to apply a Max Frequency condition, to only fire once per page view (so that once the element has been "seen", you don't keep triggering tracking if the user is scrolling up and down the page multiple times.
But again, this is only if you have enough server calls on your contract to support this (and IF this will be applied to all pages, or just very specific cases).
Adobe does have a plugin called getPercentPageViewed
Similar to other implementations, this plugin sends tracking as part of Page Views (but for the previous page viewed). Essentially sending the "max percent of the previous page" seen. This keeps server calls (and costs) down, but it generally means that you won't get the % viewed on the last page of a visit (which by extension means that single page visits won't have any data).
The other thing to consider is with responsive web pages, and so may different screen sizes (from very large with high resolution) to smaller handheld devices with limited screen real-estate; the concept of % is quite flexible....
Now, I know this would inflate server calls, so don't run out an do this without investigation into potential costs, but in theory, you could create a custom action to fire when the user scrolls down and sees a specific element on the screen....
To check if an element is in the viewport:
https://www.30secondsofcode.org/js/s/element-is-visible-in-viewport/
To detect "Scroll Event" which you can use to then check when the user scrolls if the element is visible:
https://developer.mozilla.org/en-US/docs/Web/API/Document/scroll_event
Then if you build this into a Rule, you would likely want to apply a Max Frequency condition, to only fire once per page view (so that once the element has been "seen", you don't keep triggering tracking if the user is scrolling up and down the page multiple times.
But again, this is only if you have enough server calls on your contract to support this (and IF this will be applied to all pages, or just very specific cases).
Terrific.
Thank you, Jennifer, for your quick and informative reply.
You're very welcome
Views
Replies
Total Likes
Similar to what @Jennifer_Dungan mentioned, some of our clients fire a impression event to track when certain modules have been loaded into view. It does increase the server calls so we only use it for limited cases but it helps you to give you a valid number of impressions for a CTR rate.
There is also an "Enter Viewport" from the Core extension you can use where you provide the CSS selector of the specific piece of content and the rule should be triggered when the first time the element entered viewport and seen.
I would test that to be sure that actually works... Adobe's "Custom Event" triggers have never worked for me, and I've helped other people on this forum that had issues with it....
I've also not had much luck with Data Element Change and Element Exists.... all those rules in the same block of triggers (so I am leary of it they work as expected
If it works, and works consistently, great!
Views
Replies
Total Likes
The "Custom Event" trigger involves quite a log of coding which I only tested but don't bother to find any actual use of it, just because of tracking.
However, the Data Element Change, Element Exists, and Enter Viewport triggers are good and reliable. I had been using quite a lot of data element change rules in the past and they worked as expected until developers updated CSS and broke the rule. That's why EDDL
Views
Replies
Total Likes
We Adobe's "Custom Event" trigger should avoid all that code, we use custom triggers but I have to use "Custom Code" events and write the event listeners myself for it to properly work....
I know I've tried "Data Element Change" and it didn't work either... but that was years ago... they may have fixed it...
But "Custom Event" given I helped someone a few months ago who was having issues, told them how to use Custom Code and got them sorted out within a few hours, I'm still distrustful of some of those triggers...
I'm glad they are working for you @leocwlau
Views
Likes
Replies
Views
Likes
Replies