We can demonstrate how

[alexalamin]

Constraint 2: Each business owner should be interacting with a different number for each different customer they are working with. However, there is no problem if two different customers see the same number for two different businesses because we can disambiguate who they are calling/texting based on the caller phone number. The same holds true for the business side. Therefore, we only need enough numbers to satisfy the above constraints for all of the customer-business connections every month at Yelp (with recycling).

We can demonstrate how this works out to be a small number with a hypothetical lebanon mobile phone numbers database example. If most customers contact less than 10 businesses per month, and most businesses receive less than 100 requests per month1, we only need 100 numbers (max of the two) to satisfy both constraints. We can also add a safety factor to account for outliers, but the number pool size still ends up being a small constant size. More importantly, this allocation strategy minimizes our proxy number costs because the number pool size does not need to increase (it is O(1)) with the volume of customer quote requests sent on Yelp or the number of businesses we onboard on the platform.



In this example, there are 2 customers and 2 businesses having a total of 4 unique conversations (masking sessions), facilitated by a pool of 2 proxy numbers. Notice how the proxy numbers are mapped to participants such that each party sees unique numbers for each of their conversations (i.e. both constraints are satisfied). Each party sees unique numbers (multiple proxy pools) As a final improvement, we actually use two pools of proxy numbers, one for the customer side and another for the business side.