Skip to main content

There is an issue with the back in stock subscribe event having the product’s tags appended to the products’ categories.  The tags field is not shown in the back in stock subscribe event.

This using Shopify platform, but we are sending back in stock subscribe via javascript using email and “catalog-variant” relationship only.  We use endpoint : https://a.klaviyo.com/client/back-in-stock-subscriptions

When that subscribe event is viewed in the klaviyo profile, it shows the products tags appended to the products categories, and does not show a field “tags”.  It seems when the variant is looked up from the relationship, it is incorrectly mapping the product’s tags to the end of the categories.

This prevents other functionality that uses the subscribe’s product’s tags, such as segments.

 

Hi there @joshuaahanson

It looks like another user on the Community experienced a similar issue regarding configuring their back in stock flow. In particular, they were able to amend the syntax they were using by following a process outlined in this thread: 

 

Does this connect to what you are currently experiencing in your account? If not, please let me know and we can continue digging into what the issue may be. Thank you!

Best,

Ashley


No, I do not believe the other post is related.

Almost everything is working as described, except “Product Tags”.  Ill explain further…

We send to Klaviyo the following payload

const options = {
method: 'POST',
headers: {
accept: 'application/json',
revision: new String(revision),
'content-type': 'application/json'
},
body: JSON.stringify({
data: {
type: 'back-in-stock-subscription',
attributes: {
channels: a'EMAIL'],
profile: {
data: {
type: 'profile',
attributes: {
email: new String(input_email)
}
}
}
},
relationships: {
variant: {
data: {
type: 'catalog-variant',
id: new String('$shopify:::$default:::' + variant_id)
}
}
}
}
})
};

This creates the back in stock subscription event on the profile designated.  

In that event, it details information about the product and variant to which was subscribed.  This includes the following fields:

productID, productName, categories, platform, channels, variantId, variantName, SKU, price.

All of that information is correct, except categories.  The field “categories” contains information from the product’s collection (accurate), but also contains the product’s tags information (inaccurate).  The field “Tags” is not present.

Expected

It is expected that the field categories contains the product collection information, and not the product tags information.  Additionally, the field tags should be present on the profile event, which contains the product tags information.

 


Hi @joshuaahanson,

Thank you for that context! I spoke with our engineering team and have found that this is actually expected behavior because Shopify Tags and Collections are both treated as categories within the Klaviyo catalog service.

Do you have a specific issue that you are running into when building segments with these tags (or other tools in Klaviyo)? If so, we can see if there is a work-around or other solution to help you overcome this roadblock. 

Thank you again!

Best,

Ashley


Here is my thought process:

Shopify stores these 2 pieces of information separately: collections and tags.

Klaviyo has two matching fields: categories and tags. 

Instead of combining these into one field, why not leave them separated?

 

The issue it causes is hours lost trying to figure out why every other property in the segment filter correctly maps over.  Only to realize that the Tags field shown below will never have anything, and the tags field was somehow appended to the “categories” field.

I have a workaround, which is to use categories for both, but it certainly seems like a bug.

 


This is great insight @joshuaahanson, thank you for sharing this. 

I am going to send this feedback to our engineering team now - we are always looking for ways to enhance the customer experience! If there is anything else I can do to help or other questions that arise, just let us know.


Reply