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

Component - Scroll #22

Open
davisbradleyj opened this issue Sep 1, 2023 · 13 comments
Open

Component - Scroll #22

davisbradleyj opened this issue Sep 1, 2023 · 13 comments

Comments

@davisbradleyj
Copy link
Contributor

This event should fire on the webpage on all pages and in the scroll box for requests. This event should be dispatched in milestone increments i.e 25%, 50%, 75%, and 100%

Scroll.md

@mgarzonjnj
Copy link
Collaborator

mgarzonjnj commented Sep 7, 2023

@mandyjohnston03 @davisbradleyj this is ready for your review in Pre-Dev environment.

Providing a quick description on how the team got this working:

_My Case indexes 10 and Search Results 20. Everytime you scroll/stop scrolling, Scroll event will fire.

When you first load My Requests page, you see 10 results. Event will consider 10 = 100%. However if scroll to the 10th item, another 10 cases will appear and another Scroll event will fire with 20 = 100%.

Scroll Type will include page and tab information. "Page: Tab"_

I will also provide login in details of a user who has more than 10 cases so you can test this easier.

[email protected]
Salesforce_2020!

FYI - @ACasallaJnJ

@davisbradleyj
Copy link
Contributor Author

While I can confirm that we are seeing the Scroll event fire on the "My Requests" page, there is some unexpected behaviour with it refiring after reaching the end of the page and scrolling back up.

The expectation is the scroll event ceases to capture data after reaching 100%, but I am seeing the following:

Image

Image

@davisbradleyj
Copy link
Contributor Author

@mgarzonjnj

Using that test login, I am met with the following security check:

Image

@mgarzonjnj
Copy link
Collaborator

mgarzonjnj commented Sep 15, 2023 via email

@mandyjohnston03
Copy link
Collaborator

@mgarzonjnj
Hi Maria!
A few notes on this:

  1. When I log in when the login provided above, I'm not seeing the scroll events in the dataLayer. However, Brad is able to see them using his personal login. My personal login is erroring, so I'm not able to test there.

  2. To Brad's point above, we only want the scroll events to fire on the way down. From the data perspective, we want to be able to tell how far down the user has to scroll to find a result that fits their need. For that reason - including data from scrolls back up will not tell us that story.

  3. The scroll milestones values need to be consistent. In the initial talk about this, we talked about firing at every 5 results. So, if the user scrolls to view 5 results, the scroll_milestone should be 25%, 10 results = 50%, 15 results = 75%, 20 results = 100%. That will give us a more clear picture of the user experience.

@mgarzonjnj
Copy link
Collaborator

No description provided.

@mandyjohnston03
Copy link
Collaborator

@mgarzonjnj @nkuma173 When I scroll the search results using my laptop mouse, I don't see any dataLayer pushes - this screenshot is on the 8th article

Image

@nkuma173
Copy link
Collaborator

nkuma173 commented Oct 3, 2023 via email

@mandyjohnston03
Copy link
Collaborator

Hi team -
@mgarzonjnj @nkuma173 After testing again several times, there are no scroll events being pushed into the dataLayer IF scrolling by dragging the mouse on a laptop.

With a separate mouse, we were able to see the scroll events. We are now not seeing it fire on the way up. However, we're still seeing it fire on random intervals.

Image

@mgarzonjnj
Copy link
Collaborator

mgarzonjnj commented Oct 6, 2023 via email

@davisbradleyj
Copy link
Contributor Author

Hi @mgarzonjnj

I do not believe an additional call is going to be possible. As it stands we have no time available left for this engagement, outside of the GA4 training that was requested for the week of October 23-27 (I believe you had asked specifically for October 26th).

We can be available in the following time blocks that week:

Tuesday, October 24:

  • 10:00 to 11:00 am ET
  • 11:00 am to 12:00 pm ET

Wednesday, October 25:

  • 12:30 to 1:30 pm ET

Thursday, October 26:

  • 11:00 am to 12:00 pm ET
  • 1:00 to 2:00 pm ET

I will follow up via email with these times as well, but please let us know which time block would work best for your team.

@mgarzonjnj
Copy link
Collaborator

@mandyjohnston03

The scroll events are sent once the user stops scrolling. If user begins to scroll down and stops at the 7th result, the scroll event will capture a percentage calculated using the number of pixels which show how far the user has scrolled down from the top.

Formula being used for background: Math.round((Number(div.scrollTop) + Number(div.offsetHeight))*multiplier/Number(div.scrollHeight))

If I am understanding what you're saying, what you were expecting is only 4 scroll events ever. If 20 results are 100$, if the user scrolls down to result #5, only then would the event send a 25%. If they scroll to result #7, no event would be sent. If they scroll to result 13, the 50% event would be sent.

Am I understanding this correctly?

@mandyjohnston03
Copy link
Collaborator

@mgarzonjnj An event would fire for each milestone passed so, if someone scrolls to result #7, the 25% event would send (when the 5th result was passed), but not the 50% since they didn't get to the 10th result. So if someone scrolls to 20 results, all 4 scroll events would send.

I'm not sure exactly which questions you want to answer with this. In my mind, it would be primarily trying to identify which search terms people have to scroll down a significant amount to try to find a search result. This should also be answered with the select search result event, in combination with the slot and total result parameters). What question are you hoping to answer by the component scroll on the My Requests page?

With that in mind, if you feel that it would be more valuable to fire an event with a result count vs. a percentage every time it passes 5 results (that I mentioned a couple weeks ago), that direction works as well. The key is that the milestones are consistent. This may be easier to accomplish on the developer end.

cc @davisbradleyj

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants