[Analytics] [VAMC link teasers] Custom GA events removal

[randimays]

Status

Description

The va-link web component's analytics now include link destination, and va-link-action has been released to the component library. We can now use baked-in analytics for link teasers on VAMC pages.

User story

AS A PO/PM managing Sitewide products & features
I WANT to (where appropriate) adopt the va-link or va-link-action component, its baked-in analytics, and remove the custom GA events
SO THAT extraneous code is removed and only the events needed will be triggered.

Engineering notes / background

Content-build template: https://github.com/department-of-veterans-affairs/content-build/blob/main/src/site/paragraphs/facilities/list_of_link_teasers_facility.drupal.liquid#L49

Acceptance criteria

• Elements: link teasers
  • enable web component analytics
  • remove custom events
• Requires QA

[jilladams]

#18501 was not supposed to go in QA (my mistake) or prod verify. There was some confusion around this one. The link to the code from the issue didn't exist and the file that I think it meant didn't have custom events https://github.com/department-of-veterans-affairs/content-build/blob/main/src/site/paragraphs/list_of_link_teasers.drupal.liquid

https://dsva.slack.com/archives/C03LFSPGV16/p1724284549146289?thread_ts=1724282351.499789&cid=C03LFSPGV16

Closing.

[randimays]

Whoops - I somehow flubbed the code link for this. It should be pointing here: https://github.com/department-of-veterans-affairs/content-build/blob/main/src/site/paragraphs/facilities/list_of_link_teasers_facility.drupal.liquid#L49 (also updated in the ticket description). Reopening; but please flag if this was somehow solved another way.

[eselkin]

@randimays This one has disable-analytics and some paragraph-related data being captured. Are we sure we are ok losing that? I mean, I'm guessing it's probably fine because we get textual data on link clicks from DST component analytics.

[randimays]

@eselkin Tagging in @Agile6MSkinner for this; that is a Product decision but Product was largely deferring to me to make decisions about when to remove analytics so I made the ticket for our consideration.

[Agile6MSkinner]

I don't know enough about our analytics yet to answer. @mmiddaugh do you have thoughts on Eli's question above?

[eselkin]

This is extent of what we get from the "extra" data:

'featured-content-header': '{{ paragraph.fieldTitle }}', 
'featured-content-click-label': '{{ link.title }}' 

It's like a little broader than what comes back from the regular DST component data. The link title would still come back, but the fieldTitle on the featured content would not normally. Let me do a local build with analytics allowed and copy the 2 objects side by side

[eselkin]

This is at: https://www.va.gov/pittsburgh-health-care/#9246d10cf4f5f599e892c702e4ffe33a
(but built locally to allow DST component to fire)

In the annotated image below, only the custom event currently triggers. If we replace it with the DST event we lose that paragraph.fieldTitle ("In the spotlight at VA Pittsburgh...")

However, that title seems wrong since you would expect it to be: "Other services at VA Pittsburgh health care" or something closer, but it's the section.

I'm all for removing the custom event since the additional information is kind of not clarifying.

[jilladams]

@FranECross since you've been closer to this project, you can maybe help Michael co-sign Eli's note?

[FranECross]

@eselkin Apologies for not seeing this until now. I agree with your assertion that the custom event isn't really accurate and not providing value. I'm all for removing it, too. Thanks! cc @jilladams @Agile6MSkinner After a meeting with Michelle today (9/9)... see decision in Michael's note below.

[Agile6MSkinner]

Discussed at product sync. Per @mmiddaugh and team, keep the custom tagging because it provides higher fidelity. Disable DST.

This conversation uncovers a broader need to work with DST on the tagging in components and the utility of the analytics that are provided.

[jilladams]

@eselkin Looking at this one to verify if it's closeable, but I think it needs follow up. Fran had originally co-signed removing the custom event, which went into a PR. But a follow up comment suggested instead keeping the custom event / removing the DST event instead. I think that still needs PR. I'm gonna move this ticket back to Current sprint to catch that change.

[eselkin]

However the custom event was incorrect in its data

[jilladams]

Ah, I think we missed that in the discussion with michelle. noting for next scrum (Thurs), just to make sure no other danglers and we can close as is.

[jilladams]

@eselkin looking at this in hopes of getting closure, 2 questions:

1. Where the custom event says "In the spotlight at..." rather than "Other services at..." -- do we know where it's getting "In the spotlight..." from? That's old labeling for the link teaser box, and seems like maybe that got hard coded into the event somehow?
2. Since it's a custom event, can we not update that labeling to be accurate?

[FranECross]

@eselkin looking at this in hopes of getting closure, 2 questions:

1. Where the custom event says "In the spotlight at..." rather than "Other services at..." -- do we know where it's getting "In the spotlight..." from? That's old labeling for the link teaser box, and seems like maybe that got hard coded into the event somehow?
2. Since it's a custom event, can we not update that labeling to be accurate?

I think #2 above is what Michelle would want, since in the prod sync meeting she indicated she relies on the 'Featured content header' in order to gather meaningful analytics, so fixing the header text would do what she needs, as well as disabling the component analytics.

[eselkin]

I'm sure we can get that correct text and use the custom event.