{"id":23519,"date":"2021-04-01T13:11:45","date_gmt":"2021-04-01T11:11:45","guid":{"rendered":"https:\/\/www.deptagency.com\/?post_type=article&p=23519"},"modified":"2023-07-20T09:57:17","modified_gmt":"2023-07-20T07:57:17","slug":"the-product-list-performance-in-google-analytics-improved-reliability-through-actual-product-impressions","status":"publish","type":"article","link":"https:\/\/www.deptagency.com\/en-dk\/insight\/the-product-list-performance-in-google-analytics-improved-reliability-through-actual-product-impressions\/","title":{"rendered":"Improved reliability through actual product impressions"},"content":{"rendered":"
\n\t\n\t<\/svg>\n\t\t\t\n\t\t\tBack to all articles\t\t<\/span>\n\t\n<\/a>\n\t\tImproved reliability through actual product impressions\t<\/h1>\n\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t<\/picture>\n\t\n\t<\/div>
\n\t\n\t
\n\t\t\t\t
\n\t\t\n\t\t\t<\/div>\n<\/div>\n\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\tDate\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t1 April 2021\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t<\/div>\n<\/div>\n\n
\n\t
\n\t\t\n\t\t\t\t\t
\n\t\t\t\t\n\n\t\tThrough the standard implementation of the enhanced e-commerce tracking, data in the Product List Performance Google Analytics are inflated. This is because many users do not always scroll down until the bottom of long pages such as the category or search results pages. Regardless of the user\u2019s behaviour, the standard implementation sends the entire e-commerce impressions object contained in the dataLayer to Google Analytics. This inflates the product list views metric making the report less reliable. However, a very useful application, of the recently added element visibility trigger in Google Tag Manager, enables a solution capable of sending product impressions only when the products are actually displayed on the screen.\t<\/h2>\n\n\n\t\tThe issue that inspired this article\t<\/h2>\n\n\n\t\tWhile working on a project for one of our clients at DEPT\u00ae, we noticed that on some pages the hit to Google Analytics was not sent. Yet, the pageview tag was firing correctly in Google Tag Manager according to the preview window. This unexpected behaviour, however, did not affect all the pages: from the home page or the product detail page for instance, the hits were sent correctly.\t<\/p>\n\n\n\t\tWhen investigating the issue, we noticed that the pages containing all the products of the site, e.g. the category page or the search results page, were the only ones affected.. Analyzing the Google Chrome console tab through the Google Analytics debugger browser extension, we eventually found out that in one of these pages the hit payload exceeded the maximum allowed size of 8192Kb.\t<\/p>\n\n\n\t\tThe next step was to find the reason for such a large payload, therefore we inspected the hit and discovered a long list of product impressions details. A single category page or search result page was displaying more than 50 products causing the hit payload to exceed the limit.\t<\/p>\n\n\n\t\tA solution to reduce the hit payload size\t<\/h2>\n\n\n\t\tTo avoid any loss of data we had to find a way to split the large pageview hit payload into several smaller units. To accomplish this goal we first deactivated the enhanced ecommerce features from the pageview tag and second we separated each product impression through single event tags so we basically created more hits but with lighter payloads.\t<\/p>\n\n\n\t\tWe decided to use one of the recently added features in Google Tag Manager \u2013 the element visibility trigger \u2013 and apply it to this case. Via this trigger type we could send product impressions in single (or grouped) Google Analytics event tags that fired only when the products are displayed on the screen. In doing so we were be able to achieve two goals in one action:\t<\/p>\n\n
    \n\t
  • we reduced the hit payload size so we overcame the pageview hit being dropped<\/li>
  • we also improved the Product List Performance report in Google Analytics as this solution sends only actual product impressions details<\/li><\/ul><\/div><\/div>\n\n\n\t\tIn order to accomplish both goals, we needed to follow several steps divided in three main parts: (1) resolving the page view hits, (2) building the product impressions and (3) sending them via Google Analytics events.\t<\/p>\n\n\n\t\tResolving pageview hits\t<\/h2>\n\n\n\t\tSince the enhanced e-commerce features were responsible for the exceeding hit payload size we had to disable them from the GA pageview tag when firing on category and search result pages. To do so we had to modify the all pages trigger associated to the normal pageview tag to filter out the long pages. So we created a new trigger:\t<\/p>\n\n
      \n\t
    • Trigger type: Page view<\/li>
    • Fires on: some pages<\/li>
    • Filter: {{pageType}} does not equal to category
      We used the {{pageType}} variable available in the dataLayer used for both category and search result pages<\/li>
    • Name:\u00a0Pageview \u2013 All pages except category pages<\/strong>
      Once created, we connected it to the normal pageview tag. We then renamed the tag to highlightthe new firing conditions:\u00a0UA \u2013 Pageview \u2013 all pages NO category pages<\/strong>.<\/li><\/ul><\/div><\/div>\n\n\n\t\tOnce we had deactivated the normal Google Analytics pageview tag from the category pages we needed to create a new tag, specifically for this page type, having enhanced e-commerce features disabled so not lose any page view data. So, we made a copy of the tag\u00a0UA \u2013 Pageview \u2013 all pages NO category pages<\/strong>\u00a0and brought the following modifications:\t<\/p>\n\n
        \n\t
      • We checked Enable overriding settings in this tag<\/li>
      • In More settings > E-commerce > Enable Enhanced E-commerce Features, switched to False<\/li>
      • We removed the trigger associated to the tag and clicked on the + icon to create a new one<\/li>
      • We created a new trigger having the opposite filter, so: Page view on pages where {{pageType}} equals category<\/li>
      • We named the tag\u00a0UA \u2013 Pageview \u2013 category pages only<\/strong><\/li><\/ul><\/div><\/div>\n\n\n\t\tActual product impressions build up\t<\/h2>\n\n\n\t\tAfter resolving the hits for the pageviews we needed to create the solution for the actual product impressions. To do so, we wanted to apply the element visibility trigger type and make sure to fire events only when the products were displayed on the screen. So, we started to build the following one:\t<\/p>\n\n
          \n\t
        • Type: Element visibility<\/li>
        • Method: CSS Selector<\/li>
        • Selector: .product-box
          Each product was contained in a\u00a0HTML tag type having a specific class having name product-box. It is preceded by the period (.) to specify the class in CSS notation<\/li>
        • When: once per element
          We wanted to consider all the products in the page<\/li>
        • Minimum percentage: 80%
          The minimum visible percentage can vary according to one\u2019s own idea of product impression. We considered that 80% of the displayed product can be seen as a full impression<\/li>
        • Observe DOM changes: unchecked<\/li>
        • Minimum time on page: unchecked
          The appearance of the element on the screen is not a DOM change and no delay was needed<\/li>
        • All visibility elements
          As we did not want to filter out any product we made sure All visibility events was selected.<\/li>
        • We named it Element visibility \u2013\u00a0Product selector<\/strong><\/li><\/ul><\/div><\/div>\n\n\n\t\tThe second step of the impression build up phase consisted in fetching the impression details for the single products. To do so, the large dataLayer had to be \u201csliced\u201d in parts and sent to Google Analytics in separate event tags through some custom JavaScript code injected in Google Tag Manager. The logic of the script was: for each product \u201cseen\u201d by the element visibility trigger then push a specific custom event and slice the equivalent product impression details from the entire dataLayer object.In Google Tag Manager, we first created a data layer variable to store the entire dataLayer object from the page: ecommerce.impressions and we named it\u00a0DLV \u2013 Ecommerce \u2013 Impressions.<\/strong>\u00a0Then we built the script in a custom HTML tag.\t<\/p>\n\t\t\t<\/div>\n\t\t\t<\/div>\n\n\t\n\t