Or just feel a little less like you're scrolling on your own. It's a sort of feature that makes you go, that's nice. And then you carry on with your day. But as you might expect from a feature that has to work for billions of people across a staggering range of devices, there's a lot going on under the surface. How do you figure out who someone's close friends actually are? Not just on paper, but in context? How do you pre-fetch all that data without the server X looking like they're electing a new pipe? And how do you keep animations?

Battery smooth across everything from the latest iPhone to a five-year-old Android headset that's hanging on for their life. To walk us through how they handled all of this, I'm joined by Joycef and Suba Shri from the Facebook video recommendations team. We get into the clients and performance challenges, the evolution of the MM model that powers front ranking, and why, counterintuitively showing fewer bubbles, turned out to be the key to making the whole thing worse.

For another Facebook-specific engineering deep dive, check out the Meta Engineering blog, which just published an article about the revamp of the Facebook group search that brings a bunch of novel ML techniques to search and leaves traditional lexical search models behind. But now, without further ado, here is my conversation with Joseph and Subashri. LLMs are all the raids right now, but traditional ML still powers so much of what makes our apps feel special.

And helps you stay connected with your mates. The Facebook Reels team recently launched Friend Bubbles, a feature that looks deceptively simple until you start to interrogate the details. How do you keep a feature like this performant across a wide range of devices? And how do you figure out which recommendations are relevant and which ones are just plain annoying? To talk me through the challenges and solutions, I'm delighted to be joined by two brilliant engineers, Subashri and Joseph. Welcome to MetaTech Podcast.

Joseph: Thank you. It's good to be here.

Pascal: Fantastic. Let's talk about you first before we talk about the feature that you have been developing. Subasree, can we start with you? How long have you been at Meta and what did you do before?

Subasree: Sure. I've been at Meta for a little over eight years. I actually started as a return intern after finishing my master's in computer science at University of Wisconsin Madison. Most of the time I've been in the Facebook video recommendation space, working on the systems that help people discover content they love. I've touched various parts of the stack, platformizing the various endpoints across the Facebook video surfaces, ranking models to influence the content recommendations, performance optimizations, and so on.

Yeah, and most recently I was involved in bootstrapping the L and ranking systems for our friend.

Pascal: Yeah, Joseph, can I pass it on to you?

Joseph: Yeah, I've been at Meta for just over a year and a half now. In my career, I've primarily been a mobile engineer, started an Android, and then flipped to, you know, focusing more on iOS, but I've kind of done little bit of both. But I've gone through a journey. I, you know, began working at Microsoft, working on the OneDrive app, learned a lot there about just performance, scale, et cetera. And that's kind of where I began my career. And then afterthat was in Seattle. My wife and I decided to move to Austin, where I am now, for more sun. And at that point I moved to PayPal where I worked on messaging. And you know, there again I learned a lot more about mobile performance. Yeah. And I guess now here I'm at PayPal working primarily on the engagements team. started off on private sharing, but primarily just all sorts of engagements on reels.

Pascal: Before we actually talk about this feature and the metrics behind it, Subasree, you briefly touched on it, but what is it really that you're trying to achieve on a big level? So like not the numerical stuff, but what gets you out of bed in the morning? What do you want to achieve with all this?

Subasree: At a video recommendations team is to deliver entertaining videos that bring people closer to friends and family. In other words, how do we make the video consumption experience more delightful?

Pascal: All right, I think that sets us up fairly well. So can you talk about the origin story now of the particular feature we want to discuss this? So how did she come up with Friend Bubbles?

Subasree: Instagram had already launched a version of Friend Bubbles a little over a year ago. This was our inspiration for bringing it to Facebook, as the core of Facebook experience is staying connected to your friends on the platform. And social discovery. So talking about medium consumption experience a little bit, when users are able to share their interesting reels with their favorite friends on the platform, this is a different aspect of the social engagement where

the social discovery happens as you're consuming the videos on the video surfaces. So if a user is able to watch content that is already endorsed by their friends in a way social proof, then this would match the user interests and also make them feel more social in a lightweight manner.

