feat:Time Spent on Page #341

ps863 · 2023-01-12T12:14:53Z

Currently, AWS CloudWatch RUM does not record the time spent on a certain page. This change records the time spent on a page as part of the parentTimeSpentOnPage field in the page view event details. This field records the time spent on the parent page to the page view event it is recorded in.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

adebayor123 · 2023-01-12T20:37:29Z

src/sessions/PageManager.ts

@@ -165,6 +167,7 @@ export class PageManager {
            pageId,
            parentPageId: currentPage.pageId,
            interaction: currentPage.interaction + 1,
+            parentTimeSpentOnPage: timeSpentOnParentPage,


suggestion: parentTimeSpentOnPage -> timeSpentOnParentPage

adebayor123 · 2023-01-12T20:37:32Z

src/sessions/PageManager.ts

@@ -8,6 +8,7 @@ export type Page = {
    pageId: string;
    interaction: number;
    parentPageId?: string;
+    parentTimeSpentOnPage?: number;


suggestion: parentTimeSpentOnPage -> timeSpentOnParentPage

agree. Added to the revision

adebayor123 · 2023-01-12T20:43:11Z

thought: Since we cannot retrieve the last page's duration and we decided to not create a new form of page view, what about sending a page view event with pageId: EndVisit or something similar to indicate that this was the last page to visit? I believe we have beacon to send events in the case of browser closing (feel free to correct me if I'm wrong), and if we can detect a user closing the browser/page and utilize the beacon, we would capture the last page's duration.

ps863 · 2023-01-13T21:05:58Z

thought: Since we cannot retrieve the last page's duration and we decided to not create a new form of page view, what about sending a page view event with pageId: EndVisit or something similar to indicate that this was the last page to visit? I believe we have beacon to send events in the case of browser closing (feel free to correct me if I'm wrong), and if we can detect a user closing the browser/page and utilize the beacon, we would capture the last page's duration.

Had thought about this. From what I know, I see three main issues with this approach:

In order to send this last page view event on user closing browser, we would need to listen for the beforeunload or unload event. Listening for both events is known to be unreliable (not supported by certain browsers) and can cause performance issues.
Following (1), since the existing page view event is recorded on route change and unload event is fired whenever user navigates away from a page, we would not be able to distinguish and would end up duplicating page view events recorded (as a unload event occurs with every navigation between pages and so does a route change).
We could have transition to capturing page view event exclusively when the page is navigated away from/closed by relying on the unload event, but this requires sendBeacon to work reliably. (refer to (3) on why it does not)
To flush the event cache reliably on the user closing the page, we need to use sendBeacon. However, as noted here, we noticed ad blockers were preventing sendBeacon from functioning correctly. Therefore, users have an option to configure web client to send events using fetch or sendBeacon (both approaches have their downsides).
If fetch is used, a situation can arise wherein the page has not fully unloaded before the fetch is completed and events are dispatched to the dataplane. As such any page view event that relies on listening for page unload may not get dispatched.

adebayor123 · 2023-01-18T19:12:23Z

question: How do we handle the case where the session is picked up from the cookie? For example, if user left the browser at page B, the web client may hold the "page.start" value in the cache, and when you move to subsequent pages, it may return an incorrect timeSpendOnParentPage information. If page.start is not stored in the cookie, what if the page manager's page.start is undefined? How do we handle this case?

qhanam · 2023-01-24T16:57:40Z

src/sessions/PageManager.ts

