7x common tracking errors of the e-commerce event "view_item"
Watch out for the following common errors when tracking view_item events in your e-commerce business.
Despite the importance of view_items in personalization and analytics use-cases, many e-commerce teams under-estimate the data tracking of this event. That is unfortunate. Low quality view_item event tracking can lead to:
Poorer analytics: data, analytics and reporting can’t be achieved because the some attributes are missing or have wrong values being tracked
If the event or key event attributes are not tracked at all, some use-cases stop working and others would work sub-optimally resulting in revenue loss.
Realizing too late: when the e-commerce marketing teams would like to implement a personalization, to do a certain analysis or report end up realizing they have something missing in their view_item event data architecture that makes it impossible
Navigating the implementation and long-term maintenance of 'view_item' tracking can be challenging. In our collaboration with over 25 e-commerce teams spanning 6 years, we've identified 7 common challenges faced during the implementation of 'view_item' events. In the article below we describe these challenges and our recommendations on how deal with them.
1. Commonly “missing” view_item event attributes:
Each e-commerce divides and classifies their products based on different product attributes. Depending on what the e-shop is selling, the products can often be grouped based on category, color, size, material, author, etc. It is important to define as a team which of these attributes are important to the business from reporting, marketing and personalization perspectives.
Typically this is often underestimated. As a result, sometimes not all useful product attributes in view_items events are tracked. Here is a list of the item attributes we came across. If an attribute is relevant to your product selection and is not currently tracked, consider having this information also in your view_item events.
item_category
item_subcategory
item_gender
item_size
item_color
item_material
item_collection
item_volume
any other item_ relevant classification for your product selection
web_discounted_percentage
reviews_count
avg_item_reviews
2. Product Categorization Errors
Sometimes products and their attributes are tagged with the wrong values in the back-end. This results in the wrong view_item.category values tracked. It can happen that two products, which are just variants of the same products end up having different classifications in category attributes. This kind of issue would negatively affect analytics use-cases and category-affinity personalization. They would be included in the wrong categories in Reporting (example screenshot below) and could cause unexpected issues in category-affinity personalization.
Typically, this needs to be rectified in the back-end product catalog directly.
Example of color variants having different view_item. category values
Black version of a Bed Frame “Rozali” is classified in the “Bedroom” category
White version of the same Bed Frame “Rozali” is classified in the “Living Room” category
Example of packaging variants having different view_item. category values:
330g version of the Organic Nougat Cream is classified as a “Creams and Butter” as the category.
3x330g version of the same Organic Nougat Cream is classified as a “Value-deal-packaging” as the category
3. Product Categorization is not the URL breadcrumb
A common error, is to track the product’s page URL breadcrumb as the categorization values of the products. The problem with this method is that products can be accessed via different breadcrumb paths. This is especially true if the e-shop utilizes custom landing pages and custom category pages such as Sales, Special Edits, Holiday pages, etc. This occurs when the values for the categorisation are being pulled from the Javascript values that refer to the URL breadcrumb of the page.
As you can see in the screenshot below, in this instances products are being categorized as being a “Sale”, but viewing the same product through the Men’s page would track the category_1 attribute as “Men”, category_2 attribute as “Top”, category_3 attribute as “Shirts”
This kind of category value tracking makes the attribute unreliable to work with.
We recommend following these rules when designing the logic of your product categorization:
each product belongs to a single category, each category name is unique
each product belongs to a single subcategory1, each subcategory1 name is unique
each subcategory1 is unique and only belongs to a single category
each subcategory2 is unique and only belongs to a single subcategory1 (and so on if you have more subcategories)
Special category groupings like whether a product was on sale, belongs to a certain group of products for other commercial or strategic reasons, should be tagged via the use of different event attributes not called “category”.
4. Not tracking when a customer selects a size
Many e-shops forget to track an important customer interaction on the product page. Especially on fashion websites there are variants of products that the customers must select before they add the product to the cart. It is very useful to track this selection of a product variant as an event in order to capture customer preference for a given variant (size / color).
5. Not Tracking all relevant touchpoints
A common tracking error is to not make sure that every touchpoint that allows a user to view a product should be tracked upon the user loading the page.
Do you have unconventional paths or iframes on your site where one can view products directly from a collections page or a homepage?
In the example screenshot below, no view_item is tracked when a product is viewed in a pop-up frame, that opens up when a customer clicks on a Homepage Hero Placement.
6. Double-tracking events
We have come across situations where, e-commerce teams were tracking view_item events from multiple tracking codes. This would result into a single loading of a product display page generating more than one view_item at the same time (or very similar times).
This causes issues. It inflates any reporting that makes use of view_items. It would cause unexpected behavior with the Abandoned Browse automation.
The reason such duplication of event tracking can happen in the first place is that a single e-shop can have many different software that are affecting the final rendering of the code for the final user. Consider that an average e-shop may have:
Active Google Tag Manager
Active CDP Tag Manager
Website Code Itself
Back-end options
All of these code touchpoints could track a view_item event from a page_load and assign in to the correct customer in your customer database. For this reason we recommend “hard-testing” the user journey - meaning having someone on your team identify their cookie and see what exactly was tracked when they loaded a product display page.
Additionally, we recommend keeping a record of where the code relating to the event tracking is stored so when teams are making updates to data tracking (or anything goes wrong with the existing implementation) the team can quickly find out what code and where needs to be edited.
7. Issues resulting from having different language and currency domains
E-commerce shops that operate in multiple markets have unique data issues resulting from hosting multiple domains. The product names, category names prices and currencies change between domains for the same products. This is a challenge from a reporting perspective. What if you would like to combine product data from all domains in one view to consider what is the best selling product across all domain?
Therefore, if you function across multiple language domains, we recommend to track “global” attributes that describe the product. Imagine an e-commerce furniture company that has a German, Hungarian and Romanian store. This is a product page for one of the products in their Romanian domain.
We would recommend to also track a “global” attribute for key item attributes like “item_title”, “item_category” and any other attributes that are text-based and have language variations, like this:
category_1_HU - Nappali bútor
category_1_RO - Mobila living
category_1_Global - Living Room
If you function across multiple currency domains, we recommend to track “global” price attributes, like this:
price_RO_lei - 2,072
price_HU_forint - 161,500
price_global_eur - 417
Tracking document template
We have also created a template tracking document for you, which defines the structure for view_item and view_item_variant events according to best practices. You can access the document here. Feel free to make a copy for your internal use.
If you found this post valuable…
We hope you found value in this article. If you did, we'd appreciate it if you subscribed (at no cost!) to stay updated with our latest publications
.