The inimitable Simo Ahava recently posted an article named Fire GTM Tag Upon Scroll Depth And Time Spent, in which he explains both why and how to fire tracking after visitors have either lingered on or scrolled to a certain depth on pages.
With his permission, I’ll show you how to do the same with Launch, by Adobe.
Why?
The idea is to measure how the content on your web site is being consumed, read. A lot of people use metrics like “Time on Site” or “Time on Page” or “Time Spent” or whatever your Solutions calls it to figure this out, or rather to approximate it.
The huge problem with that is that you can’t actually measure whether a visitor is really looking at the page while it is open. For all we know, they could have left the room!
If you’re a media site, or if your site has content that is considered important (banks have a lot of that), then you need to know whether your content people write the right stuff.
And while the approximation helps, there are better ways, some of which both Simo and I have written about.
This time, Simo suggests combining time and scrolling.
If a visitor scrolls a certain way, and if they linger for more than a certain time, do something.
The novelty is to combine those two conditions in a single Rule, to use two different parameters and trigger one action.
You might remember that I did something similar with DTM some time ago (see Delayed Page Load Tracking with DTM), but now we have Launch. And it’s easy-peasy with Launch.
How?
Just like GTM, Launch treats multiple Events in a Rule as “OR”, meaning any of the two Events would trigger the Rule.
Simo gets around that by making sure the triggers each take into account whether the other has already fired or not. We can do the same thing in a bunch of different ways in Launch.
One way would be to do it like in the “delayed page load tracking” article mentioned above, using a “Custom Event” Event and a single Rule. A variation of that could be to use a “Custom Code” Event.
Another way would use three Rules. The first would trigger on time, the second on scroll depth, and both would call the third, actual, Rule, which would have a condition “both have fired”, so to speak.
I don’t particularly like any of those approaches. There would be a lot of Javascript code, hidden away, yes, but it wouldn’t be clear to a casual observer what the Rule/Rules was/were doing.
The proper way of doing this in Launch, you ask?
Well, obviously, we build an Extension!
The Extension will provide a single Event Type, which encapsulates the whole thing, and which has four configurable settings:
- Threshold of time spent on page,
- threshold for scroll depth in %,
- a toggle which can be set to “fire just once per page” or “fire every time this happens”, and
- a delay time for attaching the scroll listener, in case the page builds dynamically.
In order to complete the Make an Extension mini series, I’ll write about how to test an Extension in the sandbox (there have been changes), how to test it on the integration environment, and how to publish it, when it is done. done
For now, all you need to do is find my Extension in the Catalogue, add it to your Property, then use it in your Rule.
Ah, so simple!
If you want, you can see the sources on github, of course.
Notes
It was great fun writing this little Extension!
The process has changed since I wrote about making an Extension, which means I got to write about the changes. I was also able to write the final article, about publishing your Extensions.
So thank you, Simo, for pushing me to dig deeper into this topic!
The whole thing is possible with DTM, too, but given that we now have an official end of life announcement, I shall ignore DTM completely from now on.
One flaw in my Extension is that it is imho overly specific. I may or may not work on an alternative Extension that provides all sorts of “engagement”-related Events…
Web Analytics for Developers 
Is there a support email for this extension?
LikeLike
Hi Mark,
I’m your support, or check out the github, all the code is there.
What is the issue you’re seeing?
Cheers,
Jan
LikeLike
Hiya Jan,
Apologies…these might be stupid questions. I was working with the extension (which is super useful btw!) and just had a few things I needed clarifying…although suspect it’s the way I’m trying to do it.
So I’m firing an event through Launch and then writing to the console when it fires (as I wanted to check what was coming through). And into the console I’m writing the % of the page viewed based on the following bit of javascript:
Math.round((window.pageYOffset / document.body.offsetHeight)*100) + “%”
Basically getting the point at which the rule was triggered and dividing by the length of the page (and converting to %).
But I’m getting different % numbers to the % I’m setting the rule at. Is it just the way that I’ve calculated it is different?
The other thing I wanted to clarify was the combination of the two elements (time spent AND scroll depth). If I set both to 5 does that mean this will be triggered if a user spends longer than 5secs at any point greater than 5% down the page? Or just that they’ve been on the page for longer than 5secs and have exceeded 5% at some point?
Am I right in thinking that to use this with Adobe Analytics the best way is to set up multiple rules which fire at differing intervals (e.g. 20%/40% etc…)???
Apologies if these are noddy questions…I’m dabbling with scroll depth tracking for the first time.
Mark
LikeLike
Hi Mark,
So for the first question: I use a slightly more complex logic, see https://github.com/janexner/launch-extension-time-spent-and-scroll-depth-event/blob/master/src/lib/events/combinedTimeSpentAndScrollDepth.js
It’s also possible that the Rule doesn’t fire _exactly_ when you pass, say, 25%, but a little further down. Browsers do funny things with UI events.
In terms of combination, your second part is correct: set both to 5, and the Event will trigger as soon as 5 seconds on page have passed and scroll is 5% down or more. The wait time is for the page, not the offset.
You are absolutely right on the third part: multiple Rules with different intervals.
Cheers,
Jan
LikeLike
Hi Jan,
I am using above extentions to fire event on scroll(25,50,75,100). but having issues with delay as contents are dynamiclly coming to page. i have added a delay of 25 sec(so that launch is able to get the page height). Sometimes the page loads faster and i have to wait for the event to fire on scroll.
Is there any way i can handle this?
LikeLike
Hi Abhijit,
With the Extension as it is, you can’t, no.
I have been asked to write a new version that allows people to manually deploy the listeners, and it could be built so the deployment of listeners can be done whenever you want. With such a new version, your use case would be easy to do.
Only issue: I have to find time to build that.
Or you could do it 😉
HTH,
Jan
LikeLike
Hi Jan,
I’ve tried using this extension recently and can’t get my library to build when using this rule. As soon as I remove the rule my library publishes fine. Do you know of anyone else who’s had this problem?
Thanks,
John
LikeLike
Hi John,
No, I don’t think anyone has ever had that.
Can you try deleting the Library and creating a new one?
LikeLike
Did that help at all, John?
LikeLike
Hey Jan!
Have you seen any issues with eVar persistence on these events? I’ve been using this extension and coming across some persistence issues with eVars that are set on events that load BEFORE the Time and Scroll Depth events load …. any insight is appreciated!
LikeLike
Hi Paulina! I know you have also asked on slack. Is the question still open? Have you tried using the Clear Vars Action Type? Could you be specific about your goal?
LikeLike
Hi Jan!
Yea, this is still active 😦
I have added the Clear Vars Action Type. too.
To be clear on the goal:
1. Resolve persistence issue on Scroll Depth event reporting in AA Workspaces (current state: high number of ‘unspecified’ values for certain variables are being recorded)
We have set up:
Data layer that includes page level variables
Including Time and Scroll extension
Launch:
Rule 1: All pages “Page View” event. Event configured to pageView push event, configured with page load variables
Rule 2: Scroll Depth 25% event. Event set up only with event#. No page load variables configured in event.
– Omnibug, network calls, etc: display Rule 1 fire 1st, Rule 2 fire 2nd.
– Adobe Workspaces: reporting unspecified values for page load variables when report includes (for example)
Dimension: Page Name
Metrics: Page View (event#), Scroll Depth 255 (event#)
According to my understanding, if our variables are configured to expire on visit, data layer triggers pageView push event with page load variables…..shouldn’t these values persist?
What we have done right now is explicitly added the page load variables to the Rule 2
Thank you Jan for any insight here 🙂
LikeLike
Hi Paulina,
Your understanding is correct. The eVars, once set in call #1, should persist, and the Scroll Depth 25% event should apply to them. You should not have to add those variables to Rule 2 (not that it is bad to add them, but it would be simpler not to, and it should work without).
The one thing I can think of is timing. Maybe the second call is really fast after the first one. I seem to remember that if the delay between the two is really short, the system may mix them up.
Can you reproduce on a dev or staging site? If so, could you pull a Data Feed from that dev Report Suite? That would show you whether in the raw data, the two hits might be the wrong way round, or if they’re the right way, whether the post_eVarXX columns for your page load eVars do actually hold the persisted value…
LikeLike