Pascal: This has definitely applied to me as well. I'm not a huge like Facebook Reels consumer, but I'm very active on Instagram and sometimes a friend bubble pops up and it's really nice to have this kind of conversation starter.

Subasree: Success was never just one metric. Of course, we track user engagement. Are people watching the video? Are they liking, tapping on bubbles? But we really cared more about the quality of the experience, not just the quantitative metrics. What we found is bubbles don't just get people to open the app more, but they change how people spend time. Deeper consumption, are they able to share more content with their friends and connections on the platform?

yeah, so people start coming back to see what their friends are into today, catching up on shared interests. So we also use qualitative measurement, subjective feedback, where we send out surveys to users on our video platform to capture the feedback from users on their experience of video recommendations. So we make use of these survey responses to understand if there's a significant lift in engagement on videos with bubbles and without bubbles. These were some mechanisms that we used. And of course Meta is hugely data driven. So we run a lot of A B tests to be able to understand what users' experience has been on the platform.

Pascal: Started and Joseph, this is probably a question for you, but from the client side, were there any particular constraints you had set up?

Joseph: Yeah, more than you would think. We began this thing, you know, expecting it to be a simple feature, but we quickly ran into some complications, even with the basic algorithm of how to understand which friends of yours have liked a video. And the sheer amount of data that Facebook processes, the sheer number of reels, number of friends, number of people using it, all of that really added up quickly, you know, and so the basic idea of taking the number of reels that we are given from the ranking side user is about to load, cross-referencing it with the likes of all your close friends and even down to calculating who your close friends are based on some other algorithms, the capacity constraints added up very quickly. So we went through a few different iterations of that specific heuristic and how to calculate that. sometimes had to make compromises on timeline, etc., but ultimately ended up with something that we thought that was performant, but still, you know, at the end of the day, cost something.

just because of Facebook scale. And then on the client side, of course, we have to deal, especially on the Android side, with a lot of lower end devices or devices maybe in areas that have lower connectivity. And so and you know we can get into this, but through the course of testing, we identified various optimizations for the animation and things like that to account for the the lower end devices and to cut out things that were not necessary.

Pascal: For the folks who might not have seen this feature, could you briefly describe what it actually looks like before we go into the different kind of client specific optimizations that you've made?

Joseph: Yeah, so when you open the Facebook Reels app, what you would see essentially is if you scroll and get to a video that one of your close friends had liked, you will see a bubble that has their avatar along with the reaction. So it's not just likes, it's you know, parts, ha ha, any positive reaction. And you will see up to three. and they you know the animation effect is intended to create sort of a floating effect. So they're all animating randomly.

Pascal: Does that have any positive effect? does that mean the angry reacts are disabled?

Joseph: Correct.

Yeah. Yeah. we we did discuss that. at least for the first version, we decided to cut those out. Those didn't feel as relevant and not in the spirit of, you know, the positive friend connection that we wanted to create.

Pascal: Makes sense to me, but it's really interesting that this was part of the discussion. Okay, so I think now that we probably have some idea in our heads of what this actually looked like. What did you see in terms of regressions or things that didn't quite work out as you were expecting?

Joseph: The very first version we ran was surprisingly difficult just for the, you know, clients to render. And so the very first version of the algorithm, for instance, dealt with a lot of data, you know, cross-referencing your close friends with, you know, the likes on the videos, the reactions of the videos, all of that immediately had an impact on the just the capacity, the amount of capacity we're using to make those calculations, also the amount of time it took to load reels on your Facebook app.

and then not to mention, as you're using the app, we found, especially in the earlier versions, the scroll performance, which is something that we measure on reels, which essentially calculates or looks at the number of skipped frames to use, you know, it uses these metrics, basically takes the number of skipped frames and compares them between test and control to understand how smooth the scrolling is.

Basically, we take scrolling performance very seriously. We take performance of the app very seriously because everything is so sensitive and because of the sheer amount of scale. So animation, scroll performance and capacity were some of the big things. And then load time of the reels were a lot of the big challenges we hit early on.

