Search term tracking

[hazelngan]

No description provided.

[hazelngan]

Hi @jdelagarzaf i implemented your feedbacks but run into some errors still

Fixed: I moved tracking into a Stimulus controller pushing to window.dataLayer (not gtag, which was scoped/broken as you noted). I also verified this manually in browser's console which event fires correctly with search_term/category/location. Now event fires on search submit, not on page render, so no more inflated counts from reloads/pagination. RuboCop is also clean. I also rebased the branch onto main so history's no longer contaminated.

Stuck: The fix works in a real browser, but I can't get the automated system spec to reliably observe the same event — passes manually, fails in Capybara/Cuprite despite trying a few approaches. Would love your help with this

[jdelagarzaf]

Hi @jdelagarzaf i implemented your feedbacks but run into some errors still

Fixed: I moved tracking into a Stimulus controller pushing to window.dataLayer (not gtag, which was scoped/broken as you noted). I also verified this manually in browser's console which event fires correctly with search_term/category/location. Now event fires on search submit, not on page render, so no more inflated counts from reloads/pagination. RuboCop is also clean. I also rebased the branch onto main so history's no longer contaminated.

Stuck: The fix works in a real browser, but I can't get the automated system spec to reliably observe the same event — passes manually, fails in Capybara/Cuprite despite trying a few approaches. Would love your help with this

Hi @hazelngan ,
The issue is that there are two search templates, and only one is wired.
The second one is when you land at /search with no parameters; it opens a _preview template with its own copy of the search form, and the "action:" was only added to the show.html.slim file.
Capybara does exactly this; it visits the page without parameters so it encounters the untouched search template. Fixing this should make tests work too.

Also, the homepage has a separate search that is also untracked. Located at home/index.html.slim:9 with no search controller and no action. Searches from there result in no tracking

And check this out: location is always undefined.
search_controller.js:378 uses document.querySelector('[data-geolocation-target="currentLocation"]'), and the first match in the document is the navbar's

tag at navbar/component.html.slim:11, not the search bar's tag at search_bar/component.html.erb:39.
During your testing, make sure to check the event payload so that it always matches what is expected, not just that it fired.
Fix: scope it to only the input tag rather than any tag (this.element.querySelector('input[data-geolocation-target="currentLocation"]')) or add a proper Stimulus target.

About your specs,
search_analytics_system_spec.rb:62-74 does JSON.stringify(window.dataLayer), which throws "Converting circular structure to JSON". Both the JS catch and the Ruby rescue turn that into "[]" — a silent empty read that looks like "event never fired". Pluck only the scalar fields you assert on instead of serializing the whole array.

The request spec is a false negative.
searches_spec.rb:13 asserts the markup string is in the body, and it passed the whole time the feature was broken, because passing search params routes to show.html.slim. Also, expect(page).to have_current_path(search_path, ignore_query: true) in the system spec is already true before submitting, so it isn't properly testing it.

Small detail: clearing the keyword fires a search event with search_term: "". Prevent that from happening; otherwise, it'll show up as empty search terms.

[hazelngan]

@jdelagarzaf I edited the untracked preview template, the homepage search, the location selector bug, and the JSON.stringify masking in the system spec. I then confirmed in dataLayer locally: search events now carry the right search_term, category, and location together on the same object, from both the homepage and results page. All 4 specs pass on my terminal as well

[jdelagarzaf]

Great job Hazel!

The feature as it stands is complete in code, unless you'd like to add filter capture. Currently, filters and pills that are activated are indistinguishable from regular searches. If you'd like to expand the ticket's capabilities and if it is in scope, you could add records of them.

Besides that, now all that is left to do is configure it from the GTM console with the event name search and the following variables: search_term, category, search_origin, location.