Hey Fort Worth, we're Green River Ordinance and we need you to help out our city. We'll be playing the Fort Worth Convention Center April 25th to raise money for the promotion and development fund. We need all of our fans to come out and support our hometown. The promotion and development fund helps to create really great programming that makes Fort Worth an awesome place to live. This is also the last time we'll be playing North Texas for a while so head over to partyandfortworth.org. Buy your tickets, share this link with your friends and we'll see you April 25th.


Today, I will be talking about right here on the platform. However, let me start with the rotor motivation for what I do. We are this day surrounded by all kind of two-sided matching platforms that are still ultimately trying to do the task to match the buyers with sellers. However, what happened over the years is that we've delegated a lot of decisions to the platforms. So the platforms are usually the ones that are choosing matching rules and the pricing. However, there's still a lot of private information that is involved in all of these markets. For example, the exact realization for the willingness to pay or the willingness to sell over seller and buyer that meet. And that private information affects how efficiently the market works. So it affects the efficiency of a chosen mechanism. So one might wonder, why do we not see markets with decentralized pricing where we would let participants choose the prices? The benefits of that approach are clear, kind of. That would allow for private information revelation. But at the same time, there are some costs associated with doing that. And the costs are coming from the strategic behavior that such decentralization would enable. In this paper I study, how does decentralization and pricing affect the welfare of market participants on the right-hailing platform? And so without further ado, let me introduce the platform. I'm going to be using the data from. The platform is from Russia. It's called Indriver. They originated in 2013. The company grew quite a bit. They are a very global company right now. They are present in very countries. However, so they are essentially trying to do the same task as Uber or Lyft. But there is one main difference that distinguishes that platform. It is the writer who offers the price on the platform. And then the driver can decide whether to agree to the offer price, make the counter offer, or ignore the request. So essentially, it is a centralized right-hailing platform. I'm going to start with an overview of the paper. In the paper, I build an equilibrium model of a decentralized decided platform in which writers are making their own decisions, which prices to offer. Then the drivers decide how to respond to that offer. And then the interaction between these two decisions defines equilibrium matching rates. I estimate the model primitives and demand and supply models are estimated separately. Both are estimated into steps. On the first step, I estimate players' beliefs about the matching rates directly off the data. And then in the second step, I use players' reserve choices to back out the primitives. And then it all boils down to the counterfactual in which I compare the efficiency to a scenario in which the platform chooses the prices, but without private information of the participants. However, I still allow the platform to observe the information that is not private and that the participants have at the time of their decision making. Here are some findings. I actually find that both sides can benefit from decentralized pricing. Among all of the centralized pricing regimes, I can find the one that would be preferred by the drivers. And that's what I mean by an optimal centralized regime. And when I compare that optimal centralized regime to a decentralized setting, I find that drivers still lose around 10% of their welfare. Likewise, I can find what is the regime that would be preferred by the writers. And compared to a decentralized setting, writers still lose around 4% of their welfare. So there are a few contributions that this paper makes. First of all, I consider a unique mechanism in which writers and drivers are making their own decisions. And I also build a novel equilibrium model of a centralized right-hailing market. I quantify the importance of private information on the site of matching markets. Most papers have been theoretical so far. In addition, this paper provides a unique empirical framework to study signal and effect. So the outline for today for me is to go through the data mechanism. I'm going to show you how the driver works, what is the sample that I use, and briefly mention few stylized facts that motivate some of my modeling decisions. I will then introduce the model and briefly go through the estimation and the results and go through the welfare analysis and show you what happens if the platform would be choosing up prices instead. So let me start with the data and mechanism. I have an access to companies internal data set that covers the universe of transactions from a single city. The unique feature of that data set that it contains information about unmatched requests. So I see not only the transactions that actually has taken place, but the ones where the writers were trying to get matched and the drivers were interested in placing the bid. The current sample runs from November 1st, 2018 to November 3rd, 2019. And during that time, I see more than 64,000 unique passengers, more than 3,000 unique drivers, and more than 1.7 million requests. Now that being said, the company wants to keep the city's identity private, so I'm not supposed to disclose much about the city. What I wanna tell you is that the population of the city is below 200,000 people. So with that population, you can see that the platform is very active. To the best of my knowledge, there are no digital competitors in the city during the time of the study. However, there are some traditional competitors such as taxi cabs or buses. The city is relatively compact, has clearly defined boundaries, which allows me to abstract from some spatial considerations in my paper. So I do not model the differences between different areas of the city. Here's the writer's screen. So imagine that you're a writer, and in this case, the screen is in English because the platform was operating in New York for a while. So imagine that you have arrived to JFK and you open an app. What are you gonna see?  So these green small icons represent the idle drivers. And you'll also see how many are there and how far are they. In addition, the platform will identify where you are. So in this case, it knows that you're at the airport and then you have to specify where you're going. So far, it has been very similar to Uber or Lyft. The main difference is that instead of just accepting the price that the platform would show you after you specify the destination, you have to offer your offer there. And here's the field that says offer your fare. And then there's an additional field in case if you have some special requests, maybe you need a challenge here or something like that, you can just specify it in the comments and wishes field. Once you press the button offer a fare, the request will go to all idle drivers. Now, this is the general screen and there are some specifics that I see in the data from the city that I study. First is that I see three discrete prices offered by the writers. These three prices cover more than 95% of the requests. Discreteness comes from the fact that transactions are cash-based and it's just much easier to transact with certain bills. However, conditional on the fact that I see three prices, I still see significant residual price variation once I control for many observables. So since I have very detailed data set, I know where the trip has originated, I know the trip of the distance, I know the time when it happened. So controlling for all of these observable factors, I still see that writers are offering different prices for similar trips. Then it should mean that there's something unobservable that drives writers decisions and in the model that will be coming from the differences in their valuations. However, for the writers to display, to choose different prices, they need to have some incentives. There has to be a trade-off associated with offering different price. And indeed there is a trade-off. The writers who are offering higher prices have higher chances of being matched, all other things equal. Another thing that I noticed and it's more specific to the model, in the model I have an assumption that the writer will try to make only one attempt on the platform. So they will try to get matched only once and if they're unlucky, they will just disappear forever, which is roughly consistent with what I see in the data for the non-rush hours. And these are the hours that I'm going to use in the estimation. So here is the writer screen. Let me then move to the driver screen. Once the writer has pressed offer fair, the request has gone to all idle drivers. And this is what the idle driver is going to see. First of all, he will learn the details of the request. He will learn where the writer is. He will learn where the writer is heading to. He will also learn what is the price that has been offered for the trip. In addition, he will also learn how far is he relative to this writer. So this blue segment here on the picture shows the driver that he is 0.4 kilometers away. With that information, then the driver can decide what to do with that request. And there are several options to choose from. First of all, you can decide to accept the request. And here's the button, accept. There are three options for counter offering. In this case, they are 42, 46, 49. They are recalculated by the platform based on the initial price that has been offered by the writer. There is a schedule for each given price that the writer can choose. And then there's another option which says skip. And that means that the driver can just ignore the request if he doesn't like this request and doesn't want to participate. So a few things that I document in the data. First of all, I see that the drivers prefer shorter trips with higher prices and lower distances. This fact perhaps is not that surprising. It just shows me that they are profit-maximizing on the platform. Another thing that I document is that the drivers are strategic. So if I look at the drivers who are participating in the morning rush hours and compare them with their fellows who are participating later in the morning, what I see is that the drivers who participate in the rush hours tend to reject requests at lower prices much more often so compared to their fellow drivers who are participating later. That again is probably not that surprising because it means that there are more requests in the morning, they can be more peakier and the prices are usually higher in the morning. So it doesn't make much sense for them to get matched with someone at the lower price. And then with all of these buttons you have seen on the previous slide you can imagine that there is some discreteness and sometimes the platform needs to break the ties. So what the platform is gonna be doing it's gonna collect the responses and break the ties. It's gonna prioritize the drivers that have agreed to the offer price. And then among them, it's gonna break the ties based on the driver's distances and rankings. In what follows, I will actually focus on the distance and assume that this is the only variable that matters in the model it will be that but in reality, both of these things matter. Let me then go to the model. All of the observable characteristics that are available to all market participants will define the environment. So such as the examples will be time of the day whether the day is working or weekend weather conditions, so everything that is can be easily observed from this market. Time will be discreet and we'll have infinite horizon. The one, the period will be one second. Writers will be short-lived and they will try to get matched only once. The drivers will however behave dynamically have a discount factor beta. But of course, this is not an infinite horizon game and drivers are not present there forever. So what I'm gonna do, I'm gonna introduce an exogenous probability that the game will be stopped. So the driver might be the last period on the platform. So I'm gonna rescale this discount factor and call it driver's measure of impatience and I'm gonna use it, I'm gonna use delta in the notation. So there are three pieces of the model that they have, the demand side model, the supply side model and the equilibrium. Let me go through all of them. So here's the demand model. The writers will arrive to the platform with the known probability at the beginning of which period. So the probability is lambda. And prior to the arrival, the writer takes draw V which is his valuation to be matched instantaneously from a distribution with a known density. Once he opens an app, once he has arrived to the market, he will observe the market state S. S here is the collection of the number of drivers and their distances. And using that information, he will form the believes data. On the next slide, I'm gonna show you the components of that factor A. The writer will be choosing between two prices, below or a high price. I have previously mentioned that there are three prices that are frequently chosen, but the highest price, 400, is rarely chosen outside of the rush hours and I'm not gonna be estimating model for the rush hours because interaction is slightly different for the rush hours. So instead, I'm gonna be focusing on two prices. The low price here is gonna be 300. The high price here is gonna be 350. And then once the request has been placed, there are three options, there are three outcomes that can happen to the writer. First of all, his request can be accepted. And in that case, he will be matched at the requested price. His request can be counter offered. Or, and then I have shown you that there are three options for the counter offering, but in the model, I actually collapse them to one. The reason for that is that I rarely see two highest options chosen outside of the rush hours. So I'm focusing only on the lowest one. And that lowest one is gonna be 50, and of course, it corresponds to the difference between the highest price and the lowest price. And then the last outcome that can happen is that the writer might be unmatched. So his request will be ignored. Let me walk you through the writer's choice problem.  With some probability and that probability is new, which is highlighted on the screen right now, your request will be accepted. In this case, you will just decide, you will have your V, you will have your valuation, but you have to pay the price that you have offered, or you can just take an outside option, which is normalized to zero. There is another option that might happen is that the request will be counter offered that probability is known to you as the writer. And then you will have to pay a higher price. So in case if you have offered V and you pay a counter offer, the price will be V plus Delta. Or you can take an outside option, which is again normalized to zero. That problem has a relatively easy solution. The solution is the following. There is a threshold such that if the writer's valuation exceeds that threshold, he would go with a high price. If his valuation is within the range between the lower price that has been offered on the platform and this threshold, he will go with a low price. And of course, if his valuation is below the lowest price that he can get on the platform, he'll just decide not to participate or something. One thing to notice is that this threshold depends on S. S is the state of the market. So this is what has been seen by the writer on the screen. So imagine that if you open an app and you see a lot of cars, you should be fairly optimistic. In that case, the threshold would be high for you. So it's very unlikely that you will actually go with a high price or you open an app and you don't see that many cars or they're really far. In this case, the threshold will be lower and you're more likely to offer a high price. And so here is the probability. We can compute the probability of someone offering a high price when he or she's in the state S. And the main takeaway from the demand model is that the price can signal two things. It can signal the writer's valuation and it can also signal writer's bad state. So if we see two writers who are, they are in the same state. So they face the same screen. They see the same distribution of cars nearby. One has been offering a high price. Another one is offering a low price. We can immediately deduct that the one that has offered a high price values this trip more. So this is the signaling. Likewise, what we can also say is that imagine that we know writer's valuations and we don't know the states that they're facing. One has been offering high price. Another one has been offering low price. We can immediately say that the one that has offered a high price faces much tougher state than the one that has offered a low price. Keep this in mind because that is gonna be an important piece once I go to the counterfactual. Let me then go to the supply model. Once this request has been placed, all idle drivers will observe the offer price B. Each driver will also observe his own pickup distance. So this is DI and a random shock associated with the request. So this is gonna be a private information that the driver knows about the request, but it is not known to other drivers and it's not gonna be known to the platform either in the counterfactual scenario. All drivers also don't observe their competitors. So they learn only their own distances. Each driver will choose whether to accept a request, make a counteroffer or ignore the request using this information. Then the platform will collect responses within 20 seconds and allocate the request based on the distance to a writer. So the closest one will get a right. The writer faces a match. If he accepts it, the match is formed. And if the writer decides to just reject the proposal, then the driver will remain idle and the writer will leave the platform. As you can imagine, there are all kinds of different requests that the drivers will be seeing. First of all, the requests differ by prices. So some of the requests will be coming into the platform and they will be having low price. Some of them will be having high prices. They will also differ by the distance to a writer. So there are gonna be some requests that will be very close to the drivers and some will be very far away. I will assume that the private shocks are coming from a normal distribution which is centered around zero, but there is a known variance. And so that the standard deviation is gonna be sigma epsilon. And I assume that the shocks are IED. Each driver will know how much time it will take him to complete a request of a certain type and that time will depend on the distance. So if I'm really far, I know that it's gonna take me a while to actually go and pick up the writer. In the estimation, I add another dimension, how requests are different and that is gonna be the trip distance. However, for the sake of keeping the formulas very short and concise, I actually took it out from the presentation but it is in the paper that's gonna be in the estimation. So trips will also be different by the distances. So then what is the driver will be doing? He will be choosing between these three options except counter offer or ignore. In case if he decides to accept and he wins the request, he will receive a static utility UR that is gonna depend on the price. So the higher is the price, the higher is the utility and the distance, the pickup distance. So the further away the writer is, the lower is gonna be my utility from being matched with this writer. And then there's the shock that is gonna be received by the driver only in the case when he's matched. He will learn about the shock, he will know the value but he's not gonna receive it unless he's matched. Very similarly, in case if he decides to make a control for his utility is gonna be still UR but it's gonna be a different payment. Plus epsilon shock as well. So the shock here is not action specific which is a standard thing I think of the discrete choice. Instead it's a request specific. And so there are gonna be also known probabilities by the drivers to win the request. They are gonna depend on the type of the request that they see. So if the drivers know that the platform prioritizes the drivers who have agreed, the drivers know that they have higher chances of winning the request that they're closer. So all of these things are gonna be in their beliefs and in the equilibrium, the probability that they will win the request conditional on them accepting is gonna be higher than the probability that they would win if they control. The driver will miss 20 seconds if he decides to take any action. So if he participates in any forum, he will spend 20 seconds trying to get matched during the time the platform will be collecting responses from other fellow drivers. And then if he decides to ignore, he will lose five seconds. He will still spend some time studying the details of the request, but still he will get back to the full vital drivers much faster by skipping the request. Here's the driver's payoff.  So epsilon I is your shock. Well, what are, what are you gonna get if you decide to accept that request? With some probability you will get, you will win that request. That probability is highlighted on the screen. And then in case if you win, you get a static utility from that match.  So here V is the value of being idle, which is endogenous object. I'm gonna go through that in steps, how to calculate that endogenous object.  And in that case, you will come back to the full vital drivers much faster. So the continuation value in that case is different. Very similarly, we can imagine how the payoff for the counter offering is gonna look like. There's a probability that he will win the request, but the static utility is gonna be different because the payment will be different. He asked for higher payment and he won. So the writer has accepted that. And there's a probability that he's gonna lose that request that probably will just different, but the continuation value is gonna be the same in case if he loses relative to the case when he breaks. However, for the case when he decides to ignore the request, the continuation value will be different because he will become idle much faster than in the cases above. And so the driver's problem essentially then boils down to choosing among these three options, among these three buttons. And the solution to that is relatively simple. There are cutoffs for the epsilon shock such that if the driver sees a very good shock, he will just decide to accept that request and not take his chances of counter offering it. In case if he sees a really bad shock, he will just decide to ignore the request altogether. And if he's seeing something in between, he will think, well, I might not be willing to drive this writer if I just accept, but if he pays me more, I might be willing to do so. And so in this case, he will decide to counter offer. And we can compute what is going to be the probability that the driver who's seeing a request with a type B and DI will be accepting or making a counter offer. However, the drivers don't know in advance what the full types of the shocks that they will observe. However, they can compute the expected value because they know the distribution of the epsilon shocks and they know that the appropriate probabilities of certain requests arrival into the platform. The last one, the probabilities are endogenously defined. And so then with that information, each driver can compute what is gonna be the value function of being idle. So imagine that there is this whole space of possible requests, there is a probability that that request will come into the platform, then the driver will take an optimal decision and an optimal decision. But there's another thing that can happen. There's a chance that nothing will come to the platform and in this case, the driver will just transition into the next period idle. So this is what this equation below here stands for. Essentially, it summarizes all that. And then there's the last part of the model which is an equilibrium. There are beliefs. I don't wanna overload you with formulas. They are in the paper. However, what is important to keep in mind is that there are beliefs of the writers. These are ades, the probabilities that the request will be matched at different prices. And these beliefs depend on driver's actions. Likewise, the drivers have beliefs. Their beliefs are summarized in the probabilities of request arrivals, so this alphas, and the probabilities to win. And they also depend on the writer's decisions. So this is a decided platform in which each side affects the other side. And all of these beliefs can be computed. And so here's the notion of the equilibrium. It's a rational expectations equilibrium that consists of the writers and driver's beliefs such that the writers are maximizing their expected utilities given their beliefs and the state that they face. Writers actions affect their rival rates. Idle drivers maximize expected utilities. V has to be fixed point of this equation that we have gone through. And then market participants need to have rational expectations so that the beliefs will be self-fulfilling given this optimizing behavior. So I will briefly go through the estimation and the results, because that's not the most interesting part for today's talk, I guess. What I'm gonna do, what I do in the estimation, I define a market, and I, for now, I've estimated the model for even hours of working days. I estimated demand and supply model separately. So I use vigorous techniques to extract the beliefs from the data. So I have data for the writers, mu and alpha for the drivers. And then on the second step, I use a maximum likelihood estimation to obtain the model privilege. And the data is so rich that I can actually estimate some of them directly off the data. Let me go through the primitives. For the estimation, I add another dimension to the request type. So there are short and long trips. On the demand side primitives, what I'm trying to uncover using the model is the density of writer's valuations. And what I see directly off the data is exogenous rates of arrival. So this line does are directly seen observed in the data. There are a few primitives on the supply side that I'm also trying to uncover using the model. These are the static utilities, measure of impatience and variance of epsilon shocks. And there are some other primitives that I'm estimating using the data. And that is going to be the number of vital drivers and distribution of distances to the writers. I parameterize few things. So first of all, I parameterize the distribution of the valuations. It's going to be gamma distribution truncated from below that is going to have two parameters, shape and scale. And on the supply side, I parameterize the utility so that the static utility is equal to the price minus the per mile cost associated with picking up a trip at the distance D minus fixed cost associated with picking up any trip in the market M. And then there are additional costs associated with picking up the requests that have longer distances. And so here are the estimates. I just want to briefly go through them. As you can see, there's some variation across markets. Instead of showing you all of the shape and scale parameters, which is probably not that much interesting, I'm going to show you the median valuations and probability that the writer would have rejected the trip if the platform was mandating a higher price. So this is a measure of price sensitivity of the writers. And as you can see, for instance, 10-year market is very different from the rest of them. And I attribute that to the changes in the composition of travelers. There are more business associated traveling happening around 10 a.m. And so usually these trips are paid by the company, so it naturally makes the consumers less price sensitive. But still there's some variation across markets. On the supply side, there are also some parameters. I don't want to go through all of them. A few things that I would like to mention is that the variance of epsilon shock is actually large. So you should look at the last column, which is the transformed, it's in money terms. So the lower price that has been offered on the platform is 300. And so the variance of the epsilon shock is more than one-third of that lowest price, which means that private information plays a significant role in this platform. The driver's decisions sometimes are affected by some factors that cannot be observed by the platform. So with that being said, let me then, I would be happy to talk more about the details of the estimation and the parameters. Maybe once we get to the Q&A session, but let me go to the welfare analysis because I feel like I'm slightly running out of time. So far you have seen a case in which the pricing was done in decentralized manner. So the rider was choosing between the low price and the high price. And then the drivers were accepting counter-offering or ignoring. And then the platform was proposing a match. One reminder that the price that was chosen by the rider was reflecting two things. First of all, it was showing the rider's valuation, was signaling the rider's valuation. And also it was signaling the market conditions in which he was it. So the screen that he saw, how many cars were there. What I wanted to do with the centralized pricing, I wanted to force the platform to choose the price. So the platform will be the one who's gonna be choosing between the same options, it's either low or high. And then the rider will decide whether to accept that price. So it's a very similar setting to centralized mechanisms in which you're just showing the price and then you decide what to do with that. However, I will still allow the drivers to reject the request if they don't like it. But I take away their option to make a counter-offer. That way the platform fully controls the price that is gonna be chosen for a trip. And then the platform will still break the ties in the same manner as it does right now. But I needed to find a way to inform a platform about the market conditions, otherwise it wouldn't be a fair comparison. And I needed to take this S which was a vector which is a multi-dimensional vector was containing the number of idle drivers and their sorted distances. And I needed to compress it into some sort of an index so that it would be easier for the platform to choose the price. And hopefully, well thankfully my demand model is actually allowing me to do that. I'm gonna use this threshold that was computed by the rider before and that depends on the state. And just a reminder from the rider's point of view when the rider was facing a very high threshold that was considered as the good market. And in this market, the rider was very unlikely to choose a high price. He would probably go with a low price. And when the threshold was very low that meant that the market was bad and then the rider would have chosen a high price. So let me then tell you about the following case. Imagine that we have the platform that can compute this threshold. So it knows what the rider would have been doing if he was on his own. So we have these two panels on the upper parts of the panels. We essentially have the same picture except for the price that has been chosen by the platform that is the red dot line. But let's forget about that for a second and let me actually focus on this part first. So imagine that the platform knows the threshold. So it knows this V hat. And it knows that if the rider was choosing on his own if his valuation was below that threshold he would choose a low price. In case if his valuation was higher than that threshold he would go with a high price. So that is essentially that part of the graph and it's the same between right and left. But the difference between right and left is what happens if the platform tries to set up prices and on the left part we have when the platform is choosing a low price. On the right part we have the case when the platform is choosing a high price. Let me walk you through the effects that will happen with that. So imagine that the platform is choosing a low price. In this case it mandates all of the riders regardless their type to actually pay low price. It's gonna allow everyone who is interested to participate in the market because their valuations will still be above that lower price that has been offered.  So the riders who would have chosen a high prices for themselves are no longer allowed to do so. On the right in the right panel. So here the platform mandates a high price and what happens with that?  They would have been offering high prices to begin with. So here are they. However, there are two other types of riders who will be affected. First of all, some of the riders will find the price higher than their valuations and they will decide not to participate. So in this lower panel we can compute what is gonna be the share of such riders. In addition, there's a second type. That type was Shade. So they were offering something that they couldn't afford to pay a higher price but they decided not to. They find the profit maximizing them or utility maximizing for them to just shade their valuation and go with a low price instead. When the platform mandates a higher price it essentially forces them to pay a higher price. So with these two graphs we can see a very well-known trade-off in the economics between the quantity versus prices. When the centralized platform tries to mandate the higher prices what happens is gonna lose some of the riders. However, when it wants to keep the riders on the platform it's gonna be losing in pricing. So it's gonna be closing the signaling and so the riders who would have wanted to signal won't be allowed to do so. This trade-off is less present under the decentralized situation. So what I do in this kind of factuals and then what I'm gonna show you I'm basically deciding how often the platform will mandate a higher price on the platform based on the market conditions. So I'm gonna be using a cut-off rule for some markets or so for some S when this cut-off is gonna be when the threshold will be lower than a certain number which is gonna be a cut-off that situation will be considered as the bad market for the platform or from the bad market from the riders point of view. And in this case, the platform will mandate a higher price. If that threshold was exceeding that cut-off the platform will be considering that market as good and would be choosing a lower price. So essentially the platform's trying to mimic what the rider would be doing and trying to be smart. It's an example of a surge pricing but I could have computed equilibrium for all various cut-offs and that's what I actually did but presenting cut-offs is kind of confusing. So the cut-offs can actually be mapped in the percentage of trips that are priced high on the platform. And the thing that is slightly easier to understand. Let me start with a relatively simple graph. Imagine that we have two types of trips. We have short and long trips, right? On the axis, I'm gonna have short trips. On the y-axis, I'm gonna have long trips. And what the axis are showing you what is the percentage among all of the trips that are short or long what is the percentage will be priced high? So we have them two extreme cases the left lower corner and the upper right corner in the left lower corner we have all of the trips on the platform to be priced low. It is a uniform pricing and the price is low. When we're moving away from the left lower corner into the upper right corner what we're doing we're pricing more and more trips on the platform with the higher price. And so somewhere here we would have a case again with the uniform pricing but when all of the prices on the platform are high. So essentially here then we have everything in the middle all of this possible pricing regimes. And this is a very simple graph to understand because of course if you are pricing more and more trips higher you're gonna lose more and more riders. And that's what essentially this graph is showing us. Here is another graph very similar in structure but what it shows us is the matching rates. So of course when we are gonna be kicking out some consumers we're gonna be improving the conditions for the ones that are staying. So the current matching rates in the decentralized setting are around 72%. In case if the platform decides to make all of the prices low and uniform low we would be in this left lower corner. In this case the matching rates will be around 65%. When we are moving away from that and moving into the more centralized uniform high price regime we're gonna be improving the match for the riders that remain and their matching rates will be around 75%. Then we can look at the drivers welfare. What I'm gonna do I'm gonna show you the percentage change in the drivers value function of being vital across all of the centralized pricing regime and compare it to the decentralized one. And here's the result. First of all, one of the things to notice is that the drivers don't like extreme cases. They don't like the case when all of the prices are uniform or low because they're losing in earnings. They also don't like the case when all of the prices are uniformly high. So when we're in the right upper corner because in this case they will be losing one quantities. So they prefer to have some sort of some level of price discrimination. The optimal one is circled here and but even under this optimal one which means it's they have highest welfare among all centralized pricing regimes that I consider they still lose around 10% of their welfare relative to decentralized platform. Likewise, we can compute the measure of the consumer welfare. And in this case, we will also find that riders don't seem to be liking the extreme cases. However, their preferred regime is different from the preferred regime of the drivers but under that preferred regime they still lose around 4% of their welfare. So without let me actually conclude I have presented the equilibrium model of decentralized society platform today. The results that I have shown you suggest that private information plays an important role for a two-sided market efficiency. Centralized platform that tries to set up the prices faces a trade-off between quantity and prices. That trade-off is not present in the centralized setting. And in this case, what I find is that the signaling and quantity effect dominate the shading effect present on the platform. However, I wouldn't worry you that the results might be with the market density. Today's talk is very short. So I don't have much time to actually go through that but I would be happy to talk more about it. And thank you for coming. Here's my email in case if you have any questions or comments, I would be happy to chat. Thank you. Thank you so much, Renata. And thanks for like keeping us on time. Yeah, so now let's have Alex who is our discussant. Yeah, and Alex will help us to bring our understanding to the next level, I believe. So Alex, go ahead. Let's hope. Thank you, Renata. I will not repeat the model. I think Renata made an excellent job of presenting the paper. I will just note that I think it's a beautiful paper. There is a novel dataset which is large and detailed. And there is very comprehensive structural analysis with a big intelligent model and actually very impressive. And it works on important application of online platform. I think as time goes on, the fact that it becomes more and more important because there are more and more platforms in all different applications that start operating and it's important to understand them. But also not only looking at the important application but also deliver a very important message that we actually need to treat private information and strategic behavior on these platforms very seriously and certainly more seriously than I think usually is treated. And I think we should have more and more papers like that. Very nice job. And I will give three more specific comments. I mean, I'm a theorist, so they will be more theoretical in general. But the first comment will be a little bit more applied, I guess. It will be very specific regarding one estimate that there is an estimate of a discount factor, 0.97 per second. That means that in general, there is 3% value lost every second. And this seems to be a little bit too high. I understand that it compounds also probability of quitting, but I still had a feeling that it is a bit too high of a discount. And because, for example, it also indicates that in this 20 seconds that the platform actually collects a request to first of the value is done. So, and I was wondering what can drive it in the current model? Maybe there is something which is driving it. And maybe one thing that could happen that maybe there are some part of drivers who just always accept all requests. I wonder whether this can happen and maybe more generally, whether you can observe in your data heterogeneity across drivers, but also heterogeneity across riders, actually. That is whether your data, I was not clear from reading the paper whether your data allows to trap in time the same driver or the same rider. Because if so, maybe it could allow to make even more precise estimation of the model because you can imagine that some riders can always accept all requests, but also some drivers, sorry. And some riders can be possibly just richer. And that consistently will be charging high prices. And I think that that could possibly would be interesting to address and to hear what you think about it, but maybe then of course, complete with two other comments I have. And two other comments. The second one is relates to this main message of private information and it's important, which I think is very nice. And I think it is indeed highlights that the current platforms need to think a little bit more about their design, like think about Uber and Leaf. At the same time, I was not sure whether contrasting decentralized and centralized market is the right language because in some sense, like from a theory perspective, centralized planner can actually replicate pretty much everything that can be done in decentralized that is maybe bargaining versus posted prices which would be a bit more precise language. And just to reiterate on that, as you highlight, indeed private information may be very important, heterogeneity. And if you are a platform who has designed some centralized mechanism, you might actually indeed want to screen this. But it may be done not necessarily through bargaining, but it could be done, for example, by allowing the riders, indicate that the trip is urgent. And it can be easily done in centralized memory, in some sense. So then you give an option to make a flag, this, I don't know, small fire, that you're willing as a rider to pay more, but to get the request. And I think that can be implemented in centralized way and probably it will be a more clever design that currently what Uber has and Leaf has indeed. And the third comment, it's kind of holed up on the second one, that it actually arises having an interesting theoretical question. Your analysis is how to optimally design this system. That is actually, so if you can actually allow buyers and sellers to somehow provide this private information, how should you aggregate? And in some sense, it's a classical question in mechanism design literature, but there is also there's additional twist of these inter-temporal incentives that I'm sharing to this market because the environment is dynamic, because you can wait for another buyer and there's also inter-temporal competition across drivers, which I think adds interesting dimension to this even purely theoretical problem. And I think if there are some aspiring theorists in the audience that could do something to think about. And I think this application motivates very well why it is important to think about it and that you can get a lot of gains in efficiency. And then it will be also interesting maybe to compare to this benchmark that you provided kind of positive prices. One benchmark, this bargaining procedure is another benchmark, but another benchmark would be some sort of optimal information aggregation. But this is certainly, it is a complicated theoretical question. Yes. This is my comments.