Pascal: I think this is probably one of the biggest surprises when somebody who hasn't worked on a large app joins the company. How many metrics there are about just the quality of the app, something like dropped frames or the overall memory footprint, potential number of sad users that we define through various metrics like an oom occurred or a feature didn't load properly. So

Joseph: Definitely, definitely. As someone who is new to the meta company in general, I was I've been really impressed by the amount of tooling that exists. You know, you learn a lot of these things through experience, general experience, and you have different ways of measuring things at different companies. But that's one of the things I've been continually impressed by is the amount of measurement, the number of things that we can take into account to make sure that people get a truly snappy experience. And that's I think something that you have to do at this kind of scale.

Pascal: Right. So once you realised, for instance, that your payload was too large, how did you actually fix this?

Joseph: We have an incredible team here that specializes in performance, capacity, and all things related to that in Reels. So we consulted with them. We used the data we did have experience and we came up with our own hypotheses, but we consulted with them to understand and to help us understand, you know, what could be going wrong. So the way we initially designed it actually was using just typical software engineering practices. For example, on the mobile side, it's very commonly known that you want to load UI.

Asynchronously, you know, don't block the UI while you fetch unnecessary metadata. And so that's the way we designed it. And what we found is that there are already a lot of optimizations that exist in the prefetching that allow us to load metadata in a way that, you know, it presents immediately to the user that doesn't impact the load time too much. At the same time, because of the fact that reels are playing constantly, it's not typical UI, you know, when you open an app.

The UI is typically frozen in space until you do something, whereas a reel is constantly playing, which means frames are constantly moving. So every update you make to the UI will have a negative impact on how smooth it is. And so that was one of the things they helped us understand is just that asynchronous fetching was actually leading even to some crashes on some lower end Android devices. So that was one of the big architectural changes that we made that ultimately changed.

how the feature performed and even a lot of the engagement metrics. surprisingly we learned that iOS users are a lot more sensitive to performance regressions. So our initial iOS experiment was quite neutral until we fixed some of those scroll performance issues. And then suddenly we saw all the engagement lifts. And that was one really interesting learning that we took away to the next few projects.

Pascal: So does that mean that iOS users are just generally less accepting of any kind of jank, any regression in what they would usually expect of a feature and would rather not use it? Whereas on Android it's more like, hey, shiny new thing. Let's try it out, even if I might use a drop of frame here and there.

Joseph: Yeah, yeah. And I think it's not to say anything of users, but I think iOS has fewer lower end devices. And so people are already used to very performant apps, very performant devices, which means something that drops, you know, a few frames means they will go to the competitor and do something else. Whereas on Android, especially for those lower end devices, people are already used to, you know, things that might drop frames, things that don't perform as well. So they're more willing to give it a try.However, I think the trade-off there is that we dealt with more crashes. And so we still couldn't ship something that had several crashes or a huge regression on scroll performance, even if users tended to be more forgiving. And even on Android, once we fixed those, we saw lifts in all of those metrics as well.And I think on Android in particular, the users with higher end devices or users even in areas that have better internet connectivity also showed some of that same sensitivity, is just less apparent because the pool of Android users is so much larger than iOS in the world.

Pascal: Yeah, I can see this. And no, it's it's not really about users per se, I guess. It's just the kind of baseline expec expectation that people have. I have a bunch of kind of lower end Android devices here and just the system itself is janky. It's not even the apps, but just using the home screen is slow and drops frames and sometimes doesn't react on a tap. So I guess if your feature then potentially slightly regresses the baseline performance that you've had before, it's not even noticeable because there was never this iOS liketop end experience that you have where everything is super fluid.

Joseph: Yeah.

Subasree: Yeah. I want to add to what Joseph just talked about. performance definitely has a huge impact on our overall app experience. To give a little bit of data, more than 50% of users' time spent on Facebook app is on video surfaces. So even a small degradation in performance can hurt our engagement metrics. And to speak a little bit more about video prefetch that Joseph had mentioned about, a prefetch request is actually

request that's triggered ahead of time shortly after app startup. The reason being when users enter videos again is a very heavy object and there's a lot of recommendations and processing that happens in the back end. So we don't want to surface this latency in terms of video loading when the user enters the app. So this request fetches the content ahead of time. So when they land on the video surface, the content is already available for them to view it. So in in our bubbles project, the optimization was basically to

