 I had a fault, broke two of my fingers and that was when I discovered that God must have been a really bad engineer because every damn thing is connected. But more important than that, as I was using common things like the toothpaste, the scissor, the Sharjell, it really made me understand the importance of inclusive products for users. And what I mean when I say inclusive is for everybody. And it is my sincere hope that as you walk away into your respective workplaces, you really think about user inclusiveness as your goal built in your products by deliberate design. So with that, I just want to get started. So this gentleman out here in blue turquoise shirt, he's looking for a blue bag with a sling. So he goes to his favorite merchandiser Flipkart and he types blue bag with sling. And he knows exactly what he wants, but he just can't find it. So that's what we're going to be talking about today. Just a couple of words about Lumre. So we have, we are broadly into the search space. We have a suite of solutions across search, navigation, personalization, merchandising, and organic search. And this will be the structure for this talk. So we'll talk about e-commerce, you know, but in a very 30 feet, you know, narrow down perspective from a search search perspective, introduce a taxonomy in that, and then we'll talk about, you know, the page that you as a user see, which is what we call a storefront. So what is going on behind that storefront? And then we'll talk about two specific problems in search. And in this, I'll introduce or at least mention about some of my key, you know, personal learnings about influencing product design. So an e-commerce ecosystem at a 30 feet is made up of independent merchandisers, broadly, you know, original equipment manufacturers such as, you know, FabIndia. So they, they are merchandising, you know, the whole end to end. And then there are marketplaces such as, you know, Flipkart, Snapdeal, that probably have a bit of, you know, original manufacturing also, but they really bring together a group of merchandisers. And then there are, you know, technology providers such as BloomReach and other players that help these merchandisers in the ecosystem solve, you know, very specific problems. Now, what is happening when you're walking into a e-commerce or let's say, you know, like a physical store, right? So the merchandiser obviously wants you to discover new products, right? So imagine you're going into a physical big basket, right? So there are these aisles and you have, you know, all sort of candies and assortments and stuff. So discoverability is definitely one goal. The merchandiser also wants you to engage with those products. And what I say engage is, you know, the physical act of putting them into the cart and potentially converting. And at the same time, the merchant obviously cares about, you know, business outcomes, which is about, you know, driving incremental revenue, because that's where, you know, the money is coming from. To get you, you know, a quick peek into search, right? So this is a red dress. That gentleman out there in the red dress, in the red shirt, he's looking for a dress for someone. Let's keep it, let's keep who it is out of the question. So he's searching for a red dress with a corset for someone. And he types something like a red dress with corset, right? If he's lucky, the merchandiser describes it as red. But more often than not, we've seen people describe the same red dress using 148 different colors just for the attribute red. So you would see purple, plum, lush cotton candy, you know, red, crimson, ruby, garnet. I don't even know those shades of red. So that's what we're talking about. Now, this was one attribute. I think your mind quickly jumps into the space where, if there were different attributes, so this is a teal herrington cotton throw pillow. And people are describing it using cushions with turquoise, aqua, blue colors. That's not going to surface if there was just some sort of a regular match for lack of a better word, right? So that's the space we're talking about. Quick taxonomy. So there's a user, that lady out there. She potentially has a segment, and we'll talk about the user segments in a bit. She has some driving needs, and needs are really important in any sort of commerce, you know, digital, non-digital physical commerce, because, you know, you have a need that is driving you to buy a product. In most cases, they're not, right? So you could have a usually driven needs such as, you know, you want to buy a packet of salt, or you have, you know, a luxury exclusivity sort of a need in which you want to buy a luxury watch, right? So understanding what is driving that need, or at least in some part reverse engineering those needs, is something that we're going to see later here. So that lady, she shows a search query which signals her need or the intent, and when she does that, she sees a search results page, which is what we call a storefront, and that storefront has multiple projects, products, pardon me, each of which has a purpose, and potentially, you know, each of the product has a, that has a purpose, has a positioning in the mind of the user. What I mean by positioning is that the same watch, which is a luxury watch, can be positioned as a utility item versus a, you know, like a really, you know, high end desire pertaining to, you know, vanity needs of a user. So that's what positioning is about, and e-tailers actually try to leverage that when they think about, you know, how do I position my product in the market? So I said that we were going to be talking about two problems, this is the first problem. This is a problem about cart abandments. A typical flow in our e-tailer is, you know, somebody initiates a search, views multiple products, adds them to cart, and converts. This is the normal regular flow. So what we were seeing in this e-tailer, so this was a sports merchandiser, was that people were viewing a lot of products. They were adding a lot of products to cart, but they were not really converting. You know, and one could potentially say, hey, but you know, like people add stuff to cart all the time, right? Like you're walking into a physical store, you add stuff, and then you change your mind. But this was happening in a very weird situation because, you know, the gap between the two goals that I talked about earlier, right? Discoverability and Engagement was a lot. Personally, when I see any of these problems, you know, it's very easy to say, hey, let's segment X, Y, Z, and then let's segment, you know, Y, Z, you know, in multiple other dimensions. But that's, you know, if you're looking at it from an end goal, you know, from the perspective of synthesizing what you've just learned, you know, what is the purpose of segmentation? The purpose of segmentation is one, for you to isolate what the problem is, and two more importantly, for you to actually go back and say, hey, given that I've isolated the problem, this is what, you know, is driving that, and can we fix it? So this is a framework called MESI that comes from traditional consulting. It's called mutually exclusive, collectively exhaustive. So in the discoverability and engagement gap, you know, one potential way for you would be, if you wanna segment along the queries, you know, take the same queries, divide them into well-formed, so well-formed would be queries that have, you know, natural text, versus queries that have alphanumeric, meaning, you know, some numbers and some special characters, and then take it further from there. So this is just one example. So what we saw in this example was that, like I said, you know, people were viewing and, you know, adding to cart, but not really converting. And what we found out using one of this analysis was that, you know, most of the popular sizes that we were showing on the storefront were really out of stock. And what that led us to conclude was that people were like really using carts to bookmark. Now pause here for a moment and think about, you know, if you're looking for a Redmi phone and the user does not have a favorite or add to wishlist, any sort of that button, what are you more likely to do if they allow you to add to cart if the product is out of stock, right? So this was a, so if you cannot add that single, you know, that particular Redmi phone, you are more likely to add, you know, maybe like a different color of the phone, right? So this was what was happening here, but in the context of size, you know, anybody who's seen that problem from an external perspective would say, hey, but the problem is simple, right? You just identify that the query blue jacket XXL is a size query. So it is triggering that a user is looking for a particular jacket, but that is just the tip of the iceberg because more often than not, you know, even if the query explicitly had a size, it is very difficult to identify that the query, you know, the query that's, that don't have a size explicitly mentioned. So you can assume that most of the queries, unless they are in electronics and other department that don't have a sizing sort of a constraint, sizing for a lack of better segment, have the exact same problems. So the first challenge here was that, you know, obviously there is a custom size per merchant, which meant that any sizing map that we had to prepare had to be, you know, for that particular merchant, but more important is that that size map had to be category aware. And what I mean by category aware is that a shoe size, which is talking about eight, one by eight, or eight and a half is different from eight and a half in let's say hats, if they have eight and a half that maps to hats. So we synthesize the goal for this exercise for us was, okay, we just figure out what is the availability of the SKUs to just re-rank that store product so that we will just show the products that have more availability factor, right? So you're obviously going in a very probabilistic point of view by saying, hey, you know, if I show them the products that have more availability overall, maybe the user is gonna add more of these available items. Algorithmically, this meant that if your ranking function was a function of x2, x3, x4, which are proprietary signals, you're just blending one more factor in here, which is called availability factor. Sorry. And like I mentioned with the goal, sorry, like I mentioned with the constraint, so this obviously means that we need to understand the real distribution of sizes across the hats, across all the leaf categories. So we did what was required of us. We ended up clustering these sizes. I'm not 100% sure if you can see it, but I'll read it out for you. So in the second row out here, there's the shoe size, which is eight, one by eight, nine by 10. So you would see that there are these sizes, but the strange thing here also was that there are these sizes with M slash L, and M slash L was also a size for the shirt, right? Or a free size. So that was about the shoes. There's another thing for the new ones. So new ones has 18 months, nine to 24 MO, three to six MO, nine MO, new ones. So basically, essentially what you're doing is that, because the merchandiser is never gonna give you a comprehensive, cleaned up, beautiful state of their size map, you end up creating that size map in-house, and you do two things from a product perspective. The first one I mentioned was the availability factor. So the way that we defined the availability factor had to be really simple so that it works real time when we're serving the results. And when I say I'm serving the results, so somebody types a blue jacket without the explicit XXL, and at that point of serving, we know what the availability factor was. So the way that this was built was we had our product DB. So product DB had, so when you're serving a product, on behalf of the merchant using an API, you would know what are the products that are in stock. So you can calculate that availability factor using this formula that we did, which is nothing but total inventory for that product category pair divided by the total sizes available for that category. So that was the first thing that we did from a product perspective. The second thing that we did was more from an education, you know, more from an education and understanding perspective for a merchant, where we took this data back to the merchant in terms of the gap between the demand and supply, and we told them, you know, hey, there's a good, you know, there's a good opportunity for you to align both these driving factors that you are seeing live in the market to actually, you know, fill your inventory. This is a problem number two, which is about handling special events. So for any merchant, special events are really special because obviously they drive a lot of traffic, there's a lot of revenue at stake and stuff like that. So, but special events have special challenges. So, you know, think of it, you know, just pause for a while and, you know, take a step back. What really happens in these special events is, let's say Flipkart, Big Billion, Sailrite, everybody relates with that, is that they expect the demand to go up, right? They really, it's a deliberate part. So what they do is that they have their merchandising teams that have, you know, very focused campaigns that are doing a lot of retargeting, you know, over and over to a lot of users on the web. So basically what happens out of this exercise is that the demand patterns of the users shift. Now that is important because if the demand patterns shift, then if your algorithms, you know, property algorithms were feeding on historical data, you will have very little signal versus the noise in those signals. So this is not in line with the intent at that point in time. More importantly, these are short-lived events and again have the same problem with not being able to rely on the historical data because till the point that your algorithm learns, you're gonna be losing that. The third challenge is actually, which is something like very well documented in research. It's called the Britney Spears problem, which says that Britney Spears as a term has always been popular and trending. So how do I separate the trend from the popular facts? And the fourth one is that you might think that, okay, if a merchant is gonna introduce new products, I'll just do a fair bootstrapped impression. So what I mean by this is that if they have a product P1, P2, P3 that are new, for any query that has a match to, in this set of P1, P2, P3, I'm just gonna surface P1, P2, P3, but that doesn't work. And it doesn't work because a merchant has a conflicting goal, or at least you as a technology provider serving for that merchant has a conflicting goal because you obviously wanna prevent the starvation, but you also wanna optimize for the business performance, which is where your incremental revenue comes in. What we ended up doing here was a mix of opportunities and I'll talk about each of them separately. So the first one was something about new products. So think about what is happening when, when any of these special events is coming, right? Big billion days sales. So there are new products that are gonna be coming on the marketplace. There is a new intent or a new needs. What I mean by new needs is that, when there is a sale, you buy stuff, right? So you would buy things that you would otherwise not buy. So we see queries such as sale electronics. Now, what does that mean? Are you looking for mobile? Are you looking for a consumer good? So there's a new evolving intent. And the third important thing is, so remember I talked about the merchandising teams that prepare for this demand. So it's a deliberate part of preparing the minds of the consumers for these intents. So is there in some way in which a technology provider like us, that is remote from the merchandising teams can actually reverse engineer, you know, their plans and use it to drive the business outcomes that matter for us. So let's talk about new products first. So what we do for this task is that we have a product feed, which we call a PDB. We take the PDB on day one. We just take the delta of it from the previous days. The delta is telling us the new products. As simple as that, right? Assuming the PIDs are not gonna shuffle and change and all of that. So what we ended up doing was finding these new products. Then we obviously knew that for these new products, we don't have any data historically. So can we find for these new set of new products, cohorts from the historical data that actually have the historical performance? So what I mean by historical performance is that if we know that the top two products actually performed good, then can we borrow their absolute goodness, which can be a number, right, in terms of the algorithm? And sort of translate that goodness into its related product, which is a new product. With me, okay? So, but the moment we started quantifying this relatedness, a lot of, you know, ad hoc things started to surface. So I talked about the marketplace sort of a model, right? So any merchant has two broad kind of, you know, products. So there are obviously regular products, the ones that you can definitely see with 854. And then there are products that are clearly marketplace. So when I say marketplace, that's just a name for it. The segment can also mean, you know, driving some vanity or, you know, lower price. It can be anything, but it's just that the relatedness is different, right? So that's about driving the point. So in this case, if you see, you know, the first one really looks like Swingline high capacity desktop stapler. It looks like an ordinary stapler. But the last three are Swingline, NFL, Washington, Redskins. So it is for somebody who really knows or follows a certain team, you know, in basketball. And so the notion of, you know, relatedness really is subjective. The second interesting thing that we did was that, so there was a colleague, you know, who built this tool called Muse and we quickly figured out that we could, you know, just leverage that same tool. So what we did was that this pipeline that dumped, you know, new products and the related products, it just loaded that schema. So imagine there's a single product P1, which is a new one and there is a related product P2, P3, P4, P5. For all these related products, you have their product IDs, you have their product brands, you have their product title. I mean, you can potentially get more. But what we did here was that we load the schema programmatically just for a benchmark. We don't do this every day. And then the product analyst team could go here and select, you know, yes or no. So at the end of this task, we would know that from the notion of the relatedness that we define, how much of the notion is supported by human judgment. Right? So that was the point of this. So to repeat what I just said, right? So there's a new product. There are related products. Each of the product has its name, has its title. So when somebody looks at this, you know, because you're looking at it in a row, you know that probably, you know, three or four products in this are related. So you would say a yes or no. And the QA team actually had a way, like a objective way to say, when should I select yes versus no. So we define a borrowed score where a borrowed score for any product was a factor of, you know, the related products, MLT of the PID, more like this of the product. There was a decay factor, obviously. And then there was a notion of relatedness. And then you use that score back and you re-rank, you know, your products. So that was about new products. We talked about three other things, right? Let's talk about the redirects and campaigns first. So the first query that you see, people actually type that query, women's Villanova, Wildcat, Navi, Blue, Classic, Arch, Full, Zip, Hooded, Sweshtart, right? So what merchants do, you know, what merchandising teams do is that when they're expecting very specific search intents, they have something like a phase match sort of a rule. So what that would mean is that they put these curated pages and they want to intentionally drive all the traffic to this. So there are two broad reasons to do this. One is that if they were gonna be paying a technology provider like us, incremental revenue, and they know that their team can do at least as good, they don't want us to serve that experience. So that's the business thing. The other is if they expect this page to be a lot more, you know, changing in a lot more manner, they won't maintain that control in-house. So that's why they would set the redirects. So if you see this page and I really encourage you, you know, as you go do your digital commerce, you know, whatever it is that you buy, just look at the sort of pages that come there. So this is a redirect. Then the second page is a product or a category page. And remember that earlier, we were talking about the needs that was driving the purchase behavior of that lady. So the needs, if you just again look at the, you know, some of the URLs, you know, when you use the filter, so imagine you're going to a big basket or a flip card, you can do sorting by filters. And all of that obviously is logged. So people who are actually looking at data know that for a salt, probably, you know, you just don't use any filters versus for, you know, versus for Kellogg's, you're looking for top rated. So you know, you know, there's a, there's a quality aspect to Kellogg's, but not so much to, to solve, for example. So there's exclusivity, which you're seeing by in US items. So obviously, you know, these, the, the URLs or the, the end of the suffix of the URL is going to matter. It's going to look different for different merchants, but just by sort of like experimenting. Okay, that's fine. So just by sort of experimenting there, you can see or in for back the user preferences right from your web logs. Then there is a notion of, so we talked about exclusivity, vanity, you know, quality and spend thriftness where people are looking for lowest price. Then there are campaigns. So mostly campaigns in the URLs, both, you know, are logged. So if you open a campaign in your email, right, there are two reasons why, why a merchant gives you that. So one is that it reduces the cost for, for, for you, like the cost of acquisition for you as a user because they don't have to pay Google or any, you know, search engine to drive that traffic. The other is that they can track you. So you would have this campaign thing out there. And then with the campaign, you can also have a query. So if somebody is coming from that paid search of, of Google, the front page with a query, they know exactly, you know, what was it that is driving you? So whatever we have done, you know, in the, in the previous one is actually helping us, you know, decode that user experience. So, you know, one more thing that we did was that we obviously run a lot of A, B tests with other vendors, you know, in this market. So imagine a merchandisers running Bloom reach versus a different vendor, why? And we just wanted to benchmark, you know, how are we going, doing good with the queries. Now, obviously, you know, we can't do it, you know, we can't do a human creation for all the queries that they serve versus we serve. You obviously can't do the scraping because that's like very prohibitive to do it for all the queries. So what we ended up doing in this exercise was take all the search queries, right? All the search queries. Take each user, for each of the user, just take, you know, all the queries and their pagination depth. So pagination depth is anytime you see the first storefront and you click next, right? Again, you know, do it, you know, when you're doing your digital commerce and you will be able to read it to it more, the page would change to PG2 in the URL and then you'd click next. So you can do actually two things. If you just change that page to three, it would automatically change if you want to like really cheat. Or if you want to do like next, next, next and you go to page number 10. So this was more like an analysis not so much on the product design was that we found out that on an average, this final four, which is a query that refers to, you know, the final four teams that made to a basketball tournament were doing worse off because their average storefront that people were going to was four. And then versus such, versus hoodie sweaters which had an average of two. So which means that, you know, our search results potentially are better for hoodie sweaters than they are for final four. Also because, you know, final four was little more on the, you know, natural language processing. So we really need to understand that this query is trending and probably the intent is not meeting. So again, for you to relate to it, think about what happens when a team makes it to the IPLs or something, right? You're looking for that specific branded merchandise and it's a very hard problem to solve. Then I introduced this, you know, notion of the needs. So if you look back at this notion of the needs, right? There are very, you know, I would say maybe like trivial ways, like not very data intensive, but trivial simple ways in which you can see what queries or, you know, what query segments or clusters are actually having different behaviors. So one possible behavior would be, are people brand sensitive versus are people price sensitive? So that's the first level of the question, but the more important question is the question behind the question, which is about, what are you gonna do if you know that? Are you gonna change your, you know, the way that you serve those results? Because I think if you don't have the answer to that question behind the question, you know, it just becomes a piece of analysis. We also talked about dynamic faces when I said, you know, the mix of opportunities. So dynamic faces is something, again, go to Flipkart, you see, you know, on the left hand side, you know, when you type mobile phones, there would be Samsung, you know, the brands. So there'd be one segment for brands, there'd be another segment for the screen size, there'd be other for the RAM, processor, so on and so forth. So the way that this comes in the logs, I know you're probably thinking, oh my God, everything's locked. So for vcellstuff.com, there is a dynamic facet that's coming for a query such as who did sweaters. The facet is clothing hanger, and the type that is selected here was accessory type. So now you exactly know if you were gonna take this exercise, do it on a macro level, you know what matters in what query cluster. So that was the point that I wanted to drive from that. You can reverse engineer almost everything. So what we know so far, consumers really have different taxonomy. You know, I like to speak of it like this. So imagine, you know, you're walking into Taiwan, right? And you are a native German speaker. So you say, where is the Taipei 101? And you are really asking, you know, where is Taipei 101? But the Taiwanese native speaker doesn't understand that. So there's a language mismatch, right? So when you think about, you know, serving customers, and I was talking about, you know, inclusive products for the customers before, think about how they speak, how they describe what matters to them, and what their driving needs are. And then look at the products, all the basket of products that you are gonna be showing them, you know, what is it purpose and what is it positioning? And just match this, right? So it's like a match making exercise at best. These are some of my final learnings. And after this, I have a quick experiment for all of you. So isolate, like I said, you know, mutually exclusive, collectively exhaustive. Isolate first, synthesize. So synthesize what you've learned. Commoditize, meaning after you've discovered it, if you were gonna be doing this again and again and again, how would you do it? And scale, right? Because with commoditizing comes scale. One anecdote here, so, you know, when you're working with teams that have bizarre amount of data, it's often that people say, hey, can we segment in XYZ way, you know? Of course you can, right? But why, right? So one of the things that I learned, you know, working with my teams was always, you know, stepping back and asking them, okay, given that, you know, whatever you're asking for is given to you and it does not fall in line with what you were expecting. How is it that you're gonna change? And I think that single question saved me a lot of time because sometimes people would be like, you know, oh, it's just good to know that people are brand aware versus price aware. So I was like, okay, so basically you're saying, if I give you that data, you're just gonna be looking at it and forget it. And sometimes people would try to make up the answers, but I think it helped us all get in a state of mind where we actually, you know, became, you know, hypothesis driven in a true sense of world rather than just saying, you know, we do A-B testing, we are data driven. So the second thing I wanna say is, you know, common sense math beats data science. I think I forgot to mention one thing here. So this thing with the dynamic facets. So if we look at this query chair, right? So the chair, if you're able to see, it has a color family as the top most related facet and then it has a department and stuff like that. So if you look, right, this is a simple word count after you've written a simple, you know, Python, like you're just parsing your logs, right? So what you're doing is that you are reading a URL, you're breaking that URL, in that breaking URL, after that you just process the file, just do a plain word count. And then look beyond your cursory toolkit, which is really about if you had, you know, XYZ, you know, from the URLs that I just showed you, you know, can you look at them, you know, in ways that you've not seen before? Then there is, you know, matching the intent to the purpose, which is more like a matchmaking sort of exercise. The other important thing is for you to think about, you know, if you're gonna be segmenting, can you segment to the level where actually a difference is gonna appear, right? Because if you segment, you know, repeat users versus non-repeat users or well-formed queries versus non-well-formed queries and no pattern emerges and you say, you know, add to cart rates are still falling, I segmented XYZ, but I don't know why, right? That's not a state that we wanna get in. And the most important learning was, you know, I think reverse engineering, both the user preferences or a merchandisers actions, in which case I showed you the redirects, always works, like always works. And the beauty of that is that once you have done it, you can like just scale it for all the merchants that you have, because as bloom reach, like we have multiple, like we are not an independent merchandiser, right? We are technology providers, so we would do it, for example, for Flipkart, for Snapdeal, for BigBasket. I mean, obviously those are not our actual logos, but you get the point. And before I take questions, I just wanna do a simple exercise to drive home the point that I was trying to make. So you got this pen, you know, outside, you know, when you were registering, shame on you if you don't have this pen. If you are a right-handed, raise your left hand. Okay, if you are left-handed, raise your right hand. Oh man, there's no one, okay? One left-handed. If you can use both your hands, please raise your hand. Okay, people who raise both their hands, you know, I don't need your hands, but the hand that you raise, which is your non-dominant hand, just take your pen and write your name in the piece of paper that you have. Just write your name. The non-dominant hand, the hand that you raised. Are we done? Do you guys have the pen? Just pick any page, man. Use your non-dominant hand, please. Done? Yeah? Now raise wherever it was that you wrote a piece of paper, whatever it was you wrote with your non-dominant hand, just raise that. Yeah? Yeah? So when you wrote, right, this is what inconvenience feels like, okay? And I know that we have probably the best of, you know, engineers, designers, best of everybody in this room and probably the people who are seeing it in the next room. So I just wanted to drive home the points that, you know, drive home the point that, you know, when you are designing products, right, designed with the user inclusiveness as a deliberate goal because that matters a lot. That's all I had. Thank you. I can take questions. So, hello? Yeah. So you told that common math beats the data science. Okay. So you were saying that common math beats the data science. I didn't understand that point, basically. So what I wanted to say was that, you know, sometimes as, you know, when you are building products, right, and you have a formal way of doing things like clustering and stuff like that, some more often than not, people forget the end goal, right? And they go for very non-trivial ways just because you have the toolkit, just because you know how you would do clustering does not mean that you should, right? A doctor would not use his scissor if he can just do away with the pen and give you some prescription. So that's what the point is about. So I wanted to know, yeah. Can you hear me now? I wanted to know if you, how did you get the relatedness of products? How did I get the- Similar products. Is it manual effort or you have- No, so there were two things that we did. The first thing, because all of this is coming from Solar, so I'll just repeat his question. So he was asking about how do we get the relatedness of products? So in Solar, if you give any product, you have something like a MLT, which is a more like this call, okay? When you get a, when you give it a more like this, you would get potentially like 20 to 20, and each of the products, I think by the way the Solar call works, is done using a, like some sort of a TFID of sort of approach. I could be wrong there, but it's just a notion of, you know, it's just dumping those 10 to 20 products. So what we did was that we picked up the first five for these, because we wanted to do like QA, but the second part of that was that when we just did that, even when the notion of relatedness worked, we saw that there were these kind of, you know idiosyncrasies where we could definitely see that there were different segments. So that's a harder problem to solve, but the first one was easy. Yeah? I can't hear you. Sorry? Oh, okay. What is the text tag? Okay. So we have, we use, we use Cassandra for processing the feeds. You know, we have a lot of, because we serve traffic for these merchants, right? We serve search traffic. So we use a lot of like logging tools. We have folks here who can describe that better. So I think Nginx, Graphite, you know, and a lot of other of those, but from a serving side, we use primarily Solar. And what we do is that for each of the proprietary signals, what I mean by proprietary signals is that if you have queries and you want to know for this query, what were the products that converted? We have those as QD, we have those as files. So basically we load those as external files. So I think that is where most of the real meat in the system goes. So, you know, there's offline pipelines that run, that feed to it on an everyday basis. But primarily I would say, you know, it's Solar and Cassandra, the main pieces. And then there's a huge amount of monitoring, you know, monitoring infra. And then there is, you know, of course, the whole of the Redshift and AWS stack. Hello? Cassandra? Cassandra, yeah. No, I'm not an intro person, so maybe like my language is just off. Hello? Yeah? So you talked about understanding what the user wants when he's querying for something, like you gave the example for a bag with a slap, yeah, so something like that. So, and you said that might not necessarily match the description that the vendor gives. So how do you overcome that? So there are two things that happen, right? So the first thing that happens is, you know, obviously it's a difficult problem to solve. So multiple ways in which we solve it. So if we are seeing, you know, a person who's typing, you know, blue bag with sling, he doesn't find anything, right? He would then type blue bag with a strap, probably slap matches, probably not. And then he would type something else and still not get it. I'm just describing you the most, you know, negative case. And then probably he would go surfing and then probably he would add something to cart or view a lot of products. But the main challenge is for us to actually figure out that all of this was the same, you know, intent. I think that is the hardest problem that we've solved. And what we ended up doing, so there were different ways in which we solved this problem was that we identified that sling and strap and, you know, the other products that were, the other description that was a part of the product was actually the synonym. So think of it like this, right? If I have to search, you know, a blue bag with a sling, I have a some notion in some notion, I have just appended that text so that it can match as simple as that. Like on a very intuitive level. Hello. Am I audible? Here. Okay. Hi. So it was very interesting you're talking about user inclusivity in product design. How many non-English queries do you see people attempting to search at e-commerce sites? I think I don't have that number on top of my head but we do, we do, we do. No, so actually I think earlier this year, earlier this year we actually started getting into multi-language. So it was not so much driven by, so yeah, so there are two things, right? So user inclusiveness by deliberate design is also, you know, should also, you know, translate to business outcomes, right? So I think earlier this year we got some merchants that were really, so imagine, you know, Flipkart was gonna go and sell in China or Flipkart was gonna go sell in a, in a European sort of a language, right? Then it makes a business case for us to actually build products. So he was asking me the question about the sling. So one of the first things that we did to improve search on these non-English languages, which was where we were at that point best at, was to start that effort around, you know, the synonyms. So there's a colleague who just does this thing and he does it like so well. So yeah, so around, so to answer your question, I think one it was user inclusiveness was very much driven by the business case there. But if you ask me what are the numbers that we would see, I don't know. Adding if new products come, we do not have it's historical. Yeah. We find its goodness based on its relative products. So based on which similarity you decide that this product's goodness will be related? Yeah, so I think that was the question that he was asking. He asked it a little differently. So basically in Solar, which is the search engine if you would, like that helps us serve. You have a call like MLT, which is ideally based on a TFIDF. So what TFIDF does is that, you know, I spoke about it the first time, you know, when I spoke on the same stage. So I'll probably use that same example. So imagine that you're searching for a job, okay? So there's a job one, job two, job three on LinkedIn that probably meets your resume, right? So TFIDF is basically that algorithm is just telling you how much match of your resume, physical resume on LinkedIn is with each of these jobs. So the more like this at a very abstract level is doing essentially the same thing. It's finding this particular document, which is your resume, how similar it is to these others, and it's sort of ranking it. So that's how it is doing it. And one more question. It might be based on text data. Sorry? Both having text data. Yeah. And LinkedIn. Then the frequency of words or LinkedIn or LinkedIn? So like I said, we used something that was off the shelf and the reason for really doing MLT was that, you know, we were just preparing ourselves for these special events. So if you ask me, you know, how many new products come on an everyday? Very few, like very few, right? Or they would just come in a pipe, like, you know, they would just come as a bulk. So when a merchant is sort of on, you know, ramping up a different seller altogether, right? So they, so for example, we've got now signs up with the, Minthra has signed up with a private label HRX, which is Rithik Roshan's brand, right? So now they have these new products that are flowing in. So in that case, if you think about it, right, if there are these big bulk products and they are like really different, they don't even have related products, right? To your question about the context, I think context really makes sense when you are applying it with intelligence, because, you know, if you just fire, you know, MLT and you just don't even do a QA, which is something that we really took it to the heart, it was costly for us to even be doing it for just these special events, you know, for, let's say if we have four merchants and if we wanna see the parity across all four, it was costly, but to your point, I think it was a mix of both using that with the goal that we are not gonna be seeing, you know, this use case multiple times over. If we saw, probably we would have invested a lot more effort. So I'll take just one more question, yeah. I can tell you how one would solve that problem, but personally I've not worked on it. So a couple of ways, actually, not just one. So the first thing you would do is that you would see the queries for which, you know, you are seeing these brands coming in. One cheap way for you to do that would be from this, you know, faces, you just rank them, and in the faces you would see that people are selecting. So now you know that there are these sufficient, you know, brands that are coming, but what you really care about is the overlap between, you know, users who both have Edidas and Nike, and that actually was related to what he asked in a different context was that, you know, if I know, do I know that Sling and, you know, Strap are sort of related, right? And in this case, you know, it's not a question about absolute relatedness, but about, you know, can I replace a user's need with Nike if not Edidas? So that's about seeing what is, we call something like a co-view session. So basically, in that user session, what else has he co-viewed, right? So we do a fair bit of it with our personalization team which sits out of Mountain View. So what they do is that they have, like, user profiles, and they actually do things like, you know, to this brand, the person has X amount of affinity. To Nike, they have Y amount of affinity, and what they do is that they sort of boost. And I know, you know, because I worked on that ask, you know, that at some point, we got into the point where, you know, if we keep boosting Nike all the time, do people, like, really care about it as much, or do they actually even want to? So I think those are, like, a couple of things, you know, when you're just looking at it, you know, from an actionability point of view. Yeah, yeah, yeah. I'm sorry. So I think we have to break. Thank you so much for listening.