@@ -136,6 +137,7 @@ export class PageManager {

    private createNextPage(currentPage: Page, pageId: string) {
        let startTime = Date.now();
+        const timeOnParentPage = startTime - currentPage.start;


suggestion: timeOnParentPage is more concise. Use timeOnParentPage in the event schema instead of timeSpentOnParentPage.

updated in revision and schemas

qhanam · 2023-01-24T17:28:01Z

src/sessions/PageManager.ts

@@ -165,6 +167,7 @@ export class PageManager {
            pageId,
            parentPageId: currentPage.pageId,
            interaction: currentPage.interaction + 1,
+            timeSpentOnParentPage: timeOnParentPage,


question: What happens when the page is resumed?

We may want to change the behavior so that page view events are not recorded for resumed pages. RUM users have been confused by seeing users navigate from "PageA" to "PageA" in user journeys.

Handled this case in revision. Page view events are no longer recorded for resumed pages if page ID is same. Start time from the Session cookie is used to compute the time on page if resumed page is different than when it was when session stopped.

qhanam · 2023-01-24T17:29:34Z

src/sessions/PageManager.ts

@@ -8,6 +8,7 @@ export type Page = {
    pageId: string;
    interaction: number;
    parentPageId?: string;
+    timeSpentOnParentPage?: number;


question: Is there a way we can omit timeOnParentPage from this structure? This is stored on browser storage, so if we don't need it, we should omit it.

I feel like it's something we can compute during recordPageView().

Fixed in revision. Now its done during recordPageView

ps863 · 2023-01-25T18:37:29Z

question: How do we handle the case where the session is picked up from the cookie? For example, if user left the browser at page B, the web client may hold the "page.start" value in the cache, and when you move to subsequent pages, it may return an incorrect timeSpendOnParentPage information. If page.start is not stored in the cookie, what if the page manager's page.start is undefined? How do we handle this case?

Handled this in latest revision. The following change should handle the concerns you had:

If the resumed page Id is same as the page id stored when session temporarily stopped, then we don't dispatch a new Page View Event. Only the PageManager state is updated. The start time is updated as the time stored in the cookie (ie the start time is not reset like it was previously, and therefore the correct start time is recorded). Therefore when user moves to a new page, we will use the correct start time to compute time on page.

src/__integ__/cookiesEnabled.test.ts

ps863 requested review from adebayor123, limhjgrace and qhanam January 12, 2023 17:21

adebayor123 reviewed Jan 12, 2023

View reviewed changes

qhanam reviewed Jan 24, 2023

View reviewed changes

ps863 added 2 commits January 30, 2023 23:44

feat:Time Spent on Page

cc9fd81

Fix cookies enabled integ test

4fead55

ps863 force-pushed the timeOnPage branch from a170f84 to 4fead55 Compare January 31, 2023 07:46

qhanam reviewed Jan 31, 2023

View reviewed changes

src/__integ__/cookiesEnabled.test.ts Show resolved Hide resolved

qhanam approved these changes Jan 31, 2023

View reviewed changes

limhjgrace approved these changes Jan 31, 2023

View reviewed changes

ps863 merged commit d1c3b17 into aws-observability:main Feb 1, 2023

ps863 mentioned this pull request Feb 8, 2023

chore(release): 1.13.0 #355

Merged

ps863 mentioned this pull request Mar 16, 2023

fix: Handle missing PageId in metadata when page is resumed #388

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat:Time Spent on Page #341

feat:Time Spent on Page #341

ps863 commented Jan 12, 2023

adebayor123 Jan 12, 2023

adebayor123 Jan 12, 2023

ps863 Jan 18, 2023

adebayor123 commented Jan 12, 2023

ps863 commented Jan 13, 2023

adebayor123 commented Jan 18, 2023

qhanam Jan 24, 2023 •

edited

ps863 Jan 25, 2023

qhanam Jan 24, 2023

ps863 Jan 25, 2023

qhanam Jan 24, 2023

ps863 Jan 25, 2023

ps863 commented Jan 25, 2023

feat:Time Spent on Page #341

feat:Time Spent on Page #341

Conversation

ps863 commented Jan 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adebayor123 commented Jan 12, 2023

ps863 commented Jan 13, 2023

adebayor123 commented Jan 18, 2023

qhanam Jan 24, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ps863 commented Jan 25, 2023

qhanam Jan 24, 2023 •

edited