I made this Abandoned Cart flow a while back to the specifications that Klaviyo mentions, as well as fixing a little bug of the $value needing to be Price instead to register the items.
The issue I’m seeing now is that the overwhelming majority are going into the trigger split “PriceAmount is less than 59.94”, aka The Low Value Cart. It’s over 99%, which seems incorrect. However, a few have gone into the High Value Cart, so I know it must be working in part. What could be causing this huge shift? I have screenshots to show.
One theory I have is that people might be triggering with Low Value initially, come back before the 1 Hour Time condition is up and add more to equal higher value, but it’s actually triggering the additions as a new low value. Is that possible? If that’s the case, is there a way to fix that?
What else could be going on here?
Thanks so much for any help!
Best answer by Bobby
@caitlinlmh thanks for sharing the additional information there.
My hunch is that it might require a Shopify developer to reconfigure the Added to Cart event so that the $price value of the event reflects the cart total.
I understand you mentioned the below in your original post:
I made this Abandoned Cart flow a while back to the specifications that Klaviyo mentions, as well as fixing a little bug of the $value needing to be Price instead to register the items.
In this Added to Cart tracking snippet section, an example event payload is shown. Here, the $value property reflects the total cart value while an additional top-level property of "AddedItemPrice" displays the item price.
I’ve shared the above doc with several clients’ developers who have built this enhanced Added to Cart tracking. A benefit is that each subsequent event during a user’s session will include existing items added to cart in the “Items” array. Thus, allowing all items to display in the Abandoned Cart emails, similar to how they all display in the Abandoned Checkout emails, triggered by the Checkout Started event.
Would the above seem like an ideal approach, @caitlinlmh?
Appreciate the detail you included in your post. I’ll try to help out here.
Out of curiosity, is your “Added to Cart” event set to only include one item in each event? Or, if people add multiple items to cart during a session, do subsequent “Added to Cart” events include previously added items during their session?
The reason I ask is because the default behavior for this event is the former. So, if the majority of the items you sell are under the $59.94 threshold, it would be expected that only individual items above that threshold would go down the “No” path.
Another area worth confirming is to ensure that the “PriceAmount” attribute being referenced in the flow is the desired price attribute to reference in the Added to Cart event (often times there are multiple price-related attributes).
So to answer the last question, that amount is accurate because it’s based on a free shipping threshold. Because the High Value carts get a discount incentive, we wanted to make sure that the discount would not put them below the free shipping threshold.
I think I see what you’re saying with the one item in each event - are you saying that one item would need to be greater than 59.94 in order to go into the High Value? We don’t currently have any items above that number, so wouldn’t there be 0% going into the High Value if that were the case?
I was under the impression that it was triggered by the one item, but that the TOTAL cart value at the time of abandonment is what it was using. Is that not the case? Because that’s the behavior I’m wanting!
I think I see what you’re saying with the one item in each event - are you saying that one item would need to be greater than 59.94 in order to go into the High Value?
Correct. Assuming that each of your Added to Cart events only include one item (which is the default structure for the Shopify snippet), and considering that you currently don’t have any items priced above $59.94, that could explain the behavior in the flow.
If you inspect recent Added to Cart events, do you see only one item listed in each? Or, do you see multiple items listed in an “Items” array (i.e. an expandable property)?
If the former, then that’s likely the issue.
I was under the impression that it was triggered by the one item, but that the TOTAL cart value at the time of abandonment is what it was using. Is that not the case? Because that’s the behavior I’m wanting!
The trigger split is referencing the PriceAmount event property, which I’m assuming is the price for the individual item that was added to cart. Or is that the price reflecting the whole amount of the cart? It’s a bit tougher to understand without being able to view the event data first-hand, so just let me know.
Typically, the default Added to Cart event will only show the item added to cart’s price value, whereas the Shopify Checkout Started event will include a $value property for the entire price of the cart.
If you inspect recent Added to Cart events, do you see only one item listed in each? Or, do you see multiple items listed in an “Items” array (i.e. an expandable property)?
If the former, then that’s likely the issue.
...
The trigger split is referencing the PriceAmount event property, which I’m assuming is the price for the individual item that was added to cart. Or is that the price reflecting the whole amount of the cart?
So as I said, we don’t even have any items in our store that are over $59.94. So it can’t be just one item, it would have to be the cart total. So it’s working less than 1% of the time, but it is working. I will look more into the events and see if I can see more detail.
@Bobby I can confirm that it must be calculating per-item, as all the events that triggered the High value are international, and therefor would be above $59.94 for a single item because of the currency exchange.
So, what I’m wanting is the cart TOTAL. How would I do that in my trigger?
@caitlinlmh thanks for sharing the additional information there.
My hunch is that it might require a Shopify developer to reconfigure the Added to Cart event so that the $price value of the event reflects the cart total.
I understand you mentioned the below in your original post:
I made this Abandoned Cart flow a while back to the specifications that Klaviyo mentions, as well as fixing a little bug of the $value needing to be Price instead to register the items.
In this Added to Cart tracking snippet section, an example event payload is shown. Here, the $value property reflects the total cart value while an additional top-level property of "AddedItemPrice" displays the item price.
I’ve shared the above doc with several clients’ developers who have built this enhanced Added to Cart tracking. A benefit is that each subsequent event during a user’s session will include existing items added to cart in the “Items” array. Thus, allowing all items to display in the Abandoned Cart emails, similar to how they all display in the Abandoned Checkout emails, triggered by the Checkout Started event.
Would the above seem like an ideal approach, @caitlinlmh?
By clicking “Accept All Cookies,” you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts.
Privacy Preference Center
Your Privacy
Strictly Necessary Cookies
Performance Cookies
Functional Cookies
Targeting Cookies
Site Analytics
Your Privacy
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Privacy Notice
Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
Performance Cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
Functional Cookies
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
Targeting Cookies
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Site Analytics
These cookies record your visit to our website, and are used to track your visit including information such as: web page interactions (clicks, hovers, focus, mouse movements, browsing, zooms and other interactions), referring web page/source through which you accessed the Sites, heatmaps and scrolls, screen resolution, ISP, and statistics associated with the interaction between device or browser and the Sites. If you are accessing our Services with a European IP address, you have been asked to consent to the use of these cookies (you are free to deny your consent).