• Abandoned cart campaigns - Using custom tags help you better understand the reasons why your customers abandoned their carts. For example, by using the visited_checkout_page tag containing the attribute shipping_cost, you can check whether customers abandoned their carts due to the relatively high shipping costs. As a result, you can create abandoned cart campaigns that drive purchases by offering free shipping. Another possible scenario is that after navigating to the payment site, customers do not complete their purchases because they are not sure if they can pay safely on your site. In this case, you can reassure your customers that the available payment methods on your site are absolutely safe.
• Abandoned check - out page campaigns 
• Abandoned search campaigns 
• Launch Web Channel campaigns based on custom website behavior - For instance, when a customer finished watching a video or started to download a white paper.

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:

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:

You can target customers who met the specified requirements when they triggered the event the last time by using this template. For example, you can reach contacts who fulfilled the following criteria when they triggered the specific event the last time:

• placed orders above €100 (in this case, customers who purchased something for 99 the last time will be filtered out).
• finished their running workout and ran at least 10 km (in this case, contacts who ran 9,5 km the last time will be filtered out).

The following example shows you how the Last time the event happened template works.

Suppose that we would like to target only those customers who ate chocolate ice cream the last time at an ice cream parlor.

Each time a customer adds an entry to their food log, we send the Mobile event called food_log_lunch_today containing the following attributes:

• food_type
• food_taste
• food_location

To make sure the Decision node returns exactly those events that we need, we have to define the conditions in two steps:

1. Configure the Decision node as follows:

a. Set the source to Mobile and select the event food_log_lunch_today.

b. Add the following Event criteria by clicking Add Condition:

- event_attributes.food_type contains ice_cream

- event_attributes.food_taste contains chocolate

2. Add the following attribute to the Latest event criteria: event_attributes.food_location contains ice_cream_shop

Event - Here you can specify the following values:

• Source - The trigger source.
• Event - The trigger event.

Event criteria - Contacts will continue the journey if they had an event matching all event criteria. If you add multiple attributes, they are linked by the AND operator. Here you can configure the following fields:

• Attribute - Events will be filtered based on the selected attributes. For more information, see Attributes.
• Operator - For more information, see Operators.
• Value

• Add item conditions - You can add item conditions to your Event criteria if the selected event contains product lists (arrays). For more information, see Adding item conditions.

Latest event criteria - Contacts will continue the journey if their latest event matches these criteria. If you add multiple attributes, they are linked by the AND operator.

This feature comes in handy, for example, when:

• You have an ongoing promotion for 4 exclusive items and you would like to see whether customers have purchased any of these products (based on their item_id attributes), so that you can send them an exclusive post-purchase campaign with tips and tricks.
• You would like to know whether customers have added at least one item to their carts the price of which is over €100.

Here you can see how item conditions work. In the following example, we would like to target customers who purchased more than two exclusive items in the last 30 days with the following conditions:

• the price of each product was over €60,
• the total cart value was over €300.

1. Select the Event happened template in the Decision node.
2. Choose the Web Extend source and the Purchase event, then click Add condition.

3. Select Purchased items under Item lists (arrays).

4. Select the contains more than or exactly operator and set it to 2 item(s).

5. To add further attributes of the purchased product to the attribute criteria, select the Add item conditions checkbox.

6. Define the products’ item_id and price attributes.

7. Add another condition:
   1. Select Total cart value under Single-value attributes,
   2. Choose the operator is more than or equals and set it to 300.

8. Specify the additional criteria as follows:
   1. Set the Number of events to more than or exactly 1 time(s) and
   2. Set the Timeframe to In the last 30 days.

Here you can see how array-specific operators work with the Updated cart Web Extend event.

In the examples below we will refer to the following case:

Suppose that a customer has added five items to the cart. Two products were more expensive than the others: each of them cost at least €60.

• contains exactly - The cart contains exactly 2 items and those have to meet the defined conditions. The customer mentioned in the example above has added 5 items to the cart, so they cannot continue the journey.

• contains more than or exactly - The cart contains more than or exactly 2 items and those have to meet the defined conditions. The customer mentioned in the example above can continue the journey because they have added 5 items to the cart and the price attribute of 2 products matches the defined criteria.

• contains less than or exactly - The cart contains less than or exactly 2 items and two of them meet the defined conditions. The customer mentioned in the example above cannot continue the journey because they have added 5 products to the cart.

• does not contain any items - In this case, you cannot add item conditions (i.e. the cart should be empty). The customer mentioned in the example above cannot continue the journey because they have added 5 items to the cart.

• contains items that all match item conditions - In this case, each item (regardless of the number of products in the list) has to meet the defined criteria. The customer mentioned in the example above cannot continue the journey because they have added 5 items to the cart but only two of them match the item conditions (i.e. the price of each product is at least €60).

The recommended operators are automatically detected based on the attribute type. All the recommended operators that belong to the detected attribute types are listed if you click the Operator field. If you have entered an attribute manually, then all operators are listed in the drop-down.