bundle the metadata fetch for rendering the bubble, the friend fetching and all of that. So it's pre-computed and stored on the client side and then rendered when the user enters the tab.

Pascal: Yeah, and I guess these pre-fetches that you get at the start of the app will be super highly sought after, like like prime piece of real estate. Everybody would love to have their feature be preloaded because it just behaves better. But you're giving a great justification for it. If that much time is spent in the app just watching video, then it is just a net benefit for the majority of people to have this load as quickly as possible. So if you've noticed that there was some sort of regression for a particular client or subset of users.How did she go about addressing that?

Joseph: We have to take the feature list, you know, take our feature and really analyze each aspect of it and separate what is critical versus what is nice to have. You know, those things that are core to the feature and user delight. And so one of those that we isolated was animation. It was something that is essential to the experience of the bubble, but is not essential to the core feature. and so what this meant was, you know, for example.

because we know that even after moving everything to prefetch and we still had quite a lot of scroll performance regression. We took a deeper look at the way the animation is done. So for one, we changed the architecture of just how you know it works in the UI, especially on the Android side, but then we also applied a few mitigations. And so things like limiting it to high-end devices only, making sure that only users or devices that can handle it are rendering the animations. And then another thing we did was really examining the experience of a user and trying to isolate when exactly the animation needs to happen so that we could pause it in those times when it's not. So that meant, for example, if a video is loaded, you know, to be shown next, but not actually showing right now, or was just scrolled off of, we switch off the animation on those. And then the other thing we did was if you're actively scrolling, interacting with a video, as a user, you typically wouldn't perceive the animation, especially if the video itself is moving.

So that meant we pause it on those. And then some lower end devices we discovered, no matter how many mitigations we applied, we couldn't avoid the scroll performance issues. And so we just switched off animation on some of those lower end devices. And so all of those together allowed us to ship this thing where most users still experienced a good amount of user delight without any regressions on the overall.

Pascal: Yeah, that's such an interesting overview of the scale that we're working at here because these would be considerations that often don't even make it only prioritization session for smaller apps. You can't serve everyone, but that is literally our mission here. These features need to be able to serve every user. And it's just not acceptable if you have something that potentially even crashes your app because the device has too little memory or GPU VRAM or whatever it is causes these problems. Right.

Joseph: Absolutely.

That core mission of Meta to serve everybody does, you know, make some of the engineering problems more difficult, more challenging, but more satisfying when we do figure it out, because then we can confidently say we served everyone with this feature.

Pascal: Yeah, and I feel like most engineers actually take pride in these little performance optimizations. And I I found myself in like past jobs trying to fight for them, and there was just no good justification of spending an extra week or month and making this super smooth and burning fewer CPU cycles. But here is actually part of the core mission. So you can focus on these optimizations. Sure. Can we talk a bit about the model behind all of this that?

Joseph: For sure.

Pascal: powers it. So I understand that you had multiple versions of it. Can you talk a bit about the first version that you've had and potentially where it fell short of your expectations?

Subasree: Yeah. So we already have a video recommendation system ranking the content from millions of videos in our Facebook app to show the ones that are closely matching with users' interests and which we think the users will find enjoying on our platform. Now the real challenge here was firstly to find the relevant videos liked by the user's friend graph.

So using a model to be able to identify user-to-user closeness. So we have a friend survey that gets sent out on our Facebook app where we collect information about a user's closeness to their friends in the real world. So we use this information to build a model, which is basically emitting a score given a user-user pair. So we use this as our initial version of the

model to rank videos which have bubbles. There are again going to be candidate generation phases where we fetch the video candidates, where we also introduced an explicit generator, which is to fetch candidates liked which video candidates here, which are liked by the user's friends. We then rank it in our various ranking passes, where we use the social engagement as one of the user interaction signals.

to be able to rank the videos along with the so many other optimization functions that we have to render it to users. This was our first version, but again, all of this has to happen within a sudden number of milliseconds to be able to show the content to user.

