By using this trigger, you can respond to your customers' behavior observed on your website.
To use the Web Extend Event trigger, the Web Extend data collection scripts need to be implemented on your website.
You can choose from the following default Web Extend events by double-clicking the Web Extend Event trigger:
- Purchased event
- Viewed product page event
- Viewed category list event
- Updated cart event
Notes:
- Contacts will trigger Interactions programs starting with the Web Extend Event trigger if the contact is identified and their customer ID or email address is sent properly by the
setCustomerId
orsetEmail
command. - You can filter for Mobile SDK events by using the
EmarsysSDK
value of the Web Extend attributeUser agent
in Interactions. In the following example, we have selected the Updated cart trigger event and added a Decision node to the program using the Trigger attributes template that contains the following attribute criteria:User agent
containsEmarsysSDK
. In this case, only those contacts will meet the specified criteria who triggered the Updated cart event and its payload contains theUser agent
EmarsysSDK
.
Total cart value attribute
The Total cart value attribute is available within the Updated cart and Purchased Web Extend events. You can use this attribute for:
- Fine-tuning incentives In abandoned cart campaigns.
- Sending special post purchase campaigns for orders above a specific value.
How is this attribute calculated?
We add up the price of all items in the cart (items are NOT multiplied by their quantity).
The Decision node in the following example targets only customers with a Total cart value of at least €300.
Adding product detail-specific conditions
You can define conditions using any product detail from your product catalog to fine-tune real-time engagements with your customers. For example, product detail-specific conditions come in handy when you would like to distinguish a brand (e.g. because different marketing guidelines apply to it) from another one, then you can create conditions based on product details instead of keeping all the exact item IDs in mind.
You can use product details when defining conditions for the following Web Extend events:
- Viewed product page
- Purchased
- Updated cart
The item IDs within the Web Extend events are matched with product details in the product catalog when Emarsys evaluates the decision definition. In the case of historical decisions (e.g. when filtering your contacts’ past purchases), Emarsys checks the most up-to-date details of the product instead of the attributes that reflect the item’s certain attributes (e.g. price) when the event was triggered in the past. For instance, when defining conditions based on the product’s price, you can use either the price attribute contained within the event that reflects the item’s price when the event happened or the current price.
FAQ
How can I differentiate attributes within the event from details in the product catalog?
The categories listed in the drop down help you distinguish attributes within the event from product details in the product catalog:
- Attributes within the event are listed under Single-value attributes.
- Product details in the product catalog are listed under Product data fields.
Which price attribute does Emarsys use for calculating the Total cart value?
Emarsys uses the price
attribute within the event for calculating the Total cart value attribute. The Total cart value reflects the state of the product when the event happened. You can also use this value for personalization.
How does Emarsys handle fields such as category and brand?
Fields such as category
and brand
can have multiple values in the product catalog. Interactions merges these values into a single string and you can use contains-type searches without defining exact values (e.g. such fields might contain the pipeline character “|
”) with the following operators:
- contains
- contains any of
- contains all of
- contains none of
For example, if you would like to search for sessions where visitors browsed a pair of jeans on sale, you need to configure your Decision node as follows:
Use cases
Sending different campaigns to contacts interested in a specific brand:
Suppose that you have multiple brands and different incentive guidelines apply to a particular brand. Incentives are often used in abandoned use cases or post-purchase campaigns. In such cases, you can check whether or not customers have added at least one item that belongs to a specific brand. Contacts will continue their journey as follows:
- Those who meet this condition continue their journey on the Yes path and receive a special campaign.
- Those who do not meet this condition continue their journey on the No path and receive another campaign.
This is how the Decision splitter node used in this program looks like:
Sending real-time Web Channel or in-app messages to contacts who browsed highlighted categories (cross-sell):
Suppose that you would like to send a Web Channel campaign to promote your leather care product line to contacts who browsed an item that belongs to the leather category. In this case, the Decision node looks like as follows: