docs
  1. SCAYLE Resource Center
  2. Developer Guide
  3. Features
  4. Search
  5. Analytics

Analytics

A properly implemented tracking will help you gain insights about how your customers interact and experience search.


The gathered insights can then be used to further improve your search implementation as well as configuration. Keep in mind, that SCAYLE follows a “category-page”-first approach. Therefore, we try to optimize towards redirecting as many searches to matching categories.

In the next chapters, you will learn about the most essential tracking events, that we consider to be essential in order to gain insights about the acceptance of your current search implementation as well as of the state of your search configuration.

First, let's start with the basics of how data is collected and sent to analytics or marketing platforms. Then, we can move on to the concept of event tracking.

Fundamentals of data creation process

Google Analytics 4 (GA4) represents a significant shift in how web and app data is collected, processed, and reported. Unlike previous versions, GA4 is event-driven, meaning every interaction is captured as an "event." But what is an event?

What is an event?

In its simplest form, an event has:

  • event name
  • timestamp
  • unique identifier

The simplest form of an event, lacking any additional information

Add meaning to an event

To make the meaning more precise, add context, including them in the event data.
For example, the search event can be extended in the following way:

Additional information can improve the analysis process

Event parameters provide valuable insights into the context and meaning of an event, enhancing the ability to analyze event data. They offer additional dimensions for analysis, such as generating a chart that breaks down search start by page type.

More about GA4 parameters can be found in the GA4 documentation.

Google Tag Manager's Role

In the world of web analytics, it's important to understand how Google Tag Manager (GTM) and Google Analytics 4 (GA4) or other marketing vendors work together. This chapter will explain the relationship between these tools and how they can improve your data collection and analysis.

From website to marketing platform. Extract, transform, and load processes with GTM

Google Tag Manager (GTM), a free tag management system, acts as a mediator between your website and analytics tool, like GA4, or a marketing platform, like Google Ads or Meta Ads.
It allows you to manage and deploy marketing tags (snippets of code or tracking pixels) on your website or mobile app without having to modify the code. It's a data translator.

In general, it is an ETL-Process - Extract, Transform & Load. Information is Extract as events from the website, Transformed inside GTM and prepared to Load it into another system, e.g. GA4 or Bing Ads.

A tag manager system aims to be vendor-agnostic, which is why it is necessary to transform the data within GTM before loading it into analytics or marketing platforms. The transformation is done with a mapping from vendor-agnostic extracted data from the website to transform it to the necessary form for the marketing or analytics platform.

GTM uses triggers to send data to a vendor. This means that when a user interacts with a button or visits a specific page type, this information is sent to the analytics or marketing platform.

SCAYLE’s Storefront Core Boilerplate supports GTM out of the box

Glossary

TermDescription
GA4Google Analytics 4, which is the latest version of Google Analytics that has been rebuilt from scratch
GTMGoogle Tag Manager
EventThe smallest unit of measurement
MappingInvolves transforming event data within a tag management system – such as GTM – from a vendor-agnostic format into the required format for marketing or analytics platforms
TriggersA fundamental concept that determines when specific tags should be executed, such as based on user interactions
Tracking or measurement conceptA systematic approach is used to monitor and analyze user interactions on a website or app. This approach helps define measurable objectives, monitor progress, and maintain an overview of all implemented events, parameters, and values

Search tracking concept

Search tracking is a crucial aspect of optimizing the experience for the customer. Search tracking involves monitoring and analyzing the search behavior of users.

The concept is based on search for one of the Google recommended events.

Conventions used

  • If you see (optional) in the title, it means that it is not necessary to meet the minimum tracking requirements recommended by SCAYLE.
  • If you see {{ }} , they can have dynamic values based on the provided information.
    • E.g. {{ page_type }} can have different values, depending on the location of the visitor when they trigger an event.

GA4 configuration

Google Analytics 4 automatically registers event names, so you don't need to worry about it. However, custom parameters, known as custom definitions — dimensions or metrics —, require a set-up, which can be done through the GA4 user interface. Without this configuration, you won't be able to view that information in the interface.

Keep in mind, that there are pre-defined GA4 parameters, like page_location, that do not require any setup. Read more information about custom definitions in GA4.

