@santhosh will you be doing the split for how much to request from which API (old vs. new) on your end?

@schana for context: we'd like to do A/B testing on this change. So group A users in CX will continue receiving recommendations from the old API and group B from the new API. We will monitor activity for some time to see if we can detect significant change (in specific measures).

@leila The A/B test won't need to go against the old API, rather just alternate between sending the search parameter as either morelike or related_articles when making a request. Although, for the translation recommendations, if the related_articles query doesn't return any results, it falls back to morelike. This is the way it's designed right now, but I think that logic doesn't belong in the API as it isn't explicitly what was requested - that kind of logic should live in the consumers IMO.

@schana I see. I get it now. thanks.

@santhosh will you be doing the split for how much to request from which API (old vs. new) on your end?

Yes, we will pick one of ['morelike', 'related_articles'] in random and do fetch. Once the user choose a suggestion, the alogirthm that fetched this suggestion will be logged in eventlogging. To be specific, these suggestions can be identified from ContentTranslationCTA_16017678 table with event_cta as suggestions-type-5-morelike or suggestions-type-5-related_articles

Follow T155657: Update config for new article recommendation API to see our progress in switching to new API

sounds good, @santhosh. Thanks for confirming. :)