Metrics - Hold Pass timer - will snowplow work?

[Dianadec]

Description:

With implementing a timer, let's look at some metrics to see how long it takes the average person to fill out their information on that page.

--> number of times a timer lapses this will be difficult to track with Snowplow. A better way of tracking would be to count the number of times the amount of time spent is equal (or at least very close to) the maximum allowable time on the page. --> average amt of time spent

This ticket is to see if snowplow can provide this information before delving further into a unique method.

Acceptance Criteria:

• [ ] determine if snowlplow can provide this information
  • [ ] if not - create a new implementation ticket to find a way to do this (for a future sprint)

Dependencies

Our responsibilities with Snowplow end with snowplow.js in DUP Public. This script simply turns on several general tracking metrics for the site and then forwards it to a collector maintained by BCParks but outside of Osprey. The data is then represented on the GDX Analytics Dashboard, which already shows metrics on page hits and time spent on the site in general. The maintainer of this collection may be able to massage this data to get us the average time spent on the /reservations page that will contain the pass timer.

The GDX Analytics team has been emailed to request this information (GDX.ServiceDesk@gov.bc.ca) on Apr 29 2024.

If the GDX Analytics team is unable to complete this request, then it may be worthwhile looking to other methods of tracking. AWS Cloudwatch may be a useful source of metrics tracking, or simply tracking site traffic data alongside system data in the metrics tab.

One major disadvantage to this is that the /reservations page starts when you click into a park and have not selected the facility, time of day, or number of passes requested. When a user has done all this and clicks 'Next', this is when the timer is supposed to start - but the following page is dynamically rendered on the same /reservations route. Therefore, any time spent on the select facility page (before the timer starts) is factored into the Snowplow 'time spent on page' metric, which will skew the actual information we are looking for.

This could be solved by moving the contact information page you get to after the facility select page to its own url, but that could lead to be a large change that could be risky, ie, it changes the fundamental flow of the site, which has been used with little failure for 3 years now.

We should consider how accurate we need this metric to be and how important it is to have before we make major changes to the pass booking flow.

Notes:

• possible solution? Use metric table for recording BI

[Dianadec]

Look into snowplow first.

[Dianadec]

Haven't heard back from gdx - Cam to setup a ticket for plan B - once the DUP hold timer has been implemented. cc @JLWade

[cameronpettit]

Doesn't sound like we will hear from the GDX team. I have created #467 to continue this analytics issue. Might be worthwhile using this as an opportunity to investigate how we might want to capture analytics for PRDT.

[JLWade]

good thanks Cam! lets move this one to done.