Below are the custom dimension (CD) and naming ideas to set up in GA4. You will find the namings in the data layer definition in the tracking concept.

  • custom dimension: event_action
    • scope: event
  • custom dimension: page_type
    • scope: event
  • custom dimension: page_type_id
    • name: page_type_id
    • scope: event
  • custom dimension: page_type
    • scope: event
  • custom dimension: suggested_search_term
    • scope: event
  • custom dimension: number_search_results
    • scope: event
  • custom dimension: search_term_completed
    • scope: event
  • custom dimension: search_destination
    • scope: event
  • custom dimension: suggested_brand
    • scope: event
  • custom dimension: suggested_category
    • scope: event

Advanced users have the option to use a different naming convention if they prefer.

Don’t forget to map those fields in the GA4 tag configuration inside Google Tag Manager, else you won’t receive additional information.

Open Search bar / initiate a search (optional)

Search Bar

Goal: Measurement of usage to determine general acceptance

Gaining insights:

  • To track general acceptance, use the Click-Through-Rate (CTR) for the search bar
    • Calculated as the number of times the search bar is opened divided by the number of page views.
    • For example, if the search bar is opened 200 times on a page that has 1000 views, the CTR for the search bar on that page is 200/1000 = 20%.
  • If the search bar is frequently used on certain page categories, it might indicate that users are not finding what they need through the page's layout or content.
  • On the other hand, high usage on the homepage might indicate that users prefer to search directly for what they need rather than browsing.
  • A/B Testing expandable search bar vs. search field

Frontend Trigger: The user clicks on the search bar input field

Data Layer implementation

{
  event: "search", 
    // type: string
  event_action: "start",
    // type: string
  content_name: "<page path>",    
    // e.g. "/"
    // document.location.pathname
    // type: string
  page_type: "<page_type>",
    // e.g. "homepage"
    // see page types definition
    // type: string
  page_type_id: "<page_type_id>",
    // type: string
}

Category / Page Search Result Page (SERP) - Suggestion

Search suggestion - redirect to SERP (optional)

Typing search term

Goal: Measure a submitted search

Gaining insights:

  • Usage behavior of the search suggestions feature

Frontend Trigger: The user hits enter on the keyboard, to be redirected to the Search Result Page (SERP)

Data Layer implementation

{
  event: "search", 
    // type: string
  event_action: "submit"
    // type: string
  content_name: "<page path>",    
    // e.g. "/"
    // document.location.pathname
    // type: string
  page_type: "<page_type>",
    // e.g. "homepage"
    // type: string
  page_type_id: "<page_type_id>",
    // e.g. 
    // type: string
  search_term: "<lowercased search term>",
      //e.g. "shir"
      //type: string
      // always contains the string that the user entered, not the autocompletion
}

Category / Search suggestion - search result

Search Suggestion

Goal: Measure a successfully executed search in the search suggestion

Gaining insights:

  • Top and bottom clicked searched products
  • Amount of displayed results
    • Identifying gaps in products and improving the search feature enhances user experience.
    • Zero results can be used for missing products or synonyms, see next paragraph

Frontend Trigger: The user clicked on a suggestion

Data Layer implementation

{
  event: "search", 
    // type: string
  event_action: "suggested product"
    // type: string
    // e.g. "suggested category", "suggested product", "suggested brand"
  content_name: "<page path>",    
    // e.g. "/"
    // document.location.pathname
    // type: string
  search_destination: "/b/shop/nike-272/all?category=20345",
    // Destination page path for user redirection
    // type: string    
  page_type: "<page_type>",
    // e.g. "homepage"
    // see page types below
    // type: string
  page_type_destination: "<page_type>",
    // e.g. "category", "serp", ...
    // Destination page type for user redirection
    // type: string    
  page_type_id: "<page_type_id>",
    // e.g. 
    // type: string
  search_term: "<lowercased search term>",
      //e.g. "shir"
      //type: string
      // always contains the string that the user entered, not the autocompletion
  number_search_results: "<number of search results>",
      //e.g. 6
      //type: int
  search_term_completed: "<lowercased suggested search term>",
      //e.g. "t-shirts"
      //type: string
  search_destination: "<url>",
      // e.g. 
      // URL the user is sent to after submitting the search form
      // type: string
  suggested_category: "<category>"
      // ""
      // The user chose a suggested category
      // type: string
}

Search suggestion - no result

Search suggestion - No Results

Goal: Measure an unsuccessful executed search in the search suggestion

Gaining insights:

  • Identifying gaps in products and improving the search feature enhances user experience.
    • Zero results can be used for missing products or synonyms.

Frontend Trigger: When the user enters a few characters, and the API endpoint does not return any results with a delay of 1 second (maybe 0.5 seconds)

