Update REACH_RESULT_END, LOAD_MORE, SELECT_SEARCH_RESULT analytics events for additional search views

[obulat]

Problem

REACH_RESULT_END and LOAD_MORE_RESULTS events are currently sent from the additional search views with the correct values for searchType and resultPage, but query is set to blank string "".

The SELECT_SEARCH_RESULT is also sent for additional search views results and has a query property that is currently set to searchTerm:

openverse/frontend/src/types/analytics.ts

Lines 253 to 269 in 3e57bfa

	SELECT_SEARCH_RESULT: {
	/** The unique ID of the media */
	id: string
	/** If the result is a related result, provide the ID of the 'original' result */
	relatedTo: string | null
	/** Kind of the result selected: search/related/collection */
	kind: ResultKind
	/** The media type being searched */
	mediaType: SearchType
	/** The slug (not the prettified name) of the provider */
	provider: string
	/** The search term */
	query: string
	/** the reasons for why this result is considered sensitive */
	sensitivities: string
	/** whether the result was blurred or visible when selected by the user */
	isBlurred: boolean | null

Description

We should update the payload to add the search view (similar to what we have in the strategy in the search store: 'default'/'tag'/source'/'creator', and also update the code to set query to the tag for tag pages, source for source pages and source&creator pair for the creator pages.

Alternatives

Additional context

[obulat]

@WordPress/openverse-frontend, what do you think is the best way of recording these events? Currently, the payload for these events is:

{
    /** The media type being searched */
    searchType: SupportedSearchType
    /** The search term */
    query: string
    /** The current page of results the user is on. */
    resultPage: number
  }

For the additional search views, we need to add the tag value for tag pages (the analog of query for search), source value for source pages, and source and creator values for the creator pages.

I think we can update the payload to be:

 {
    searchType: SupportedSearchType
    query: string // `tag`, `source` or `source/creator` for the additional search views
    strategy: "search" | "collection"
    resultPage: number
  }

Is there anything we should add/remove? Also, @dhruvkb, do you think there are drawbacks to adding a new property to an existing event?

[dhruvkb]

do you think there are drawbacks to adding a new property to an existing event?

I don't think there are any drawbacks.

[sarayourfriend]

I've asked this before, and I can't remember what the reason for doing this approach was, but the strategy duplicates the page path, doesn't it? Search will always be /search or /search/image|audio and collections /image|audio/collection. As much as we can, we should try to rely on the page path for things like this, if we can, because it's possible to query it in addition to one custom property, whereas it is not possible to query multiple custom properties.

Mostly asking for clarification on why the strategy property is needed separately from the page path, if it is, so that it's documented. Otherwise, I will probably end up asking the same question in a few months time 😅. Preferably a comment in the code explains this.

[obulat]

Noting here that Plausible recently added the ability to filter by more than 1 custom property.

I couldn't, however, find a way of filtering by the query parameters. This means that we won't be able to distinguish between the collections. If we do want to do so, we need to add a custom property for it. I think we should add the strategy, but use tag/creator/source instead of a single value of collection. This way, we could compare how often users select results from and load more results for each kind of page.

This is what I think we should send:

 {
    searchType: SupportedSearchType
    query: string // search term for default search, and the value of `tag`, `source` or `source/creator` for the additional search views
    strategy: "search" | "tag" | "source" | "creator"
    resultPage: number
  }

This way we can see how useful the users find each kind of view. If they often load more pages for one kind of "strategy", that would mean that it is a very useful feature.

[sarayourfriend]

Noting here that Plausible recently added the ability to filter by more than 1 custom property.

Oh! That's really exciting and great to know. That eliminates any concern I have.

The expanded strategy sounds good to me, but could we have tag_collection, source_collection, and creator_collection, just so that it's not possible to confuse it with the field-based, non-collection "search" strategy search? https://api.openverse.engineering/v1/images/?creator=hello&source=flickr

It's a separate code branch (sort of) from q based searches, so it would be easy to make the confusion without detailed domain understanding.

[zackkrida]

I'll get a PR up today, but I wanted to share my own understanding of these properties:

• We already have "kind" on the SELECT_SEARCH_RESULT event to distinguish if a result is from a standard search result set, a related result set, or a collection result set. This isn't my favorite name, but this seems to cover the "strategy" requirement.
• The remaining information we need is the "sub-type" of the collection (tag,source, or creator) and then the actual value of the collection ("flickr", "dogs", etc.). I do not think we should overload existing fields for those and instead should use two new fields: collectionType (tag, creator, or source) and collectionValue (the actual tag, source or source/creator name string). These are analogous to other contextual custom properties like relatedTo which is part of the SELECT_SEARCH_RESULT payload but only applies to related searches.