Ignoring URL query parameters in Behavior Flow

Question

A major part of my web app is a rich search functionality with about 7 different facets to filter on. All the search parameters are fully represented in the page URL; this means that a user might remain on what is conceptually the search page (i.e. URL always has the same path, /search) but with varying combinations of query params (?q=holiday&fa=200&fb=3&...) as she tweaks the filters.

My goal is twofold:

1. To be able to capture every combination of search filters issued in a user session, for a deeper understanding of how people find what they're looking for. In particular I'd love to see full query params for each pageview hit in our export to BigQuery
2. At a higher level, our product manager requires Google Analytics's Behavior Flow chart to collapse consecutive searches into a single interaction step (as long as user didn't navigate away from search to some item detail, then back). To my mind this means that I want Behavior Flow to ignore everything in the page path after the ?.

When I let gtag.js record pageviews on its own, I seem to fail goal 2, as I do see query params—even session tracking from referrers!—in the interaction steps. When I disable send_page_view and instead explicitly send a pageview by setting on the gtag config {page_path: '/search'}, which omits the query params, then I achieve goal 2 but have lost the rich data required for goal 1.

Does Google Analytics offer a compromise? I read about content groupings, but the docs made it seem to me like this might be intended for static pages rather than unlimited dynamic search results.

Answer 1

Content grouping will create an overall Group eg "Search", that can then be drilled down into in the All Pages report. This could be done using Rule Definitions based on Page and "starts with" /search. If the Search content group is selected in Behaviour Flow report, you will lose some information in the report (1 example - the Start Page information for Landing Pages).
Content groups are not retroactive.

The 2nd alternative is to use the View Settings to Exclude URL Query Parameters and to Strip Query Parameters out of URL for search queries. These two options will remove all the specified parameters from the pageview URLS, however this will then also remove the data you need for your stated first goal.
This option also will not be retroactive.

Given that neither option will be retroactive, I would setup two new Views for testing purposes, one using the Content Grouping method, the 2nd using the Exclude URL Query Parameters together with Strip Query Parameters out of URL method.

Once both methods have been tested and one decided on, then the nonoptimal Test View can be deleted, and the chosen View can be renamed to something suitable and retained.

This will not affect the View you are using that you wish to retain all the parameter data in for your 1st goal and will allow you to test and create a new View that fulfills your product manager's needs.