Simplifying Recommendations for TV with Flutter and SAS Event Stream Processing Engine
Ah, the age old subject of recommenders. Here we go again.… If you’re in tech and follow blogs here on medium, you’re probably thinking this. But, let’s stop there and start at why recommenders help. You might go, that's basic but ok, it improves obvious business metrics we try to optimize. Ok, sure, it can help scale your business but at its core, it helps drive engagement while democratizing a personalized experience to fit your customer’s potential needs.
Alright, if we find that response acceptable the immediate next question is why democratize anything? The ‘easy button’ response to that is when we democratize capabilities, we have the widest reach to create impact. Possibly create impact that can drive change. Although it’s questionable if all change is good or even warranted, the overwhelming idea is to use tech as a tool to aid change by some magnitude and direction so we can keep moving forward (or feel like). Essential to making this purported impactful progress is a compass grounded in a value system that powers the intentionality and the direction of the change. Therefore, before we try to democratize any capability, we have to ask ourselves — what are the foundational values that drove the creation of this capability? Not just what gets solved, but why and how it is being solved. While it does seem like a very simple question, the question around foundational values is often unanswered, misunderstood or skimmed over simply because we’re caught in the grind of choosing comfort over deliberation. The internet at large, social media, streaming platform etc. train us to do this. Many thanks to recommenders.
Unfortunately, if we aren’t intentional about the driving value system, the so-called democratized technology could end up doing the exact opposite thing that it may claim to do or have set out originally to solve. In the area of recommenders, for example, we might force too many choices or take away from the experience by butting in with an “I’ve got this to offer” opinion.
Therefore it is important to choose how to surface any recommendation based on the values associated with the brand you desire to create. These values, obviously, will differ based on what you care about as a company and what the company’s core competency is. All other metric-knobs you turn to optimize for this (around revenue, engagement, clicks, views etc. across various customer segments) follow these values.
All of that prelude is just to say always think about your customer’s focus (whys) and “focus” on their needs in that context (how). Understanding needs without understanding context is as good as understanding nothing when it comes to recommendations. Instead of improving the experience, you could inadvertently end up disrupting it.
With that, let’s get into the why and the how around our recommendation app.
We’ll be building a companion app for linear TV where the problem is around choice. Too many choices to select from, too little time to grasp what’s playing across all the channels and yet choices have to be made. What if our companion app did this for us? So our why is — we want to optimize viewer’s choice to reduce the unnecessary cognitive decision making overload and we want to deliver this optimal choice (the how) via a companion app that doesn’t intrude with the viewing experience. Since this is a fictitious application, we can consider that this is what our audience likes. Just to make it fun, let’s just say that our focus group preferred the companion app idea.
With that out of our way, let’s show how we can use flutter to build a cross platform app that can then be used to surface pinpoint recommendations based on the viewer demographics, psychographics and content consumption behaviors. A super smart colleague of mine has written this blog on how to set up a good recommendation system and make it ready for real time streaming analytics. Let’s pick up from where that ends. To make things easy let me give you a quick overview of what the streaming analytics project is doing. It broadly does the following three steps before generating a final recommendation.
- Calculate metrics on what the top shows are in the last hour based on the viewer count.
- Using the customer profile (i.e history) and streaming set top box records, generate overall recommendations (using a factorization machine model)
- Next, merge the results from 1&2 above and pass these results into a model that predicts if a family is consuming content currently. Once this is done, generate the final recommendation from this data
For simplicity sake, in this example, we want to just generate one recommendation per “recommend” request. But you can most certainly generate as my recommendations as needed per request.
Our companion app layout is going to be pretty straightforward. We have a ‘login’ page, a ‘currently watching’ page and a ‘recommendation’ page. When the user requests to ‘Recommend Something Else’ on the currently watching page, we want to post the event to SAS Event Stream Processing (ESP). SAS ESP then does the aforementioned steps and returns the result back to us.
There are other user actions that could be performed here as well, just so we can then collect feedback from the user for future recommendations but that isn’t the focus of this post. To keep things simple, we’ll assume the iOS user experience shown here is same as the Android user experience. So far, its been straight forward as to how we’ve set this up. At this point, we need to retrieve the current best recommendation based on the user preferences. To do that, we can make a call to SAS ESP looking for that specific customer’s recommendations. Our function makes an asynchronous call to the NetworkHelper class as shown below.
The getData method in the NetworkHelper Class then shoots the request off to ESP, which retrieves the response from ‘Final_Recommendation’ window in the stream processing model shown HERE.
Following this, you can just parse response JSON appropriately and update the widget on the recommendation page by using a simple setState.
At this point, you should be able to create the experience we desired using the the companion app. I’ve placed the code for the entire demo app here, in case you’re interested. We’ll take the point of view of two users Jack & Jill with different viewing patterns. You can see below how the app produces different recommendations based on viewer preference, whats being currently watched, anticipated viewing type (watching with family vs not), past consumption history and trending top shows. Once again, check out this post on how ESP does this.
Sure, you could skip the currently watching screen if they user isn’t watching TV. But besides that point, doing something like this and allowing customers to switch over to content they would like quickly and easily is beneficial not just for the viewer but also for businesses that are struggling to keep customers as they increasingly choose streaming options. Something like this could reduce the choice paradox and massively improve the overall TV watching experience since the “decision making” is passed over to AI that understands the viewer intimately thereby avoiding situations like THIS.
Let’s also quickly examine what SAS ESP responds with for our two users — Jack and Jill side by side. On checking out the JSON response we can see our models have figured that family friendly content needs to be recommended to Jill as she is likely watching TV with her kids. The selected recommendation is adjusted accordingly based on this prediction as shown below.
As we’ve seen in this post, we can use endpoints from specific windows on SAS ESP for injecting the power of AI in your apps just like how we’ve enabled personalized user experiences through our demo TV companion app. Additionally, ML Models and business logic can also be served up via SAS Micro Analytic Service but that’s for another day and another time.
Connect with Sathish on LinkedIn
