Even after you've prioritized only the important user journeys, you may find yourself with an unmanageably long list of fine-grained SLI's, and this is the case we regularly find. It's because conceptually or architecturally, similar user interactions are considered to be separate journeys. Aggregating the SLI's for these journeys together, can reduce the overall complexity that operators need to keep in their heads. Let's look at a real-life practical example from one of Google services, the Play Store to illustrate how this works. The infrastructure serving the Play Store is complex, and users have lots of different ways to interact with it. We're going to look at four similar user journeys in this example. The first is visiting the stores homepage. Users do this automatically as soon as the app is opened. They are shown recommendations, curated collections, and ads for apps and content. From here, they can search the Store which is our second journey, or they can follow our third by navigating to categories of apps like photography or education apps, or contents sorted by genre like rock music, or family movies. Lastly, from either these category pages or search results, they can open up the page that shows the details of an individual app, movie, book, et cetera. From the user's perspective, all these journeys are similar because the user is just taking a look at what content is available to them. So, we can think of all these journeys as part of a browse the store meta-journey. All of these journeys involve the app making requests to the Play Store then displaying the data returned to the user. So we have availability, and latency SLI's for them. But instead of tracking these SLI's separately and setting separate SLO targets for them, we aggregate them together by summing all the valid events and good events for each SLI type to give an overall browse availability and latency SLI's. Simply summing things together can work well for many situations but when there is a large disparity in the rate of a valid events occurring for different component journeys, there's a risk that small but significant rates of failure affecting just one of the lower rate journeys can get lost in the noise. More complex aggregation strategies like multiplying the SLI's for the component journeys by a weight based on their traffic rates or relative importance, can ameliorate the risk to a degree.