AMA - Recommendations in Adobe Target

[kandersen]

I’ve noticed quite a few threads and questions in Experience League around Adobe Target Recommendations recently - and it’s no surprise, because it can be tricky to wrap your head around how everything fits together. 

Some of the recurring pain points I see are:

• Feed vs. implementation

• How Recs are collecting behavioural data and how it is used

• Balancing business rules with algorithm performance

• Making recommendations actually relevant for users (not just technically correct)

So let’s open it up: Ask Me Anything (AMA) about Recommendations.

• What’s the toughest challenge you’ve had with Target Recommendations?
• Or, if you’ve cracked the code, what’s the one trick that made the biggest difference?

I’ll share my perspective and best practices along the way — but I’d also love to hear how you are approaching it. The best insights comes from our combined experiences!

[kandersen]

I've received a couple of questions via DMs, which I'll post here for everyone to see the answer:

Q: Do I need to upload my products via the feed for Recommendations to recommend them in a criteria?

A: No. You want to implement entity.id (this is the minimum requirement) on all product detail pages. Target will then use this to 'fuel' the criterias. The feed is used to enrich your products collected via entity.id. Maybe you're not passing how many items are in stock via an entity parameter, you can then pass this via a feed to have your criteria logic take into account how many items are in stock.

If you pass all the relevant information via entity parameters you actually don't need to use the feed. It is not a requirement to get the criteria to work.

[kandersen]

Another one from my inbox.

Q: Is entity.id required in the Design template?

A: No, it is not a required entity in the design for Recommendation to work. I primarily use it in my design if i need to debug, then it is easy to have the HTML print the ID for the product it is showing. I rarely used it in production and would only be relevant if you want to show the SKU for the product.

[chris-luckett]

Hi @kandersen, thanks for starting this thread.

We have a tricky one - we are using product recommendations to promote relevant products that are currently discounted or on promotion.

We have a "promotions" collection that is updated every 2 weeks, but have found that whenever we add or remove products from the collection it takes up to 24 hours to sync and the product recommendations are not displayed reliably on the front-end during this time. 

Is there any way to resolve this?

We are currently working around it by creating a new Collection and Target activity every 2 weeks, 24 hours in advance of launch, but this is quite manual & time consuming as needs to be done for a large number of markets.

[kandersen]

Hi @chris-luckett 
This is an interesting use case. I've had a similar case previously. Without more details, I'm not sure if this addresses your specific case. Previously we solved this by creating an attribute that controlled whether the product was a promotion or not. e.g. promoActive = false/true.

We then used the API to update this on the individual products (if that's possible for you), which would allow updates to happen after 15 min. We later moved towards a 'basis-feed' (the primary feed which was only crawled once a week or so) and a 'delta-feed' (which was crawled more frequently) and was only updating the promotion products.

Have you already looked into controlling the promotion through an attribute on the product?

[chris-luckett]

Hi @kandersen 

Thanks for getting back to me so quickly! No, I hadn't considered that as a solution, but defining promotions as an attribute to reduce the need to manually curate collections every 2 weeks is a great idea.

I'll need to do some thinking whether it's possible to create an attribute that correctly captures all of the different possible promo states for our products (I'm hoping to implement without the need to develop a new "promoActive" flag in our CMS) but if it can be cracked would reduce a lot of admin time.

Are you able to share why you moved to a multi-feed method as opposed to using the API to update all info in near real-time? Was it a performance concern?

[kandersen]

@chris-luckett 

Honestly, I don't remember all the details behind the decision, but if I recall correctly, it was easier to to expand their google feed which they already used, rather than develop a a full api solution. Initially, the api was a temp solution. 

It was not due to performance.

Let me know how you progress with adding it as a parameter - wouldn't be bad if you can reduce the manual work you have right now, which sound tedious.