Transforming Financial Forecasting with Data Science and Machine Learning at Uber

We previously highlighted some of the presentations delivered during our second annual Uber Technology Day. In this article, engineering senior software engineer and Uber Tech Day presenter Chunyan Song discusses how we apply data science and machine learning in our financial planning platforms.

By Chunyan Song

As of 2018, Uber’s ridesharing business operates in more than 600 cities, while the Uber Eats food delivery business has expanded to more than 250 cities worldwide. The gross booking run rate for ridesharing hit $37 billion in 2018. With more than 75 million active riders and 3 million active drivers, Uber’s platform powers 15 million trips every day.

Financial forecasting and budget planning for an organization that touches the lives of so many people on a daily basis is an incredible challenge. Add an astounding rate of historical and current growth, and these tasks seem nearly impossible.

To meet the challenge of running a global business at scale and making smart strategic investment decisions, we brought to bear our teams working in data science, machine learning, and financial technology.

To tackle this challenge, we built internal financial platforms where, rather than relying on annual budgeting and forecasts, we can continually update our planning to respond to changing business environments both globally and locally. Through scenario planning, our team members can test spending levels around Uber-specific goals, from sustainable growth to profitability for individual markets.

Our financial platforms let us respond quickly to changing financial conditions and support the growth and complexity of Uber’s business.

In this article, we walk through the process of financial planning at Uber and share how we built Uber’s finance cloud platforms to tackle the unique challenges posed by our dynamic markets and fast growth.

As at most companies, Uber’s financial planning cycles involve three phases, depicted in Figure 1, that cycle through strategic goals, operational planning, and analysis:

Strategic planning: this phase determines budget allocation and target expectation across the company and our global markets. The timeframe looks to the end of the financial cycle (most major companies tend to approach planning on an annual or quarterly basis).

Operations: following strategic planning, city teams work towards their set budgets and target expectations. The relatively short timeframe for operations planning can last as little as one week and as long as one month, with repeated cycles up until the next budget refresh during strategic planning.

Insights: this ongoing process monitors business performance, reevaluates and adjusts budget targets as necessary, and makes recommendations for improving the next cycle’s financial forecasting.

At most companies, financial planning occurs on an annual cycle, with strategic planning done at the end of the previous fiscal year. However, Uber’s global scale makes this annual cadence insufficient.

After coming to this realization, we began running our planning cycles more frequently. We established a mid-year rebase process using similar calculations as our annual planning to adjust budget and forecasts. In addition, we conducted a bi-weekly business pulse check across our global markets.

We identified many pain points and limitations in the process and tools we use:

These pain points made our financial planning cycle cumbersome and impaired our ability to adjust our strategic focus in reaction to fast-changing market dynamics. This lack of agility motivated us to build our own financial cloud platforms to address the following priorities:

The software our financial intelligence team built for financial forecasting and planning is an end-to-end solution, including a top layer UI, platforms for modeling scenarios and optimizing budgets, and a financial data warehouse and metrics store.

We designed the UI to make it easy for both our corporate finance team to do budget allocation and our city teams to do scenario planning. This interface makes collaboration effortless, as team members no longer need to email each other spreadsheets containing financial forecasting data; instead, they can concurrently modify, compare, and share scenarios in the same UI, all running on the same back-end systems.

Our Scenario Management and Optimization platforms make up the middle layer. The Scenario Management platform composes models and computes scenarios used by city teams to figure out what levers, or metrics, they can move to get their desired results. The Optimization platform uses mathematical optimization to help determine our global budget allocation for each city and the forecast business metrics they use.

Our machine learning platform, Michelangelo, plays a part here as well, supporting both scenario planning and optimization. It lets dozens of data scientists train, experiment, backtest, and deploy their models for online prediction, as well as functions as a model computation service.

Last but not least, good models need to be trained with good data. The lower layer of our financial software consists of a data pipeline, finance data warehouse, and metrics store.

The finance cloud platforms we built enable us to continually adjust financial planning throughout the year instead of relying on a quarterly or annual schedule.

The interactive UI makes collaboration between headquarters, regional, and city teams seamless, as they can all run their forecasting and planning at the same time, and pool their results together.

At Uber, a financial planning scenario consists of business metrics and computations arranged into a workflow. We can input initial metrics to see what results they will yield. To visualize scenarios, we represent them as directed graphs, similar to Figure 4, below.  Each scenario typically shows how budgets affect outcomes. A scenario can, for example, show us how many new riders will choose Uber based on our marketing spend.

With the potential to include many metrics and computations, these scenarios can be very complex and display many results. Using scenarios, we can test how budget allocation will affect results in specific cities. We power these scenarios with machine intelligence, but that is only half of the magic. We also leverage expert knowledge from thousands of talented employees in our city teams around the world.

Uber’s business is measured by many metrics, covering everything from number of rider/driver sign-ups and the number of first-time trips to our gross bookings. Depending on the maturity of specific markets, we strategically optimize certain metrics. For example, in a newly launched market, the strategic focus is often growth in riders, and a key metric we use to measure success may be the number of first_trips, the first trip a new rider takes. In mature markets, such as major U.S. cities, we might shift our focus to profitability, which means we might want to maximize the net_inflow metric, our net profit, while keeping the spending metric in check.

We run sets of input metrics through computations to get a set of output metrics, which can be intermediary steps in the scenario or final results, showing us, for example, that if we spend a certain amount on marketing, we can expect a specific number of new riders. A computation can be:

When a graph node is a computation, the nodes immediately preceding it are all input metrics and the nodes immediately following are all output metrics. Therefore, the graph of the scenario not only captures all of these metrics and computations, but also their dependencies. By its nature, the graph is 2-colorable and acyclic, as it does not make sense to have a metric or computation dependent on itself either directly or indirectly.

Since the graph is acyclic, we can topologically sort its nodes. As depicted in Figure 4, above, we can sort its nodes as x1, x2, A, x3, B, x4, x5, which gives us another way to represent this graph using a list of functions:

x3 = A(x1, x2)

x4, x5 = B(x2, x3)

In this example, x1 and x2 are initial metrics, meaning they do not have any preceding nodes. Given these initial metrics, we can calculate all the remaining metrics in the scenario by running the computations in topological order.

As used in Uber’s ride sharing business, we structure a scenario as shown in Figure 5, below. By providing the initial metrics, in this case acquistion_spending and engagement_spending, running the computations topologically will calculate the remaining metrics in the scenario, down to the very last: net_inflow.

The scenario above shows how we are able to make a large amount of intelligent models, designed by different teams across Uber, work together.

After we have built our scenarios, we can put them to work. Scenarios enhance our financial forecasting results and decision-making by combining machine intelligence with human expertise.

The scenario management platform has the following responsibilities:

At the beginning of every financial planning cycle, we use budget allocation algorithms to determine the initial spending metrics for each city, run the full scenario computation, and produce a set of base scenarios, otherwise referred to as the seeding process. Base scenarios, created by pure machine intelligence, are metrics projected by the algorithms. Take for example a hypothetical base scenario for São Paulo, shown in Figure 7, below:  

For explanation’s sake, suppose the seeding process gives the São Paulo city team $200 for new user acquisitions (acquisition_spending metric) and $100 for existing user retention (engagement_spending metric). The cost curve model tells us that setting $200 for the acquistion_spending metric will get us 35 new rider signups. By running our models in topological order, we can compute our metrics, including the very last one, a net_inflow of $1,274. The scenario computation is idempotent, meaning that re-computing repeatedly will yield the same metric values.

Models can be inaccurate for a variety of reasons, including:

Our city teams often have additional information about their localities and can make adjustments accordingly to the metrics in the base scenarios. For example, the São Paulo team might think that the same $200 acquisition_spending is going to lead to 50 new rider signups, not the 35 predicted in the base scenarios. As shown in Figure 8, below, we can rerun the scenario with the override value and generate updated metrics including a net_inflow of $1,350.

In order to optimize our operational efficiency, local teams often want to adjust levers, essentially changing metrics, to test out different hypotheses. For example, they might want to know the impact of reducing acquisition spending versus reducing fares in a given city. We built an interactive UI so they can compare scenarios.

When our team needs to test a hypothesis, they could, for example, create two new scenarios by cloning the base scenario, then in one scenario override the acquisition_spending metric, and in the other override fare. After computing both scenarios, they can compare them and see its impact on trips, gross bookings, and other metrics. They can create as many scenarios as they want, and eventually promote the most relevant scenario to guide the actual day-to day-operations.  

The top-down seeding process at the beginning of a financial planning cycle results in budget allocation to all of Uber’s 600+ city operation teams, as well as a base scenario containing the forecast business metrics for each city. To achieve an optimal budget for our worldwide organization, we use mathematical optimization to model Uber’s top-level strategic decision-making. We built our optimization platform, part of our financial cloud services, to handle these calculations.

