Integrate Azure Personalizer for personalized content
Is your enhancement related to a problem? Please describe. Increasing the relevance of recommended content
Describe the solution you'd like Leverage Project Custom Decision from Microsoft Cognitive Services Labs. Project Custom Decision (formerly Custom Decision Service) is an experimental API offered as part of Microsoft Azure Cognitive Services. It uses Reinforcement Learning to personalize content for each visitor, and experiments with new choices to see how different options perform and adjust to emerging trends.
Designs n/a
Describe alternatives you've considered I have yet to research alternatives in existence.
Additional context I believe we've got some sample code that could help, I'll look to find that before we'd begin on this work.
@jeffpaul Noting here, as discussed in Slack, I'm going to take a look at the new Personalizer service and see what would be involved with integrating it into Classifai (potentially using https://github.com/10up/azure-cds as a starting point).
An interesting, related quote from WP Engine’s London Summit: How AI Can Build a More Meaningful Digital Experience:
Companies need to be accurate in their personalization, as 99.6% of respondents agreed, but it’s equally important to be “free from creepiness,” according to 99.1% of those questioned. If you master both these skills, 40.3% of consumers will return to your website, because the experience provides a sense of emotional engagement.
From that I infer that we'll want to make sure we test our Personalizer integration in ClassifAI to ensure we're getting relevant and accurate content returned and that we're clear within ClassifAI about any data collection, targeting, logging, etc. that happens within Personalizer (especially if that's in any way data at a user level instead of at a large geographic region or broad site level).
Reminder that @eisber and https://github.com/microsoft/Personalizer-WordPress is option to stay in touch with as that project and this feature enhancement both iterate utilizing Azure's Personalizer service.
Another note that we'll want to consider potential uses of ClassifAI in a headless nature and how those sites might be able to utilize the content personalization features if the data coming back from Azure isn't somehow stored in WP to be utilized by a decoupled front-end.
@jeffpaul After playing with Personalizer a bit in WordPress, I don't see where there would be value in storing anything Personalizer-related in the WP database. Of course I could be missing some possibilities, but with the way the system is architected, I think it works best with this lifecycle occurring within a given pageload:
- After pageload, make a request to the Personalizer API with context info (e.g., user location, time of day, content of current page, session info, device info, etc.)
- Receive Personalizer's suggestion back from the API
- Use that suggestion to serve something to the user (for example, a related post that flies in at the bottom of an article, or a social widget)
- If the user takes the action you want, then within the same pageload you send a second API request to reward Personalizer for the good suggestion (e.g., if a user has clicked the related post, you catch the click and send the reward to the Personalizer API before sending the user to the next page)
Having Personalizer loops that span multiple pageloads (via cookies maybe) would be possible but would increase the technical complexity significantly. The Personalizer docs actually try to steer us away from this sort of thing. One of the things I love about Personalizer personally is that you can do all this without tracking anything from anyone.
In cases where a site deals with only logged in users, much more could be done because the user session is more like a contract and more reliable.
In my exploration, I created a WP REST endpoint to proxy the Personalizer endpoints. With this approach, it would be possible to capture anything you want to capture to store in the WP DB, but so far I haven't thought of a reason to do so.
Where I left off I'd played with the related post concept a bit and was brainstorming similar site features that lend themselves to what I outlined above -- i.e., they lend themselves to coming in after pageload and ideally lead to actions that can be rewarded within the same pageload.
In some ways the headless architecture would make these things more natural because you're likely dealing with React or another similar library where tools to make things happen within a pageload are built in.
Thanks for the input from your research @johnwatkins0, that definitely helps inform what we should do and how in terms of content personalization with Personalizer!
Let me just point out that user profile information (e.g. stored in WP) can be super valuable for ML (=Personalizer). Apart from the additional tracking work, one also needs to closely look on how to obey GDPR (anonymization, cookie agreement, data retention, deletion, ... ).
@eisber totally agreed on the GDPR front. My inclination is the default our application to NOT utilize user profile information and force sites to explicitly enable that feature with callouts of potential GDPR concerns (potentially referencing best practices in staying compliant).
This issue needs more UX analysis and thought on how we approach this, so I'm punting to 1.7.0 in hopes that we'll be able to get some of this early stage planning done in that release cycle.
Potential default block layout/design:

Block toolbar: ClassifAI logo, drag/drop, up/down, change alignment (wide, full), options Default block title text: Recommended Content 3 columns of posts including: featured image, title
Potential block settings layout:

On by default: Display featured image, Display post title