[Analytics] Audit PW GA spreadsheet and create additional tickets

[randimays]

Description

Our custom GA events epic (#18184) does not accurately represent the work required from the spreadsheet. There was also at least one missing item on the spreadsheet (for homepage hub links).

See this Slack thread for context: https://dsva.slack.com/archives/C52CL1PKQ/p1719507165841209

Acceptance criteria

• All remaining custom events that should be converted to web components have been accounted for in tickets on the Sitewide board

[randimays]

Facilities ticket where analytics were gathered: #17532

[randimays]

End of sprint update: I have created some tickets for Public Websites, but no tickets have been created for Facilities yet (and I'm not sure of the lift; I haven't had time to review the spreadsheets in this ticket). I want to do another pass through all of the custom events for Public Websites and make sure I've captured everything and that the spreadsheet is totally up-to-date. After that, I'm going to move over to Facilities and do that same for those products.

This will certainly carry over. I estimate there's probably about 3 points of effort left. Noting that the original points for this did not include Facilities work.

[jilladams]

Noting from sprint planning: we had to pause this work for Injected header, and have had enough other priority work pop up that it wasn't possible prioritize in Sprint 8. Unassigning Randi, moving back to Ready, and when we are able to pick this up again, we will.

[randimays]

@FranECross @Agile6MSkinner Re: analytics for VBA pages

I ask specifically about these because this code is relatively new and is already using web components so I'm not sure if the custom events are intentionally duplicative.

Example page: https://web-cmugn5ieupsmz1cyrrmcwiwcawfidlrx.demo.cms.va.gov/philadelphia-va-regional-benefit-office/

The phone numbers in the first screen and the "Find a VA benefits location" link in the second screenshot are currently using web components, but they also have custom events on them (meaning we are getting two events for each one).

For Main Phone, we are sending a custom event with this info:

'event': 'vba-regional-facility-vba-facility-main-phone-number',
'vba-regional-facility-name': {facility name}
'link-label': 'Main Phone'

A <va-telephone> element (which this is), already records the origin URL, destination URL / href, and the contact number and extension. Is this custom event necessary, or can we remove it?

For VA benefits hotline, we are sending a custom event with this info:

'event': 'vba-regional-facility-vba-facility-va-benefits-online',
'vba-regional-facility-name': {facility name},
'link-label': 'VA benefits hotline'

Same as above; this is a <va-telephone> element with a baked-in analytics event. Do we need the custom event, or can we remove it?

For Find a VA benefits location, we are sending a custom event with this info:

'event': 'vba-regional-facility-vba-facility-find-VA-benefits-location',
'vba-regional-facility-name': {facility name},
'link-label': 'Find a VA benefits location'

This is a <va-link> element, which tracks the origin URL, destination URL and the title of the link. Is this custom event needed, or can we remove it?

[randimays]

@FranECross @Agile6MSkinner I found a few more VBA links that I'll need some help clarifying whether they need action:

https://web-2pegzvqcy77ynmcultaityqtlrpfbfoo.demo.cms.va.gov/honolulu-va-regional-benefit-office-at-spark-m-matsunaga-department-of-veterans-affairs-medical-center/ > Disability compensation accordion, Learn how to manage disability compensation benefits online link:

This link has already been converted to a web component but it has a duplicate link on it.

Custom event:

'event': 'vba-regional-facility-services-manage-benefits-online',
'vba-regional-facility-name': {facility name},
'accordion-parent-label': {accordion title},
'link-label': {link title}

Schedule an appointment online link (I couldn't find a Tugboat URL / VBA facility to test this on). This link is not a web component; should it be converted and use baked-in analytics?

Custom event:

'event': 'vba-regional-facility-service-location-schedule-appointment'
vba-regional-facility-name: {facility name}
accordion-parent-label: {accordion label}
link-label: Schedule an appointment online

Email address link (I couldn't find a Tugboat URL / VBA facility to test this on). This link is not a web component; should it be converted and use baked-in analytics?

Custom event:

'event': 'vba-regional-facility-service-location-email-address'
vba-regional-facility-name: {facility name}
accordion-parent-label: {accordion label}
link-label: {email address}

CC @laflannery Do you know of a Tugboat link where I could find the Schedule an appointment online and Email address links?

[laflannery]

@randimays The schedule an appoint link should be in Disability compensation and pretty much every service accordion in Honolulu. I think one of the VBA tickets we did recently somehow messed this up and it's not showing now. I'm going to investigate and see what I can find.

Regarding the email addresses, those just recently got fixed I believe but we don't have a ton of actual services. I can add some and release content on my own tugboat shortly for this

[FranECross]

@randimays I'll need to defer to @Agile6MSkinner regarding the VBA analytics/links.

[Agile6MSkinner]

@randimays @laflannery If we have the tracking in the web components, it seems like the custom events would be redundant, no? It seems like there's a bigger picture here that I'm not getting in terms of the move to GA4 and what analytics are now in web components vs what we need custom events for. Who can bring me up to speed on that?

[FranECross]

@aklausmeier Tagging in Amanda, since she has insight into what some of our custom events gather. @Agile6MSkinner For some background, the events that the components are providing are extremely basic, and in some cases don't give enough information depending on the feature. For instance, the analytics person (Jamie) reviewed our custom events recently, and as an example said for the Campaign Landing pages she thought we should keep them and not use the baked in component analytics because we lose all the section/location information by doing adopting the component analytics (she recommends going back to the clp-link-click event if that was important). In many cases, we can go ahead and implement the component, but then just disable the baked in analytics and continue to use the custom analytics. cc @randimays @laflannery @mmiddaugh

[aklausmeier]

We don't want duplicate events being sent through GA4. There is a cost associated but we also don't want to compromise on losing data. If there is no risk of losing data and it's a duplicate then that seems to suggest the baked in DST component is sufficient and custom can go away. If there is a grey area or you are unsure, I strongly suggest reaching out to the analytics team in their Slack to confirm.

[randimays]

For instance, the analytics person (Jamie) reviewed our custom events recently, and as an example said for the Campaign Landing pages she thought we should keep them and not use the baked in component analytics because we lose all the section/location information by doing adopting the component analytics (she recommends going back to the clp-link-click event if that was important)

@FranECross We already removed all the custom events in Campaign Landing Pages (this ticket's ACs said to remove all custom events and fall back to baked-in).

Didn't we say that section (location on the page) was unnecessary since we have the text of the link and the origin URL?

[laflannery]

CC @laflannery Do you know of a Tugboat link where I could find the Schedule an appointment online and Email address links?

@randimays

Here is a tugboat with both the Schedule and appointment and email links for you to take a look at: Philadelphia VBA Life Insurance Service https://web-codylbelkq0gdivw6x7tykigmeqloewe.demo.cms.va.gov/philadelphia-va-regional-benefit-office/vba-service-item-1147-

[FranECross]

@randimays Thanks for the reminder, and you're absolutely correct. We did decide the baked-in analytics would suffice for this one. I think I was confusing it with a different convo I'd had. Thanks.

[randimays]

@FranECross @Agile6MSkinner This audit is complete and we have an additional 25 tickets in this epic: #18184. I'm closing this ticket.

Background for web component vs. custom GA events and the analytics migration

The Platform Analytics team (Slack channel: #platform-analytics) had a July 1 deadline to upgrade to Google Analytics 4. Earlier this year, they asked VFS teams to gather & send all their custom Google Analytics events so the Platform Analytics team can ensure the custom events transfer correctly when the upgrade occurs.

In the front end repos (content-build & vets-website) we can create custom Google Analytics events by using a VA Platform utility on interactions such as links/buttons, or while making API calls. These are the events we gathered and sent to the Platform Analytics team.

A design system web component (such as <va-link>) has "baked-in" analytics. The web component's code fires an event with basic info when it is interacted with. If we don't want this event to fire, we pass a flag on the web component to prevent it.

It is also possible to use both web component analytics and a custom event together.

ℹ️ For the purposes of this epic / audit, we are only concerned with removing custom events where the custom event can be replaced by the web component baked-in event. We are not adding new events or updating existing events otherwise.

Updated Sitewide Google Analytics events spreadsheet

https://docs.google.com/spreadsheets/d/1fDsRQct_QMJ5nd3bTRDgwrfbFo_PqzdFQqYecJouic8/edit?gid=0#gid=0
and Sharepoint worksheet https://dvagov-my.sharepoint.com/:x:/g/personal/randi_mays_va_gov/EWJlQ7eATRdMjn2A4c9fYv0By9ZoeVbyCH7LngqVfAUCAQ?e=n5eZqo

Events tab

A comprehensive list of GA events, both current/future and events that have already been removed as of 7/17/2024.

Columns explanation

Custom event to be removed

• Yes: this event has already been removed, or will be removed by the ticket in the Ticket Status column
• No: this event should not be removed because:
  • it adds more useful detail than the web component upgrade can provide
  • it is not possible for some reason to upgrade this element to a web component at this time
  • the event occurs for an API call or some other method where a click / interaction event does not suffice

Custom event is on top of web comp event

• Yes: A custom event and web component event will fire for this interaction
• No: Only a custom event exists for this interaction
• N/A: The custom event will no longer exist when the ticket is complete

Sitewide FE pages / Example URL: Sitewide product and example URL where this interaction can be found (or API call is made)

Ticket status

• Green background: for the purposes of this audit: no action needed
• Yellow background: Needs review and a ticket; there are notes for each

Elements with custom events, event name, other event data

Specifics for what element triggers the event, the event name in GA, and any other data that is logged. { } represents variables depending on the situation.

Web Component Analytics tab

A list of web components' baked-in analytics from the Design System team. This is not a comprehensive list of all web components used by Sitewide products; these are the web components that Sitewide products used that had custom GA events at the time we started doing this audit.