Skip to main content

How can I automatically remove purchased items from a customer's wishlist?

Updated

A wishlist lets customers save products they may want to buy later. After a product is purchased, you often want it automatically removed from the wishlist.

This article shows one way to remove purchased items from a wishlist using a scenario. You can also use this as a pattern for similar use cases in your own project.

Customer property for wishlisted items

First, you need a customer property where wishlisted items are stored. In this example, we use a customer property named wishlist with the data type set to list. Each value in the list should be an item identifier (for example, a product ID).

If you already have a customer property where you store wishlisted items, you can reuse it. Just make sure the items are stored as a list.

Choosing the event and attribute

Next, choose the event that represents a purchase. It is very common to store item IDs or other item identifiers in the purchase event.

Our approach works whether your event contains:

  • A single purchased item ID, or
  • Multiple item IDs stored as a list

The important requirement is that the value is stored in an event attribute of type list (recommended) or string. In the example below, we use a list attribute called product_list. Replace this with the attribute you use in your project. Make sure not to use an integer type for this attribute when storing IDs, as that can cause issues.


Set up scenario logic

You can remove purchased items from the wishlist with a simple scenario using an On event trigger. In this example, we trigger the scenario on the purchase event.

  1. Create a scenario with an On event trigger using your purchase event.
  2. Add filter conditions if needed (optional)
  3. Add a Set attribute node.
  4. In the Set attribute node, use the following Jinja code:
{# define variables #}
{% set wishlist = customer.wishlist | default([]) %}
{% set purchased_items = event.product_list | default([]) %}
{% set result = [] %}

{# loop through items in wishlist #}
{% for item in wishlist %}
 {% if item not in purchased_items %}
   {% append item to result %}
 {% endif %}
{% endfor %}

{# save updated wishlist #}
{
 "wishlist": {{ result | json }}
}

 

 

The logic of this code is as follows: 
First, it takes all item IDs from the customer's wishlist property and stores them in the wishlist variable. Then it does the same for the purchased item IDs from the event, saving them in the purchased_items variable. It also creates an empty result variable, which will hold the final list of items that should remain in the wishlist.

In the for loop, each item from the original wishlist is checked: if the item is not present in purchased_items it is appended to result. As a result, result contains only the items that were originally in the wishlist but not included in the purchase event, and the wishlist customer property is updated with this filtered list.

Conclusion

This approach will work as expected as long as all of the prerequisites above are met:

  • Wishlisted items are stored in a list-type customer property.
  • Purchased items are available in the event with a compatible attribute.

You can also use a different event (not only purchase) as long as it has the same attribute data types as in this example.

It is also possible to track one item per event, but this requires sending each customer event with a slight delay so that wishlisted items are correctly updated based on the value from the previous event. This approach isn't ideal because you can't predict how many customers will enter the wait nodes. As a result, too many customers may be routed to a single wait node, which does not align with our scenario best practices. For this reason, the most reliable and recommended approach is to use a single event that tracks all items the customer purchases and use that event as the trigger for this solution.

Related articles