Each strategic focus can be translated to solving an optimization problem for a specific business metric. During the early days of Uber, our top priority was growth, therefore the metric we chose to optimize on was the number of trips. Of course, we needed to work within constraints, such as spending. As the business matures, our priority shifts to profitability, and the metric to optimize for becomes net inflow.

In a mathematical optimization problem, the metric we optimize for is called an “objective.” Note that optimization may not always entail a maximization problem; it can be a minimization problem, as well. Here are some examples of the objectives that come up in our business:

With each optimization problem, we can also specify constraints, such as:

These objectives and constraints, which are based on current company strategic priorities, are fed into the optimization platform, which finds the optimal budget allocation and produces the base scenarios for all cities, as depicted in Figure 11, below:

In practice, we don’t usually have a single objective across all of Uber’s global operations, instead, we often have varying strategic priorities for different regions. For example, Latin America is a newer market where we want to invest heavily on growth, while in North America, a mature market where some cities are close to saturation, we might focus on profitability. In India, a market still showing enormous, untapped potential, our focus might be on sustainable growth.

To support multiple objectives, we structure the optimization problem in alignment with a geographical tree structure. The objective and constraints can be defined on any node. Then we can run the optimization problem at any level of abstraction, achieving both the global and regional goals.

We built a UI that enables our Finance team at HQ to specify their strategic goals in the form of optimization problems, such as optimizing for growth vs optimizing for efficiency.

Once the strategic investment objectives are input in the UI in the form of an optimization problem, the optimization platform tries to solve the problem by finding the maxima or minima through iterations.

Figure 13, below, offers an example of how we solve a budget optimization problem. Suppose we are doing budget allocation for Latin America, which includes dozens of cities (São Paulo, Mexico City, Rio Janeiro, Buenos Aires, etc.). In this model, we have set the strategic focus to growth and the optimization objective to “Maximize total trips” for all  cities.

The algorithm turns the optimization problem into a big while loop, which could include thousands or even millions of iterations. In each iteration, the algorithm provides a set of initial metrics for each city, which in our example is the spending metric. It then creates one scenario for each city, and computes all metrics in these scenarios. The algorithm simply keeps track of the scenarios generated in the iteration in which the aggregated trips metric is the largest (in other words, it finds the maxima through iterations).

We might only need to run the directed graph up to our objective metric, which is trips in this example. All the subsequent models and metrics (gross booking and net inflow) can be skipped. In other words, the directed graph that the optimization platform uses is always a subgraph of the full graph used in scenario planning.

The mechanism of the optimization platform is really simple. The magic lies in the optimization algorithms, which make up the brains of the entire budget allocation optimization process. There are a couple of optimization algorithms we use. Convex optimization is easy to construct and implement, but it is theoretically bounded by assumptions that do not always hold true for complex, real world problems. We also adopted gradient descent optimization, which allows us to express the richness of our optimization problem. Gradient descent generates significantly more iterations of more expensive computations, and it may not always converge and often takes a long time to converge. However, we can define our desired precision and the approximate results are usually more than sufficient for our needs.

As part of our effort to enable rolling forecasts, we also automated our system’s model refreshing, retraining, and backtesting processes. Automating these processes expedites the feedback loop and continuously improves our model accuracy. We are also leveraging the work of other teams, such as Marketplace, Global Intelligence, and Risk, to inject more metrics into the system.

Our finance data scientists constantly build new models. We primarily used aggregated metrics on the city level to do forecasting, but now are experimenting with deep learning models that rely on individual user-level metrics. Deep learning models require significantly more computation complexity but generate more accurate forecasts. Using these trained models for online prediction presents a technical challenge due to their runtime performance.

We are also looking at how our financial cloud services can be applied to general resource management at Uber. The generalized design and implementation of this system has already let our Uber Eats and Marketing teams migrate their financial forecasting processes. For instance, the Uber Eats team only needs to define a specification, thereby creating business metrics and computations, to generate forecasts on our system. We are also exploring how we might apply these platforms to l areas beyond financial planning, such as hardware resource allocation optimization and human resource allocation.

We are eager to see how other teams at Uber can leverage our system to build AI-driven forecasting platforms to further grow our business.

If you are interesting in building innovative and intelligent financial planning software, consider joining our team!

Subscribe to our newsletter to keep up with the latest innovations from Uber Engineering.