It’s possible to configure the Abandoned browse trigger in many different ways. This article will go through a few examples and highlight some best practices.
Sessions
The Abandoned browse trigger will in general act based on a single session and the product views that occurred in it. If the Voyado script is used a session is kept alive as long as the user keeps the tab or browser open. If the tracking API is used the e-com decides how long a session is kept open. It’s the abandonment of the single sessions that will trigger the automation. But, it is possible to link multiple sessions for a single contact together by using labels, this is further explained under “Labels” in this article.
As an example, here are two made-up sessions and how different triggers would work with them. All entry criteria are not included in the example below, for full documentation regarding this, see this article.
Triggers
If no additional entry criteria are added to the AB-trigger all sessions that match the bullets below will start the automation:
- Without activity for the last 30 minutes
- No product was added to the cart during the last 24 hours
- Those that are identified with contactID
- The SKUs in the session can be found in the product feed
- Those that haven’t already been sent to the trigger (a session can only trigger the automation once)
Restrict the trigger
Some common entry criteria that are used to restrict when the abandoned browse automation should be triggered.
Views on session level
It’s often the case that you want to restrict the automation only to act when the sessions contain a certain amount of product views to not spam bouncing visitors and instead target engage ones. Keep in mind that this doesn’t consider multiple sessions, but the number of views within a single session. If you want to link multiple sessions take a look for the “Labels” section here.
In the example below, the outcome would be that Session 1 would trigger the automation since it has two product views from the same SKU, but session 2 would not.
Views on product view level
Views can also be applied on the product view level, in that case, it’s product views of a specific product/SKU. Could come in handy if you want to trigger the automation when a visitor has visited the same product more than X times in the same session.
In the example below, the outcome would be that Session 1 would trigger the automation since it has two product views from the same SKU, but session 2 would not.
Brand
The brand of a product view can be used to restrict which sessions that trigger the automation. If this condition is added it means that at least one product view in the session has to be of a product tied to that brand based on the product feed. This can come in handy if you want an automated way to campaign around a specific brand, maybe focusing less on the specific products and more curated content based on the brand.
In the example below, the outcome would be that Session 1 would trigger the automation since it has at least one product view tied to the brand Acme Corporation, but session 2 would not.
Combined conditions for a product view
On the product view level, multiple conditions can be grouped like:
- 2 product views tied to the brand Acme, or
- 2 product views tied to the SKU 456
- 3 product views tied to Web category X
The reason for combining product views for a specific SKU and attributes like category or brand is in case you want to be more cergical in your automation. The reach will be smaller but more engaged.
For the conditions to be linked they must be included in the same group, here are two examples.
In the first one, conditions are linked in the same group.
The outcome would be that Session 1 would trigger the automation since it has one product view tied to the brand Acme Corporation, but session 2 would not.
In the second example, conditions are not linked in the same group but are added as two separate criteria.
The outcome would be that Session 1 would trigger the automation since it has one product view tied to the brand Acme Corporation, but session 2 would not.
Top web category
The Top web category is an aggregation of the product views in the session, where the web category with the most views is named the Top web category. The web category is included in the product view event that is sent to Voyado by the site. The web category can instead of a trigger condition be used in a value split to handle multiple categories in the same automation. Voyado also enriches each product view with the Main category from the product feed. This category type is not aggregated.
The use case for the top web category is similar to the brand attribute. For example, an automated way to campaign around a specific category. Focusing less on the specific products browsed and more curated content based on the category.
In the example below, the outcome would be that Session 2 would trigger the automation since the Top web category for that session is Pants, but session 1 would not be triggered since the Top web category, in that case, is Shoes.
SKUs on the session level
It’s possible to restrict the trigger to only accept sessions with a certain amount of different SKUs within that session.
In the example below, the outcome would be that none of the sessions would trigger the automation since neither of them has more than two different SKUs. Session 1 has 3 product views but two of them have the same SKU.
SKUs on the product view level
A SKU can also be added as a condition on the product view level. In that case, the session has to contain at least one product view of the SKU added to the trigger. If this setting is used you might want to send communication curated for the specific SKU rather than the recently viewed products in general.
In the example below, the outcome would be that both sessions would trigger the automation since both contain the SKU 456. In case the start frequency for the automation is limited to for example 1 per 30 days and the sessions happened within that timeframe only Session 1 would trigger the automation.
Comments
0 comments