Tracking product views
By tracking product views, Engage can:
Trigger abandoned browse automations
Build audiences based on products of interest
Get improved product recommendations
Ways to track product views
Product views can be tracked through:
The Voyado tracking script
The tracking API
When tracking product views, the JavaScript method used is productview().
Features built on product views
The following features in Engage are enabled by the tracking of product views.
Abandoned browse
The site submits product views, which are part of a session, either via the tracking script implemented on the e-com site or through the tracking API.
Sessions without activity for at least 30 minutes are considered abandoned. If the session doesn’t contain any cart event, and the product views are connected to a specific contact, it will be sent to Engage. All other sessions will be filtered out. A session can only be sent to Engage once.
All product views sent to Engage are enriched with data from the product feed.
Engage then triggers the relevant automation, based on the specific trigger configurations. If automations contain email activities those can include dynamic product data enriched from the product feed.
Read more about abandoned browse here.
Products of interest
The site submits product views, which are part of a session, either via the tracking script implemented on the e-com site or through the tracking API.
Engage, using the recency, frequency and other patterns of product views from the last 90 days, calculates up to 25 products which each contact is probably most interested in, based only on their onsite behaviour.
These products are updated using a scheduled job and enriched by the article registry and can then be used in segmentation and as part of a scheduled selection in an automation.
Read more about products of interest here.
Product recommendations
If a contact has products of interest, these will be part of the data used to calculate personal recommendations in Engage. This means that their onsite behaviour (Products of interest) will be combined with all historical purchase and return behavior to present a set of personalized recommendations that can be used in emails.
Read more about Engage product recommendations here.
Abandoned browse automation requirements
The following are required so that an abandoned browse automation can be triggered:
The locale must match a product feed in Engage. Events without a matching product feed will be filtered out.
The SKUs must match products in the product feed (commonly “g:id”). If an SKU doesn’t match the feed, that particular product will not be included in the email. If no SKUs match the products in the feed, the automation won't be triggered at all.
Using the tracking script
Here is how to use the tracking script to track product views.
The productview() method
Invoke this method every time a product is viewed, such as on a product page, whether the user has been identified by the website or not.
Param | Type | Description |
|---|---|---|
*categoryName | string | Product category, e.g. “Men / Sweaters / Cardigan” |
*itemId | string | Mapped to SKU in Engage |
contactId | string | The Engage contact ID |
**locale | string | Format as defined by IETF language tag. Should match a product feed locale in Engage and is required for abandoned browse automations. |
Fields marked * are mandatory and ** is also mandatory when using abandoned browse.
This is what a call to the productview() method looks like:
va("productview", {
"categoryName": "Women / Armour / Greaves",
"itemId": "123XYZ",
"contactId":"afa7625d-2e97-4667-b4c1-ad3b01194bbb",
"locale":"sv-SE"
})Important points when tracking product views
Call productview() in all cases, regardless of whether the user is anonymous/identified or logged in.
All behavioral data can be used to create insights. A product view belonging to an anonymous user can be linked to a specific user after the user is identified.
Call productview() for all product views and with an itemId that matches SKU in Engage.
A product view can be a visit to a product page but can also be anything else that shows a selected product to the user, for example a “quick look” in a popup. The product/itemId will be matched against the SKU in Engage and enriched with product and transaction data. A product page can call productview() multiple times if it represents multiple SKUs.
Using the tracking API
It's possible to submit product views directly via the API instead of implementing the tracking script. Keep in mind that a lot of functionality that exists out-of-the-box when using the script has to be handled by the retailer.
Identification
It's important to identify contacts that enter the e-com from a link in a newsletter by reading the encrypted JSON that is sent in the link's query string. This contains the information needed to identify the contact. Only identified product views can be registered via API (since the contactId is required).
SessionID
A product view is part of a session, identified by sessionId, which is required for abandoned browse. This is handled automatically by the tracking script, but when using the API the sessionId has to be included in all calls.
Read more about the Engage REST API here or go directly to the Swagger page to try it out.
Use cases
When the user enters the e-com via a link from a newsletter
The user clicks a link to the e-com in an email newsletter sent out from Engage.
The link is decorated with vtid (contact ID).
The user views a specific product and invokes productview()
Populate categoryName with the current product category (e.g. “categoryName”: ”Computer accessories > Printers > Toners”)
Populate itemId with the current product SKU (e.g. "itemId": "549852″)
Populate locale based on the current language/market of the site (e.g. “locale“: “sv-SE“)
Populate contactId with the users contact id from Engage, vtid is used as fallback
When the user enters the e-com unidentified
An unidentified user browses into the e-com
The user views a specific product, invoking productview()
Populate categoryName with the current product category (e.g. “categoryName”: ”Computer accessories > Printers > Toners”)
Populate itemId with the current product SKU (e.g. "itemId":"549852″)
Populate locale based on the current language/market of the site (e.g. “locale“: “sv-SE“)
Do NOT populate contactId
When the user enters a product display page (PDP) with multiple SKUs/colors/variants
Avoid sending a productview for each size when the customer visits a product page and instead send a product view when a specific size/colour/variant is picked.
If you want to track the view no matter the variant, then send a random SKU from the PDP, or, as a last resort, send all variants.
Caution
If all variants are sent, you risk triggering abandoned browse emails containing many variants of the same product.