Pascal: Right. Surveys are such a powerful tool and also very limited because you need to find people who are actually able to take it. It takes some time. There's some selection bias. But our platform for this is also just really incredible. I used it before not to ask our external users, but just our internal developers about usage of different frameworks. And you can just target internal users with the same tool as well. And it's really cool because you get a lot of information out of it.

Even though you are clearly using it directly to train the model, whereas I was just looking at some fancy graphs that I could then present back to framework teams. So what was then the the second version of this? What was your evolution after you moved on from the server based model?

Subasree: Yeah. So the survey-based model was definitely serving the purpose of being able to test this product end-to-end and to be able to get some initial signals on whether this is resonating with the users and our platform. but we also realized that this there is a limitation with this approach where we are not able to capture the interactions that the users have on the app. For instance,

Liking, commenting, co-engagement on our platform is not fully captured in the survey-based model. So we want to build an online interaction-based user-to-user closeness model. Since the bubble interaction, the UI also has a tap and a post-tap experience. So when the user clicks on the bubble, there's also a messaging bar where they could chat and have a conversation with the friend. So this sort of engagement loop needs to be tied back into our model.

to be able to let the model understand which bubble videos are actually useful and which user pairs are interacting on our platform. This was the whole idea behind the user-to-user closeness based on the online interaction model.

Pascal: But I that also means you really needed the first version because otherwise you would have no data to kick start this feature to begin with. And once it was live and you had some data, which might not have been the optimal way of ranking it, you could then use the real world signals from this particular feature to train the second version. Is that about right?

Subasree: That's right. And also again for ML, we we need a product working end-to-end to be able to even log the signals and data for us to be able to train a model. So this is where the sequential development sort of comes into picture where we need the UI elements in place, the logging, and then comes the MLPs.

Pascal: Right. I don't really know how you train these models. So what is the the kind of infrastructure behind the scenes? Is it like in real time that you update the model or do you batch it all and run it weekly? What is the life cycle behind the scenes?

Subasree: The survey-based model is of course processing trillions of user-user pairs, but this is something where the information might not change a lot compared to video recommendation model, where we get a lot of videos in the inventory from time to time, which needs to be a little bit more real-time. Even a small lag in the user interaction data collection can actually degrade the model performance given the data drift that happens, changing user interests and so on.

However, the user-to-user closeness model is slightly less sensitive to these changes. It's not going to change. The friend graph doesn't really change a lot day to day. So that was an inference done in a weekly basis. And we also train the model once in a while. So it's at a different cadence, less real time compared to the recommendation models for videos.

Pascal: I see. And when you have these big model training sets and a new model comes out, do you experiment with those as well? So do you see like how much better they perform to previous versions?

Subasree: Yeah. So we closely worked with the user-to-user closeness model team, which models a friend graph across a Facebook family of apps. And they they roll out different versions of the survey-based model where they used to compare various models to be able to identify whether this model is better, trained with newer features, and so on.

Pascal: After you've launched the new model, were there any interesting, potentially unexpected findings that you've had?

Joseph: Actually, one thing that we initially thought is if this bubble is useful, why don't we add it everywhere? Why don't we put bubbles on every video? Why don't we show all your friend likes? And a lot of the data actually, and even intuitively, and some of the UX research that we did showed us that the quality of the bubble matters just as much as the prevalence of the bubble. And so you might notice if you open up your Facebook Reels and open it, you won't see that many bubbles.And that's by design. And this is because that bubble real estate is very important. Every piece of meta metadata on a video affects people's experience watching the video and how immersive it is. And so we had to be really careful and targeted in whose bubbles we show and what bubbles we show. And so this meant being really careful and conservative around the limit of how many friends we would allow to be eligible for bubbles. And so the first version we just did something like your top hundred close friends. but that's a model that we're consistently evolving to try and improve the relevance of the bubbles, not just the prevalence.