Examples

The following examples show you how some of the operators work:

• between 1 and 5 - includes the values 1 and 5 as well,
• at most 10 - includes values that are smaller than or equal to 10, 
• at least 5 - includes values that are greater than or equal to 5.
• is one of the following (text)/is not one of the following (text) - the defined values should exactly match the values contained by the incoming events, as the underlying text operator is "equal" (i.e. the received value should be identical with the defined value) and not "contains". The listed values are linked by the OR operator. For example, if you expect to receive events with the attribute weather that could contain the attribute values heavy rains and mostly sunny, then the values specified in the Decision node have to be identical with those values. If you specify the values rain or sunny in the Decision node, then the incoming attribute values heavy rains or mostly sunny will not fulfil the conditions set by this node and as a result, this decision will not be taken as expected.

For example, you can use the Participation check node if you have a refer-a-friend campaign in which you would like to offer a more valuable incentive after the first friend of a contact joins the campaign and a less valuable incentive after another friend of the same contact joins the campaign.

Such a program would look like as follows:

In the example above, the Frequency of the Participation check node is set to Only once ever. As a result, the contact can only proceed along the Yes path when the event happens for the first time and this contact receives the 40% discount only once. Each time the contact triggers the same event again, the contact will be directed to the No branch and will receive the 20% discount.

The Participation check node may come in handy if, for example, you have a delivery update program and you would like to send a voucher based on the value of the order with varying frequency after the purchased product is shipped.

Such a program would look like as follows:

In the example above, the Decision splitter node checks if the value of the order made by the customers is above or below 80€ and the Participation check node ensures that: 

• Those contacts whose order exceeds that value will receive a 20€ voucher only once in every 2 months.
• Those contacts whose order value is below 80 will receive a 10€ voucher only once in every 3 months.

If you have a promotion that you would like to show your contacts who finished their workout under different circumstances, then you can use the same Participation check node settings within the same program. For example, let’s imagine that you would like to:

• Use the same trigger event in both cases but a different campaign will be displayed depending on the attributes.
• Advertise different products depending on the temperature for contacts:
  • Who ran when the temperature was above 25 °C.
  • Who ran when the temperature was below 10 °C.
• Display the campaign every 30 days regardless of the temperature.

Such a program would look like as follows:

This is how the Participation check node would look like:

You can use the same Participation check node settings in multiple programs in the following cases:

• Abandoned use cases: You can use the same Participation check settings in multiple programs to make sure that a contact receives only one abandoned campaign a week to avoid marketing fatigue or unsubscription. In this case, you can insert the same Participation check node (called Abandoned use cases in the example below) before the channel nodes in your abandoned browse, abandoned cart and abandoned checkout page campaigns. This is how such a Participation check node looks like:

• Sending a valuable voucher once in a month: You can use the same Participation check settings referring to the same limited audience in multiple programs to make sure that a contact can only receive one valuable voucher once in every 30 days.
• Back in stock and price drop campaigns: You can use the same Participation check settings in multiple programs to make sure that your contacts only receive either the back in stock or price drop campaign a week.

Here you can see the following options:

• Frequency: You can define how often customers can proceed along your program. You can choose from the following options:

◦ Only once ever - Contacts will be able to proceed along the Yes path of your program only once.

◦ If the following time has passed since this contact last proceeded along the Yes path - Contacts can proceed along the Yes path of your program again after the specified time period.

• Make this check available in other programs - You can save your Participation check settings and the audience referred to by this node to make them available in other programs or you can use an already existing configuration. You can choose from the following options:

◦ To create a new Participation check, proceed as follows:

1. Switch the Make this check available in other programs toggle and select Create new from the drop-down.

2. Give it a name, then click OK.

◦ To use an already existing Participation check configuration, proceed as follows:

1. Switch the Make this check available in other programs toggle and select an existing Participation check you would like to use from the drop-down.

2. Once you are ready, click OK.

You can only edit the Participation check node in active programs if you have previously activated the Make this check available in other programs switch. Otherwise, you can only edit the Participation check node after freezing your program.

You can modify the following settings in the Participation check node:

• You can change the Frequency from If the following time has passed since this contact last proceeded along the Yes path to Only once ever. In this case, the Interactions program stores the timestamp when the contact passed through the Yes branch the last time, so those contacts who have already proceeded along the Yes path cannot pass it through again if you set the Frequency to Only once ever.
• You can change the Frequency from Only once ever to If the following time has passed since this contact last proceeded along the Yes path. In this case, the Interactions program compares the current timestamp to the one that was saved when the contact passed through the Yes branch the last time (while the Frequency was set to Only once ever).

If, for example, a contact proceeded along the Yes path on July 4 when the Frequency was set to Only once ever, and you set it to If the following time has passed since this contact last proceeded along the Yes path after 7 days, then:

◦ A contact who proceeded along the Yes branch on July 4 can pass it through again on July 11.

◦ A contact who passed through the Yes branch on July 19, can only proceed along that path again on July 26.