Scaling The Disney Streaming Offer Management Platform
This article is the first in a series of technical articles going detailing the Disney Streaming Offer Management Platform within Growth Engineering and some of the patterns we worked with to scale effectively.
Growth Engineering at Disney Streaming is responsible for customer acquisition, retention and revenue growth. This team handles the Disney product catalog, the subscriptions for our global customer base, recurring invoicing, and payments. It is also responsible for all commerce related messaging during sign-up and price increases. Experimentation, Accounting, and Business Analytics are powered through events from this domain.
In this article, we’ll highlight the responsibilities for this domain. We’ll then discuss the challenges in getting offers available for our global subscribers with minimal turnaround time and how we solved them with configurations.
For those who may be new to Disney Streaming’s suite of brands, here is a quick review of the products referenced throughout the article: Disney+ is the streaming service which houses content from Disney, Pixar, Marvel, Star Wars and National Geographic. The Disney Bundle provides access to Disney+, Hulu, and ESPN+. Star+ is an additional streaming option for our Latin America customer base. In Star+, various live events from ESPN are available alongside premium general entertainment TV series and movies.
Offer Management Responsibilities
The team handles workflows for showing contextual and localized offers to our new as well as existing customers. It is responsible for the Disney+ product catalog, pricing, and the specific offers made available to eligible users.
Some of the challenges for this domain are:
- Reducing time to launch growth and retention offers.
- Managing an evolving Product catalog as well as a rich Feature catalog (e.g to download capabilities, live DVR, etc.).
- Expansion to multiple geographies brings challenges to localization, payment integrations, third party billing integrations, etc.
- Offer eligibility for a global subscriber base, price changes across multiple sales channels, and price holds for retention.
Challenges in Offer Management
A focus of this blog entry will be to demonstrate how configuration-based development to help reduce the time to launch offers globally.
The Offer Management team provides tooling to enable business users to configure offers with varied eligibility rules. Eligibility rules can be customized around numerous dimensions, including user demographics (e.g. country, locale, currency, age, etc.), viewing platforms (web, mobile devices, living room devices, and set-top boxes), and a user’s subscription and payment history (products purchased, payment trends, free trial usage, billing status, etc.)
The permutations for these various offers and their granular eligibility make it difficult to configure and handle them in a denormalized fashion. In the initial implementation, the requirements were feature requests for the development team, often leading to code changes to ensure that the offers were exposed to the relevant users. As offers became more complex and as demand for quicker turnaround times to launch them grew, a scalable solution was needed.
Configuration-Driven Eligibility
The need for flexibility around creating offers led us to pivot to using a configuration-driven pattern. This change allowed business operations users to leverage a configuration grammar to define eligibility rules for offers that are visible to users.
For example, one offer may include a free subscription for seven (7) days. After the 7-day free period, the subscription price is discounted 10% off for the next 3 months. After the 3-month period, the subscription reverts to full price. Additional discounts could be available to a user based on their selection (20% off if a bundle of products is selected), demographics (40% off for a student discount) or time of year (additional 20 % off only if purchased during certain holidays or events).
Eligibility Grammar
The configuration-based approach only works with a detailed taxonomy and grammar for defining eligibility rules. Exhaustive research on use cases for subscription-based streaming offers led us to create a set of relevant constructs. A representative example is described below:
- #cohorts : Represent sets of users who are similar in some way as defined by some cohort criteria.
- #hasStandAlone : Monthly or yearly subscription of a single product.
- #hasBundle : Multiple products sold together at a discount.
- #platform : Denotes Disney+, Hulu, ESPN+, Star+ platforms.
- #hasPaymentContext : References users who use some of the payment methods.
- #purchaseContext : For offers only made available within specific landing pages.
All of the above constructs ingest multiple arguments to make them configurable for a user.
Eligibility Example
An eligibility rule can be built using a combination of the constructs defined above using an Expression grammar. We decided to use the Spring Expression Language (SpEL) format to define the eligibility expressions. Through many experiments, SpEL was deemed flexible and performant enough to meet our use cases.
Let us take an example offer which has the following eligibility criteria:
- Offer only available to existing users or new users.
- User does not already have a Star+ or Disney+ product and does not already subscribe to a bundle of these products.
- User is not in a specific landing page for selling promotional offers.
The above eligibility can be expressed using our predefined grammar, as shown below:
The above representation is then converted to a SpEL expression format as shown below :
Extensibility
One of the important factors in our design was to ensure that as the number of use cases increase, the grammar could be extended with low effort while also ensuring backward compatibility for existing eligibility expressions.
Hypothetically, if we wanted to provide an additional offer based on the month (offers around Summer Break) and location of a user (Summer Break could be on different months based on geographic locations), the grammar could easily extend to include those constructs. We would have to implement the new constructs to fetch the data for the user #territory and #date. The rest of the workflow does not have to change.
Eligibility Resolver
In the above diagram and flow, Business Operations users manually input eligibility as part of creating offers on the various discounts and subscription phases. To better support these teammates, the eligibility grammar is pre-defined and is available to guide the users in a User Interface.
When a customer loads any of our offer pages, various services capture the user context, user subscription history, and watch/payment history. Based on these signals, the Eligibility Resolver service evaluates the eligibility expressions at runtime to find out the optimal offers for the user. The pattern shown helped us because it separated the criteria to make offers visible to users as configuration setup.
The latency requirement for this use case is low. Hence it is important for these resolvers to be efficient and data be properly cached. Mechanisms are in place so that the evaluations are done in parallel and data shared across the various eligibility expressions so that common expressions are not re-computed. The service code uses mechanisms to evaluate these eligibility expressions efficiently so that users can be served relevant offers.
The win: Business Operations users can now set up these offers using an Offer Management User Interface with little to no dev team involvement.
In the next article in the series, we will discuss some of the tenets we used to create entities for the Offer Management domain. We will take the config-driven eligibility discussed herein and extend it to show how the complexities of increasing the subscription price for our products across various channels and geographies are managed at scale.