Pascal: Right. I feel like this is probably also where the data driven approach comes in again and is so important because I would think if I were to work on a feature like this, I would think this is the knees bees. I need to show you this absolutely everywhere. This is the best thing ever. And you need to have a mechanism of keeping you in check. It's like, no, maybe less is more in this case. Actually focus on quality over quantity. So it's really cool to have the the right checks in place that you arrive at the correct conclusion here.

Joseph: Definitely it hits a point of diminishing returns. If you show too many, it becomes less valuable and it tanks the whole feature.

Pascal: Yeah. Coming quickly back to the feedback loop, how exactly is that set up? Is there anything you can share about the challenges and potential solutions you found to problems there?

Subasree: So, the feedback loop, we would want the user's bubble interactions on the videos to flow back as signals into the training data for the model to pick up this. So again, the logging here is really critical on the user's interactions, trying to understand if users are skipping more on a certain video which had a bubble, watching, commenting, liking, and so on. So all of these interactions build our training data.

So it was important for us to update our models to use these interaction signals so it can rank the videos with bubbles better for surfacing the right content and the model to be able to understand user interests. So capturing the user-to-user closeness is one part of it. But also it's very likely that a user may be close to their friend in real world, but they may not actually share the same common interests when it comes to the Facebook, be it

Following the same sports league or hiking or baking interests. So it was really that nuance in capturing these interests in the model to be able to serve better recommendations. So we had to build the model to be able to use these signals and pipe it into a ranking funnel so that our existing video recommendation models, now friend aware, be able to rank them better.

Pascal: That is so interesting, yeah, because I've also noticed that my interests shift over time. So do those of my friends, and someone had like a Venn diagram that was basically circle in terms of our interests are now fairly removed, and you need to have all these cons considerations. And if you s as you've said before, there's also a drift going on. So keeping this up to date is just so important. Cool. I think I need to ask you because this was developed in like, I assume, late 2025, early 2026.How did AI help you out with building all of this?

Joseph: So we began this feature in early 2025. The very first version we tested, I think last April. And it's crazy to say this, but you know, at that time the use of AI for development was still quite novel. So some people were doing it, but we didn't have the tooling to make it available everywhere. And so the first version was not, you know, did not use any AI at all. But some of the later iterations, especially as we got you know into the second half of 2025, began to use it more and more. So we used it for development, some data analysis and experiment setup. And so in the beginning of this year, as we really continue to optimize the bubbles experience, I would say AI has done, you know, nearly all of the development, a lot of the initial paths of experiment analysis. All of it still requires, you know, human eyes on top of it, but it's greatly accelerated our ability to iterate quickly and iterate through a few different options because before we could had, you know, we had to be really targeted in which things we tried, which tests we ran. And now we can sort of try it all because we can run it a lot faster and really more quickly identify the best candidates for each aspect of it.

Pascal: I actually need to try out experiment analysis. That actually sounds super useful. Yeah, and previously it's just really hard when you have so many different metrics to track and figure out like, okay, this goes up, this goes down, what does that actually mean? Super Shri, do you also had certain kind of power ups through the use of AI in your work?

Joseph: So helpful.

Subasree: Yeah, I know Gen AI is sort of the new cool thing, but here we are using AI basically through traditional ML models to build a feature that powers the recommendation systems. So suddenly we are using AI to recommend products on our Facebook platform. But again, using AI to build AI is gonna be pretty cool. So like Joseph said, we definitely used AI to do a lot of data analysis to extract insights.

It's like having a fast, you know, pair programming partner or data scientist who never gets tired. So it meaningfully helps speed up our iteration cycles that matters a lot when you're trying to ship and learn quickly at scale.

Pascal: Yeah, that's a great answer. Okay, we slowly need to wrap this up, but you're obviously just two people of a larger team or even multiple teams, so I also wanted to ask who your collaboration partners in this were and who else kinda helped in building this feature.

Subasree: Yeah, Friend Bubbles actually touches almost every part of the Facebook video recommendation stack. So our collaboration was quite broad. On the ML side, we had a bunch of engineers work closely on the video side and also partner with the closeness, user-to-user closeness and friend graph team for building the models for scoring the Friend tracted content. And on the client side, we had Joseph's team building the iOS and Android experience and also the performance optimization team.

