[Analytics] [Search] Header Search is firing duplicative GA events (view_search_results)

[aklausmeier]

Status

[2024-07-18] [Fran] Updated the Problem Statement, User Story and AC; moving to Ready column. This ticket should be implemented in Sprint 9 because it has budgetary considerations (we pay for every event fired).

Problem statement

Analytics team uncovered a duplicative search event firing in the header.

Basically, when a user is using the header search box, and they initiate a search, the _view_searchresults event is firing, and then it's firing again when the search page loads/displays.

This event should ONLY fire when the search page loads/displays.

User story

GIVEN a user is on VA.gov and enters a search term in the header search box, WHEN the user initiates the search, THEN the event "_view_search_result_s" should NOT fire AND when the search results page loads/displays THEN the event "_view_searchresults" SHOULD fire

Acceptance Criteria

• [x] the event _view_searchresults only fires when the search page loads/displays
• [x] Pass off to @FranECross for QA, which can only happen in PROD.
• [ ] Fran to verify and close.

[aklausmeier]

@mmiddaugh FYA

[randimays]

Pulling in from Refined & Ready for Sprint 16.

[randimays]

As discussed in this Slack thread, we want to make sure every entry point for site-wide search is logging analytics consistently and keeps the correct structure for the Analytics Team's reporting.

This ticket we recently closed was mistakenly addressed for the search bar on the /search page rather than the search bar on the homepage (next to Top pages), so we'll need to address that as part of this ticket as well.

I created this Mural with a proposed path forward (this Mural also illustrates the current state of things) in order to get our analytics streamlined. I will need @FranECross ~@aklausmeier~ and Jamie Stutt (analytics team, she is OOO today 11/4) to review and provide feedback.

[randimays]

Updated the above comment; I added the current state of things to the Mural as well.

[randimays]

End-of-sprint update: Fran approved my proposed approach to search analytics, but I'm expecting to get feedback from Jamie (Analytics team) today and not sure how much change that will entail. This will carry over.

[randimays]

Update here: This ticket ended up being larger than originally anticipated. By removing the extra events when using search inputs from other pages (not /search), we lose contextual information about where the search originates. We needed to wire up a way to keep the contextual information in the single event when loading the search results page. Because we've already removed the extra events on other search bars in other tickets, this wiring needed to be done for all the places that search can originate.

I'm still working on wiring this up and I estimate this ticket has another 1-2 points of work.

[randimays]

Update: In code review to be tested locally (and then in Platform's queue to review). Once it is in staging, it will be ready for @FranECross to review.

@FranECross: I made some updates to the Mural based on technical feasibility and conversations with Jamie. Do you mind reviewing this again please? Specific things to note:

1. We can get the typeahead suggestion clicked on the homepage search and the header search (both desktop and mobile), but we aren't able to get it from searches on the search results page. Because the suggestion box on that search only exists in the DOM while it is open (and is otherwise removed), there are timing issues listening for clicks on it and when the form is submitted. We can still send the list of typeahead suggestions through the event, but we won't know whether one of them was clicked.
2. If a user performs a search really quickly (submits the search before the typeahead box has a chance to populate), the typeahead suggestions will not be sent through. This is expected.
3. Here's the Slack thread where we discussed Jamie's reporting, in case you need a refresher. She said that our proposal wouldn't break any of their reporting.

[randimays]

@FranECross The new search analytics events are in production and ready to review. Reminder: here's the Mural. It has the latest structure of events to expect.

Essentially, we have 5 search entry points other than the /search page (that we know of?):

1. Mobile header (separate code from desktop header)
2. Desktop header
3. Resources & Support (All VA.gov selected)
4. Homepage
5. 404 page (see notes below)

None of these should produce a GA event when their search button is clicked. We should only get one event (onload_view_search_results) when the /search page loads.

404 page

Right now, the 404 page lives in a different repo and is not set up to feed data to the search page about its origin (like the other entry points in vets-website can). When the event is logged from a 404 page search, it'll look like it originated on the search results page.

Example

I searched "benefits" from the search bar at va.gov/blah and got this event on load at /search:

Edge cases and such

When I spoke with Jamie Stutt from the Analytics team, she mentioned that we don't currently handle (via analytics) searches that land on /search from a Google search, or searches from someone copy/pasting a URL into a new browser window (e.g. https://www.va.gov/search/?query=benefits).

I think this, and searches that originate from the 404 page, could be a separate effort to iron out if we decide to do so. For now, they'll continue to look like they came from the search results page. Do you think we need a ticket to explore this? Or are we ok with the current treatment?

CC @jilladams @aklausmeier FYI

[FranECross]

@randimays I finished the testing (sorry it took so long!), and have results in this Excel doc (I've shared "anyone with a link"). Some of the tests seemed to fail, where I chose a typeahead option but it didn't display in the event. And also one event showed a bit differently than what Mural suggested. Please let me know if you have any questions.

[randimays]

@FranECross

The changes I made and the Mural represent only site-wide searching. Searches within our other applications (such as Resources & Support and Find Forms) have their own view_search_results events and those are not duplicative because they do not lead to the global /search page. This ticket's concern is for any searching that lands on https://www.va.gov/search/ when using the search bar.

Row 2 in the spreadsheet

This scenario does not represent functionality that was updated for this ticket and should still have the same event as before:

event: 'view_search_results'
'search-page-path': {URL from where the search originated - e.g. /resources/something}
'search-query': {query}
'search-results-total-count': {count}
'search-results-total-pages': {total pages}
'search-selection': 'Resources and support'
'search-typeahead-enabled': false
'search-location': 'Resources And Support'
'sitewide-search-app-used': false
'type-ahead-option-keyword-selected': undefined
'type-ahead-option-position': undefined
'type-ahead-options-list': undefined
'type-ahead-options-count': undefined

Row 15 in the spreadsheet

This scenario is as expected. The /search page uses the <va-search-input> web component. When the typeahead suggestion box loads below the search bar, and you click a suggestion, the search immediately happens when you click. This also closes the suggestion box. The code that would pick up the suggestion clicked would need the below in order to work correctly: 1) the suggestion box to be open 2) some lag time in between the click of the suggestion and the actual search (there is none or it is way too small a gap)

That said - the homepage search also uses the web component. But because it doesn't immediately search, but rather redirects to another page that does the searching, there's (most of the time) enough lag time for us to pick up the suggestion click.

[FranECross]

@randimays Thanks for the explanations! I've updated the spreadsheet and consider this passing. Okay to close.

[randimays]

Per Fran's comment above, closing as complete!