Data Layer implementation

The total number of search results should be returned, rather than the count of results shown on the initial search result page. If a search does not return any results, this should be represented by sending 0 as a value.

{
  event: "search", 
    // type: string
  event_action: "view suggested results"
    // type: string
    // e.g. click, submit
  content_name: "<page path>",    
    // e.g. "/"
    // document.location.pathname
    // type: string
  page_type: "<page_type>",
    // e.g. "homepage"
    // see page types below
    // type: string
  page_type_id: "<page_type_id>",
    // e.g. 
    // type: string
  search_term: "<lowercased search term>",
      //e.g. "pulli"
      //type: string
      // always contains the string that the user entered, not the autocompletion
  number_search_results: "<number of search results>",
      //e.g. 0
      //type: int
}

Search Result Page (SERP)

Zero results page

Goal: Measure a successfully executed search, to do a SERP (Search Results Page) analysis.

Gaining insights:

  • Top and bottom viewed products/brands
  • Amount of displayed results
    • Zero results can be used for missing products or synonyms
  • The number page_type within the search should be as low as possible, as SCAYLE follows a category-page-first approach.

Frontend Trigger: page load

Data Layer implementation

The total number of search results should be returned, rather than the count of results shown on the initial search result page. If a search does not return any results, this should be represented by sending 0 as a value.

{
  event: "search", 
    // type: string
    event_action: "view search results", 
    // type: string
  content_name: "<page path>",    
    // e.g. "/"
    // document.location.pathname
    // type: string
  page_type: "<page_type>",
    // e.g. "search results"
    // see page types below
    // type: string
  page_type_id: "<page_type_id>",
    // e.g.
    // type: string
  search_term: "<lowercased search term>",
      //e.g. "shirt"
      //type: string
  number_search_results: "<number of search results>"
      //e.g. 6
      //type: int
}

Search Result Page (SERP) - Sorting (optional)

Does not come out of the box. Each customer can have a unique sorting and filtering section. This custom event needs to be implemented when setting up the frontend work.

We do NOT recommend implementing sorting on SRPs because by default it should be sorted by relevance to the search term.

Sorting by e.g. price will give worse products in most cases as the search term itself isn’t factored into the sorting.

Sorting Options

Goal: Measurement of usage to determine general acceptance for sorting features.

Gaining insights:

  • Behavior on sorting options

Frontend Trigger: The user clicked on any sort option

Data Layer implementation

{
  event: "filter", 
    // type: string
  event_action: "", 
    // e.g. newest, price ascending, ...
    // type: string
  event_label: "-", 
    // e.g. -, blue, 36, 45-90, Nike, 
    // type: string
    // Maybe not necessary field
  content_name: "<page path>",    
    // e.g. "/"
    // document.location.pathname
    // type: string
  page_type: "<page_type>",
    // e.g. "search results"
    // see page types below
    // type: string
  page_type_id: "<page_type_id>",
    // e.g. "<category_id>"
    // type: string
  search_term: "<lowercased search term>",
      //e.g. "shirt"
      //type: string
  number_search_results: "<number of search results>"
      //e.g. 6
      //type: int
}

Search Result Page (SERP) - Filter (optional)

Does not come out of the box. Each customer can have a unique sorting and filtering section. This custom event needs to be implemented when setting up the front-end work.

Goal: Measurement of usage to determine general acceptance for filter feature and reveal the potential for adding new category pages, like "Leinenhemd" based on popular filters, e.g. category “Hemd” "material Leine."

Gaining insights:

  • What filter options or combinations are used
  • Combine category page or search term with filter categories

Frontend Trigger: The user clicked on any sort option

Data Layer implementation

Multiple value for event_action and event_label separated by ; (TBD if GA4 has a problem with specific delimiter), e.g. event_action: size; color and event_label: 36; blue

{
  event: "sort", 
    // type: string
  event_action: , 
    // e.g. size, brands, color, price, 
    // type: string
  event_label: "", 
    // e.g. -, Nike, 36, blue, 45-90
    // type: string
  content_name: "<page path>",    
    // e.g. "/"
    // document.location.pathname
    // type: string
  page_type: "<page_type>",
    // e.g. "search results"
    // see page types below
    // type: string
  page_type_id: "<page_type_id>",
    // e.g. 
    // type: string
  search_term: "<lowercased search term>",
      //e.g. "shirt"
      //type: string
  number_search_results: "<number of search results>"
      //e.g. 6
      //type: int
}