Who worked closely with us on the architecture for and also for improving the latency and capacity aspects of the pipeline. And we also had a user research team in the early stages of our product to be able to collect feedback from real-world users when we were prototyping a lot of the product. And designers worked very closely with us, data scientists to be able to tell us what's resonating with users.

which cohort is more efficient for this product and so on.

Joseph: Yeah, and we also had some surprising collaboration partners like you know, people on the feed. this feature was also shipped on feed. And so when they spun up this project on their end, we spun up a collaboration with them to share some code, even things like the post tap experience that we iterated on and share learnings as well that helped accelerate each of our projects forward.

Pascal: Fantastic. And then maybe as a last question, are there areas you are now thinking about investing as well? Or how do you basically envision bubbles evolving over time from now on?

Joseph: Yeah, I think right now a lot of the focus is in inventory expansion of who gets to show in bubbles and what types of engagements show in bubbles. And we're experimenting with a few different additions there. And then on the modeling side, there's also a lot of work around improving the relevance and even improving the relevance of the bubbles themselves. And so things like making sure the reactions we show to you are actually meaningful, they are useful.

not just the friends whose reactions are showing on there. And that really helps improve the quality of the video that's being recommended itself. So now it's really a lot of tweaking, some expansion, but really a lot of tweaking to make it more and

Subasree: I'll add to what Joseph just mentioned. Prevalence and relevance are definitely key for this product. And when I say prevalence, we want to increase the distribution of videos with bubbles. No matter how great the product is, if it's not really visible to users or it's not widely shown on the Facebook surface, then we're not being able to improve the user experience. So definitely prevalence matters. And on the relevance side, we're also looking at capturing

more granular interest signals on the user videos and launching advanced ML models to improve the recommendation for the videos and user-to-user closeness models.

Pascal: So as you're working on the kind of next iteration of models, how do you roll them out safely to so many users?

Subasree: Yeah, at Meta scale, even a small model change can affect billions of people. We have amazing experimentation frameworks here. We try to be ambitious but also cautious at the same time. So we start with internal dogfolding. Employees use the feature first and then give us feedback so that catches the obvious issues before anyone outside meta sees it. Then we move to a small cohort tests or a handful of markets where we can monitor everything closely.

So we look at engagement, system health, crash rates, user feedback. And each phase is a gate. So we don't move on to the next one unless the data tells us it's safe and the experience is solid. And then we use the A-B test results to interpret and do some data analysis to understand whether it's like driving the metrics that we care about. It's within the guardrails. So we're also we don't just flip it on to everyone and have the product rolled out.

But instead we start with a smaller set of users and then gradually roll out again after monitoring all these metrics. So we don't overwhelm the system, but also have the right checks and balances in place.

Joseph: There's also a piece in the experiment design, which we also consider other experiments that are running that might potentially conflict with our ability to do clean analysis. And so in the initial version, especially, there are a few different experiments that would potentially interfere with this one. So we had to come up with a sandboxing system so that we would experiment in isolated environments and then slowly test how these things work together in production before fully releasing.

Pascal: Right? There's just so much care that you put into all of this and it is completely invisible to the user, to them, if your bubble showed up on the surface that they are probably used to. But that's why I love these kinds of discussions, because you can really peel back all these layers and reveal how much goes into building something like this. So Joseph and Suba Shri, thank you so much for joining me here and for building ways we can build stronger connections.

With all our friends.

Subasree: Thanks Pascal for inviting us.

Pascal: And that was my interview with Subasree and Joseph. The thing that properly stuck with me is how iOS users were essentially indifferent to the feature until the team sorted out scroll performance and then suddenly all the engagement metrics lit up. It's a brilliant reminder that it doesn't matter how clever your ML model is or how delightful your animations are, if the whole experience feels wrong. Performance isn't a feature, it's the foundation everything else sits on.

If you've got thoughts on this one, or you're on tale of a simple feature that spiraled into an engineering odyssey, drop us a line on threads or Instagram where we are at MetaTechpod, or fire off an email to techpodcast at meta.com. But that's it for another episode of MetaTech Podcast. Until next time.