CN116783604A

CN116783604A - System and method for determining asymmetric merchant visibility

Info

Publication number: CN116783604A
Application number: CN202280012450.5A
Authority: CN
Inventors: 牛俊鹏; 陈文卿; 郑盛忠
Original assignee: Grabtaxi Holdings Pte Ltd
Current assignee: Grabtaxi Holdings Pte Ltd
Priority date: 2021-05-19
Filing date: 2022-05-10
Publication date: 2023-09-19
Also published as: KR20240009914A; WO2022245283A1

Abstract

A system for determining asymmetric merchant visibility is disclosed. The system may include one or more processors configured to: determining a first area for the merchant and a market offer in the first area; determining one or more second areas for one or more users and market demand in the one or more second areas, wherein the one or more second areas surround the first area; determining a distribution rate based on market supply and market demand; determining one or more balance scores for each of the one or more second areas, wherein the one or more balance scores indicate a likelihood that the driver receives another job after a first job of delivering the item from the first area to the one or more second areas; and determining asymmetric merchant visibility based on the allocation rate and the one or more balance scores.

Description

System and method for determining asymmetric merchant visibility

Technical Field

Aspects of the present disclosure relate to a system for determining asymmetric merchant visibility. Aspects of the present disclosure relate to a method for determining asymmetric merchant visibility. Aspects of the present disclosure relate to a non-transitory computer-readable medium storing computer-executable code including instructions for determining asymmetric merchant visibility. Aspects of the present disclosure relate to computer-executable code comprising instructions for determining asymmetric merchant visibility.

Background

Delivery (e.g., immediate delivery, such as food delivery, drug delivery, grocery delivery) provides many convenience to e-commerce consumers by delivering items in a short period of time. This is called instant delivery SLA (service level assurance). To ensure a high level of SLA, a business-centric circle is typically predefined, and only consumers within the circle can see and order from the business in their user devices. The radius of the circle may be a straight line distance/time or a route distance/time. This is referred to as symmetric merchant visibility control.

However, current methods of using symmetric merchant visibility control do not take into account asymmetric demand distribution and batch potential or future driver revenue after delivery. Furthermore, two delivery points in a home or office area may have different merchant listings.

Currently existing delivery prediction methods are based solely on dynamic radius around the merchant (based on distance or time). Thus, driver utilization and revenue are not optimized and consumer experience is also compromised.

Disclosure of Invention

Accordingly, there is a need for an improved system for merchant visibility for users. There is also a need to improve user and driver satisfaction.

Advantages of the present disclosure may include an improved system for merchant visibility for users that results in increased user satisfaction through asymmetric merchant visibility.

Advantages of the present disclosure may include higher user satisfaction due to increased order allocation rates.

Advantages of the present disclosure may include higher driver satisfaction due to increased driver utilization and revenue.

These and other foregoing advantages and features of the aspects disclosed herein will be apparent from the following description and drawings. Furthermore, it is to be understood that the features of the various aspects described herein are not mutually exclusive and may exist in various combinations and permutations.

The present disclosure relates generally to a system for predicting a delivery time of a batch order. The system may include one or more processors; and a memory having instructions stored therein that, when executed by the one or more processors, cause the one or more processors to: determining a first area for the merchant and a market offer in the first area; determining one or more second areas for one or more users and market demand in the one or more second areas, wherein the one or more second areas surround the first area; determining a distribution rate based on market supply and market demand; determining one or more balance scores for each of the one or more second areas, wherein the one or more balance scores indicate a likelihood that the driver receives another job after a first job of delivering the item from the first area to the one or more second areas; and determining asymmetric merchant visibility based on the allocation rate and the one or more balance scores.

According to an embodiment, the first region may be a supply region and the one or more second regions may be at least one of a demand region and a mixing region, wherein the mixing region may be both the second demand region and the second supply region.

According to an embodiment, when the dispensing rate indicates an oversupply, both the user in the demand area and in the mixing area can order from the first area.

According to an embodiment, when the dispensing rate indicates an insufficient supply, users in the demand area may not be able to order from the first area, while users in the mix area may be able to order from the first area.

According to an embodiment, the one or more balance scores for each of the one or more second areas may be determined based on the amount of orders from the user and the amount of orders to the merchant for each of the one or more second areas.

According to an embodiment, the one or more balance scores for each of the one or more second regions may be determined based on the historical long-term demand value and the historical long-term supply value, the historical short-term demand value and the historical short-term supply value, and the real-time demand value and the real-time supply value.

According to an embodiment, the one or more balance scores for each of the one or more second regions may be determined based on a first weight for the historical long-term demand value and the historical long-term supply value, a second weight for the historical short-term demand value and the historical short-term supply value, and a third weight for the real-time demand value and the real-time supply value.

According to an embodiment, the one or more processors may be configured to determine a balance score for the first region. The one or more processors may be configured to determine a total balance score based on the balance score of the first region and the one or more balance scores of each of the one or more second regions.

According to an embodiment, the one or more processors may be configured to determine asymmetric merchant visibility based on the total balance score.

The present disclosure relates generally to a method for determining asymmetric merchant visibility. The method may include using one or more processors to: determining a first area for the merchant and a market offer in the first area; determining one or more second areas for one or more users and market demand in the one or more second areas, wherein the one or more second areas surround the first area; determining a distribution rate based on market supply and market demand; determining one or more balance scores for each of the one or more second areas, wherein the one or more balance scores indicate a likelihood that the driver receives another job after a first job of delivering the item from the first area to the one or more second areas; and determining asymmetric merchant visibility based on the allocation rate and the one or more balance scores.

The present disclosure relates generally to non-transitory computer-readable media storing computer-executable code comprising instructions for determining asymmetric merchant visibility in accordance with the present disclosure.

The present disclosure relates generally to computer-executable code comprising instructions for determining asymmetric merchant visibility in accordance with the present disclosure.

To the accomplishment of the foregoing and related ends, one or more embodiments comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the associated drawings set forth certain illustrative features of one or more aspects in detail. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed and the present specification is intended to include all such aspects and their equivalents.

Drawings

In the drawings, like reference numerals generally refer to like parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the disclosure. The dimensions of the various features or elements may be arbitrarily expanded or reduced for clarity. In the following description, various aspects of the disclosure are described with reference to the following drawings, in which:

FIG. 1 illustrates a system according to various embodiments.

FIG. 2 illustrates a flow chart of a method according to various embodiments.

Fig. 3 shows an exemplary illustration of a first region and one or more second regions, in accordance with various embodiments.

FIG. 4A illustrates an exemplary table of historical demand and supply values according to various embodiments.

FIG. 4B illustrates an exemplary balance table for the exemplary table of FIG. 4A, in accordance with various embodiments.

FIG. 4C illustrates an exemplary balance score table for the exemplary table of FIG. 4B, in accordance with various embodiments.

FIG. 4D illustrates an exemplary aggregate balance score table for the exemplary table of FIG. 4C, in accordance with various embodiments.

Detailed Description

The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized and structural and logical changes may be made without departing from the scope of the present invention. The various embodiments are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments.

The embodiments described in the context of one of a system or server or method or computer program are similarly valid for the other system or server or method or computer program and vice versa.

Features described in the context of embodiments may be correspondingly applicable to the same or similar features in other embodiments. Features described in the context of embodiments may be correspondingly applicable to other embodiments even if not explicitly described in these other embodiments. Furthermore, additions and/or combinations and/or substitutions described in the context of an embodiment for features may be applied accordingly to the same or similar features in other embodiments.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

In the context of various embodiments, the articles "a," "an," and "the" are used with respect to a feature or element to include references to one or more features or elements.

As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

The terms "at least one" and "one or more" are to be understood to include numerical amounts greater than or equal to 1 (e.g., 1, 2, 3, 4, [.], etc.). The term "plurality" may be understood to include numerical quantities greater than or equal to 2 (e.g., 2, 3, 4, 5, [.], etc.).

The words "plurality" and "plurality" in the specification and claims explicitly refer to amounts greater than 1. Thus, any phrase that explicitly invokes the aforementioned word (e.g., "multiple [ objects ]") that refers to a large number of objects explicitly refers to more than one of the objects. The terms "set," "collection," "series," "sequence," "grouping" and the like in the description and in the claims, if any, refer to an amount equal to or greater than 1, i.e., one or more. The terms "proper subset", "reduced subset" and "smaller subset" refer to subsets of a set that are not equal to the set, i.e., subsets of a set that contain fewer elements than the set.

The term "data" as used herein may be understood to include any suitable information in analog or digital form, such as provided as a file, a portion of a file, a set of files, a signal or stream, a portion of a signal or stream, a collection of signals or streams, and the like. Furthermore, the term "data" may also be used to represent references to information, for example in the form of pointers. However, the term "data" is not limited to the above examples, and may take various forms and represent any information understood in the art.

For example, the term "processor" or "controller" as used herein may be understood as any type of entity that allows processing of data, signals, etc. Data, signals, etc. may be processed according to one or more particular functions performed by a processor or controller.

The processor or controller may thus be or include an analog circuit, a digital circuit, a mixed signal circuit, a logic circuit, a processor, a microprocessor, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), an integrated circuit, an Application Specific Integrated Circuit (ASIC), or the like, or any combination thereof. Any other type of implementation of the various functions described in further detail below may also be understood as a processor, controller, or logic circuitry. It should be appreciated that any two (or more) of the processors, controllers, or logic circuits detailed herein may be implemented as a single entity having equivalent functionality, etc., and conversely, any single processor, controller, or logic circuit detailed herein may be implemented as two (or more) separate entities having equivalent functionality, etc.

The term "system" (e.g., drive system, position detection system, etc.) as detailed herein may be understood as a set of interactive elements, which may be, by way of example and not limitation, one or more mechanical components, one or more electrical components, one or more instructions (e.g., encoded in a storage medium), one or more controllers, etc.

As used herein, "circuitry" is understood to be any type of logic implementing entity, which may comprise dedicated hardware or a processor executing software. Thus, the circuitry may be analog circuitry, digital circuitry, mixed signal circuitry, logic circuitry, a processor, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), a digital signal processor ("DSP"), a field programmable gate array ("FPGA"), an integrated circuit, an application specific integrated circuit ("ASIC"), or the like, or any combination thereof. Any other type of implementation of the various functions described in further detail below may also be understood as a "circuit". It should be understood that any two (or more) of the circuits detailed herein may be implemented as a single circuit having substantially equivalent functionality, and conversely, any single circuit detailed herein may be implemented as two (or more) separate circuits having substantially equivalent functionality. In addition, reference to "a circuit" may refer to two or more circuits that together form a single circuit.

As used herein, "memory" may be understood as a non-transitory computer-readable medium in which data or information may be stored for retrieval. Thus, references to "memory" as included herein may be understood to refer to volatile or non-volatile memory, including random access memory ("RAM"), read only memory ("ROM"), flash memory, solid state memory, magnetic tape, hard disk drive, optical drive, etc., or any combination thereof. Furthermore, it should be understood that registers, shift registers, processor registers, data buffers, etc. are also encompassed herein by the term memory. It should be understood that a single component referred to as "memory" or "a memory" may be composed of more than one different type of memory, and thus may refer to an aggregate component that includes one or more types of memory. It is readily understood that any single memory component may be divided into multiple collective equivalent memory components and vice versa. Moreover, although the memory may be depicted as being separate from one or more other components (e.g., in the figures), it should be appreciated that the memory may be integrated within another component, such as on a common integrated chip.

The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects in which the invention may be practiced. These aspects are described in sufficient detail to enable those skilled in the art to practice the invention. The present system provides various aspects, and the present method provides various aspects. It should be understood that the basic properties of the system also apply to these methods and vice versa. Other aspects may be utilized and structural and logical changes may be made without departing from the scope of the present invention. The various aspects are not necessarily mutually exclusive, as some aspects may be combined with one or more other aspects to form new aspects.

For easier understanding and put into practice, the present system, method and other specific aspects will now be described by way of example and not by way of limitation with reference to the accompanying drawings. Repeated descriptions of features and attributes may be omitted for brevity.

It should be understood that any of the features described herein for a particular system or device may also be applicable to any of the systems or devices described herein. It will also be appreciated that any of the features described herein for a particular method may be applied to any of the methods described herein. Moreover, it should be understood that not all of the components or operations described need be included in any device, system, or method described herein, but rather only some (but not all) of the components or operations.

The term "comprising" is to be interpreted as having a broad meaning similar to the term "comprising" and is to be interpreted as implying any such integer or operation or group of integers or operations but not excluding any other integer or operation or group of integers or operations. The definition also applies to variants of the term "comprising", such as "including" and "containing".

The term "coupled" (or "connected") herein may be understood as electrically or mechanically coupled, e.g., attached or fixed or attached, or simply contacted without any fixation, and as directly or indirectly coupled (in other words: coupling without direct contact may be provided).

Fig. 1 illustrates a system 100 according to various embodiments.

According to various embodiments, the system 100 may include a server 110, a first user device 120, and/or a second user device 140.

In various embodiments, the server 110, the first user device 120, and the second user device 140 may communicate with one another over the communication network 130. In an embodiment, even though fig. 1 shows a line connecting the server 110 to the communication network 130, a line connecting the first user equipment 120 and the second user equipment 140 to the communication network 130, the server 110 and the first user equipment 120 or the second user equipment 140 may not be physically connected to each other, for example, by a cable. In an embodiment, the server 110, the first user device 120 and the second user device 140 are capable of wireless communication via the communication network 130 or via a mobile cellular communication network via an internet communication protocol.

In various embodiments, the server 110 may be a single server as schematically illustrated in fig. 1, or have functions performed by the server 110 distributed across multiple server components. In an embodiment, the server 110 may include one or more server processors 112. In an embodiment, the various functions performed by server 110 may be performed across one or more server processors. In an embodiment, each particular function of the various functions performed by server 110 may be performed by a particular server processor of the one or more server processors.

In an embodiment, the server 110 may include a memory 114. In an embodiment, the server 110 may also include a database. In embodiments, the memory 114 and database may be one component or may be separate components. In an embodiment, the memory 114 of the server may include computer executable code defining the functions that the server 110 performs under the control of one or more server processors 112. In an embodiment, the database and/or memory 114 may include historical data such as the amount of orders from the user and/or the amount of orders to the merchant for each region. The historical data may also include historical long-term demand values and/or supply values, historical short-term demand values and/or supply values, and/or real-time demand values and supply values.

According to various embodiments, a computer program product may store computer executable code comprising instructions for determining asymmetric merchant visibility according to various embodiments. In an embodiment, the computer executable code may be a computer program. In an embodiment, the computer program product may be a non-transitory computer readable medium. In an embodiment, the computer program product may be in the system 100 and/or the server 110.

In some embodiments, server 110 may also include input and/or output modules that allow server 110 to communicate over communications network 130. In an embodiment, the server 110 may also include a user interface for user control of the server 110. In an embodiment, the user interface may include, for example, computing peripherals such as a display monitor, user input devices, e.g., touch screen devices, and computer keyboards.

In an embodiment, the first user device 120 may include a user device memory 122. In an embodiment, the first user device 120 may include a first user device processor 124. In an embodiment, the first user device memory 122 may include computer executable code defining the functions performed by the first user device 120 under the control of the first user device processor 124. In an embodiment, the first user device memory 122 may comprise or may be a computer program product such as a non-transitory computer readable medium.

In an embodiment, the first user device 120 may further comprise an input and/or output module allowing the first user device 120 to communicate over the communication network 130. In an embodiment, the first user device 120 may further comprise a user interface for user control of the first user device 120. In an embodiment, the user interface may be a touch panel display. In an embodiment, the user interface may include a display monitor, a keyboard, or buttons.

In an embodiment, the second user device 140 may include a second user device memory 142. In an embodiment, the second user device 140 may include a second user device processor 144. In an embodiment, the second user device 140 may be similar to the first user device 120. Repeated descriptions of features and attributes of the second user device 140 are omitted for brevity.

In an embodiment, the system 100 may be used to determine asymmetric merchant visibility. In an embodiment, the processor 112 may be configured to determine a first area of the merchant. The first region may be in the first geographic hash or may be the first geographic hash. The term "geographic hash" may be a predefined geocoding unit of a partitioned area of a city or country. In various embodiments, the first area may be a building such as a shopping mall or a food center. In various embodiments, the first region may be defined based on a predetermined radius or distance.

In an embodiment, the processor 112 may be configured to determine the market offer in the first region. The market offer may be a number of orders for items from merchants in the first area. The first area may also include a plurality of other merchants. The market offer may also be a number of orders for items from one or more merchants in the first area. The first region may be a supply region.

In an embodiment, the processor 112 may be configured to determine one or more second regions for one or more users. The one or more second regions may be in or may be one or more second geographic hashes. In various embodiments, each of the one or more second areas may be a defined area such as a residential area or an office building or a predefined community. In various embodiments, each second region may be defined based on a predetermined radius or distance. One or more users may be located in one or more second areas.

In an embodiment, the processor 112 may be configured to determine market demand in one or more second regions. The market demand may be a number of orders for items from the merchant by one or more users in one or more second areas. The one or more second regions may surround the first region or may be peripheral to the first region. The one or more second regions may be at least one of a demand region and a mixing region. The mixing zone may be both the second demand zone and the second supply zone.

In an embodiment, the processor 112 may be configured to determine the dispensing rate based on the market supply and market demand. The allocation rate may indicate a likelihood that the user order matches or is accepted by the merchant.

In an embodiment, the processor 112 may be configured to determine one or more balance scores for each of the one or more second regions. The one or more balance scores may indicate a likelihood that the driver receives another job after a first job of delivering the item from the first area to the one or more second areas.

In an embodiment, the processor 112 may be configured to determine asymmetric merchant visibility based on the allocation rate and one or more balance scores.

In an embodiment, when the dispensing rate indicates an oversupply, users in the demand area and the mixing area can order from the first area.

In an embodiment, when the dispensing rate indicates an insufficient supply, users in the demand area may not be able to order from the first area, while users in the mix area may be able to order from the first area.

In an embodiment, the one or more balance scores for each of the one or more second areas may be determined based on the amount of orders from the user and the amount of orders to the merchant for each of the one or more second areas.

In an embodiment, one or more balance scores for each of the one or more second regions may be determined based on the historical long-term demand and supply values, the historical short-term demand and supply values, and the real-time demand and supply values.

In an embodiment, one or more balance scores for each of the one or more second regions may be determined based on a first weight of the historical long-term demand and supply values, a second weight of the historical short-term demand and supply values, and a third weight of the real-time demand and supply values.

In an embodiment, the processor 112 may be configured to determine a balance score for the first region. The one or more processors may be configured to determine a total balance score based on the balance score of the first region and the one or more balance scores of each of the one or more second regions.

In an embodiment, the processor 112 may be configured to determine asymmetric merchant visibility based on the total balance score.

In an embodiment, an asymmetric merchant visibility control method may be used to optimize driver utilization and revenue in a global and long-term manner. In an embodiment, the processor 112 may use the supply and demand information for each region, as well as the number of orders to the merchant, to estimate the opportunity cost for that region for the entire instant delivery system, and then apply that opportunity cost to construct the delivery span.

In an embodiment, there may be a system or model to estimate regional demand and supply and calculate a balance score (i.e., supply/demand balance score) that may indicate opportunity costs based on historical and/or real-time demand and/or supply and/or batch information.

In an embodiment, there may be a system or model that estimates the delivery efficiency of each zone based on zone distance and/or supply/demand balance score and/or batch information.

In an embodiment, there may be a system or algorithm that dynamically calculates asymmetric merchant visibility control based on market conditions (confirmed allocation signals) and delivery efficiency for each region.

Fig. 2 illustrates a flow chart of a method 200 according to various embodiments.

According to various embodiments, a method 200 for determining asymmetric merchant visibility may be provided. In some embodiments, the method 200 may include step 202: the first region for the merchant and the market offers in the first region are determined using one or more processors of a system (e.g., system 100). In an embodiment, the method 200 may include step 204: one or more processors are used to determine one or more second regions for one or more users and market demand in the one or more second regions. The one or more second regions may surround the first region. In an embodiment, the method 200 may include step 206: the distribution rate is determined based on the market supply and the market demand using one or more processors. In an embodiment, the method 200 may include step 208: one or more processors are used to determine one or more balance scores for each of the one or more second regions. The one or more balance scores may indicate a likelihood that the driver receives another job after a first job of delivering the item from the first area to the one or more second areas. In an embodiment, the method 200 may include step 210: asymmetric merchant visibility is determined based on the allocation rate and the one or more balance scores using the one or more processors.

Steps 202 through 210 are shown in a particular order, however other arrangements are possible, for example, in some embodiments, step 206 may be performed after step 202. In some cases, these steps may also be combined. Any suitable order of steps 202 through 210 may be used.

In an embodiment, the region 300 (i.e., city) may be divided into small regions, for example, via a clustering algorithm. These small areas may be determined based on information of density and/or supply and/or demand. With the provisioning and/or demand information, small regions may be clustered or categorized into demand, provisioning, and hybrid regions. The category of the area may change in real time as demand and supply change. In an embodiment, the first region may be a supply region. The one or more second regions may be at least one of: a demand area and a mixing area. The one or more second regions may surround or may be proximate to the first region. In an embodiment, each region has a balance score.

In the example shown in fig. 3, zone 300 has a supply zone 302, a first demand zone 304 (i.e., zone 1), a second demand zone 306 (i.e., zone 2), a mixing zone 308 (i.e., zone 3), and a third demand zone 310 (i.e., zone 4). The supply area may be considered as a first area. The first demand region 304 (i.e., region 1), the second demand region 306 (i.e., region 2), the blend region 308 (i.e., region 3), and the third demand region 310 (i.e., region 4) may be considered one or more second regions.

In an embodiment, after the region is defined, for each merchant, demand in the history may be determined by analyzing the historical orders. In an embodiment, the historical data from the historical orders may include an average and/or median of orders historically placed to the merchant based on the time of day and/or whether the day was a weekday or a weekend. If nearby merchants order batches are performed, similar demand amounts for nearby merchants may be determined.

With the demand information, a table may be generated to represent the relationship between the merchant and the linked area. For example, FIG. 3 shows one merchant in the offer area 302, with four link areas 304, 306, 308, 310 having orders placed to the merchant.

Using known demand and supply information, merchant visibility control may be applied based on the assigned health of the area. The allocation health of an area at any given moment can be estimated by validating the real-time signal of the allocation rate (CAR), which is defined by the following formula:

based on the CAR signal, market supply and demand can be categorized into several levels, such as oversupply (e.g., CAR > 0.9), slight undersupply (e.g., 0.9 ≡car > 0.75), undersupply (e.g., 0.75 ≡car > 0.5), and extremely undersupply (e.g., CAR < 0.5) when driver supply is extremely low and demand is extremely high (such as in peak hours in urban areas).

When the market is oversupplied, users in all surrounding areas 304, 306, 308, 310 may order food from merchants in the supply area 302, as the driver supply is sufficient, the focus may be on increasing the total number of orders and thus the total merchant value (GMV).

When the marketplace is in a slightly under-supplied condition, users from another area (e.g., the third demand area 310) may be removed because the other area may have fewer orders (e.g., 3 orders) from merchants in the supply area 302 from the users. Since the amount of orders to the merchant from the other area may be low, the batch probability of all users in the other area may also be low.

When the market is in an under-supplied condition, users from a nearby area with fewer orders (e.g., the first demand area 304 with 3 orders) may be removed because the demand is much smaller than a far area (e.g., areas 306, 308), because orders in the far area with higher orders may have a higher batch opportunity than the near area, and thus have a higher driver utilization efficiency.

When the marketplace is in an extremely under-supplied condition, if the distance and demand from both areas are similar, users from the demand area (e.g., area 306) may be removed, while users from the mixing area (e.g., area 308) may be able to continue purchasing from merchants in the supply area 302. In a demand area, after the driver has completed a work, the chance of getting another work in the vicinity of the area will be very low, which means that the driver needs to return to the supply area without an order at hand, thus reducing the system efficiency. For the mixing zone, the driver is more likely to get another job near the mixing zone, thereby improving system efficiency.

In an embodiment, the problem may be expressed as a linear function of one or more of the following: merchant distance, regional attributes of demand and supply, and number of orders from merchants within the region. The formula can be expressed as:

S _region(s) ＝α×d _Merchant +β×S _Balancing +γ×n _{Order form}

In an embodiment, S _Region(s) May be a selection score for a particular area for a merchant or a group of nearby merchants. The higher the score, the higher the opportunity that the merchant can access from the area when the driver supply market is in an under-supplied condition.

In an embodiment, d _Merchant May be the distance between a particular area (e.g., its center point) to a merchant or a group of nearby merchants.

In an embodiment, S _Balancing There may be a balance score calculated based on the number of orders created by the customers and the number of orders processed by the merchants in one area. The higher the number of orders processed by the merchant, the higher the score, which may indicate that drivers in the area have a higher chance to get work. A lower score may mean that drivers in the area have a lower chance to get another job.

In an embodiment, n _{Order form} The number of orders created for a particular merchant or group of merchants from the area may be indicated. The higher the number, the higher the chance that two or more orders will be batched. Otherwise, the batch probability may be lower.

In an embodiment, the coefficients α, β, and γ may be estimated based on time spent or saved by the driver in driving, detouring, batch time efficiency, and time saved by obtaining another job in one or more launch areas near the launch location. These three coefficients may be estimated and optimized based on a learning algorithm that may adjust parameters with real-time performance metrics and market conditions.

In an embodiment, to obtain a balance score for an area, it may be necessary to consider historical order balance and balance of surrounding areas. For example, the number of orders created by the user and/or the number of orders processed by the merchant may be used. The amount of orders may be based on a day of the week and/or a time slot in a day of the long time (e.g., a month) and a short time (e.g., a week). In an embodiment, a value of a previous time period in the day (i.e., a current value) may be obtained. The time period may be user defined based on these variables and the frequency of change of the CAR signal, for example 15 minutes, 30 minutes or 1 hour.

With the calculated long-term, short-term, and current values of the amount of orders created and the amount of orders processed in the area, the balance number may be: n is n _Balancing ＝(n _Food-stuff －n _Merchant ) Wherein n is _Food-stuff Is the number of orders created by the user (i.e., guest) in the area, n _Merchant Is the number of orders processed by the merchants in that area. The score can range from [ -0.5,0.5]。

s _Balancing The formula of (t) may be s _Balancing (t)＝(max(n _Balancing )－n _Balancing )/(max(n _Balancing )－min(n _Balancing ) -0.5, wherein s _Balancing (t) may represent a balance score, which may be a normalized value based on a maximum balance and a minimum balance.

s _Balancing The formula of (region) may be s _Balancing (region) =a×s _Balancing (long term) +bxs _Balancing (short term) +c×s _Balancing (present), wherein s _Balancing The (region) may represent an overall balance score for the region, which may combine the long-term history score, the short-term history score, and the current score.

In an embodiment s _Balancing The (long) may be a long term balance score, which may be aggregated based on long term data (e.g., data of the past month) for the time period. s is(s) _Balancing (short) can beBalance score for short-term data (e.g., data of the past week) for the particular time period. s is(s) _Balancing The (current) may be a score value of a previous time period, which may represent a current market condition. Coefficients a, b, and c are coefficients of these values, which can be adjusted based on a learning model.

In an embodiment, with the balance score for each region, the final balance score s may be calculated _Balancing . The balance score of the nearby region and the region itself may be interpolated. For example, if an area itself is a demand area, but if most of the surrounding areas are supply areas with a higher balance score, the area may be considered as a supply (surplus) area because after the driver completes the assigned work, the driver can still easily find another work in the surrounding areas. The formula may be:

Wherein: />May be a uniform distance between the area itself and the nearby area, i in the area may be the area itself and a set of areas in the vicinity of the area, +.>May be a uniform distance based on a predetermined uniform step size (e.g., 500 m).

FIG. 4A illustrates an exemplary table 400 of historical demand values and supply values in accordance with various embodiments.

Table 400 may include a zone name 402, a long-term user order 404, a long-term order 406 for the merchant, a short-term user order 408, a short-term order 412 for the merchant, a current user order 414, a current order 416 for the merchant, and a distance 418. Under the zone name 402, there may be a supply zone 420 (zone A) and one or more zones near the supply zone 420. The one or more regions may include a first region 422A, a second region 422B, a third region 422C, a fourth region 422D, and a fifth region 422E. Distance 418 may include information regarding the distance from one or more of regions 422A-422E to supply region 420.

Fig. 4B illustrates an example balance table 425 for the example table 400 of fig. 4A, in accordance with various embodiments.

Based on the long term user order 404, the long term order 406 of the merchant, a long term balance number 426 may be obtained. The long term balance number 426 may be obtained by subtracting the long term order 406 of the merchant from the long term user order 404.

Based on the short term user order 408, the short term order 412 for the merchant, a short term balance number 428 may be obtained. The short term balance number 428 may be obtained by subtracting the short term order 412 of the merchant from the short term user order 408.

Based on the current user order 414, the merchant's current order 416, a current balance number 430 may be obtained. The current balance number 430 may be obtained by subtracting the merchant's current order 416 from the current user order 414.

In an embodiment, a negative number may indicate that the region may be a demand region, and a positive number may indicate that the region may be a supply region.

Fig. 4C illustrates an exemplary balance score table 450 for the exemplary table 425 of fig. 4B, in accordance with various embodiments.

In table 450, long term balance score 432, short term balance score 434, and current balance score 436 may be calculated based on the maximum and minimum balance numbers around the merchant. For example, max (long) =200, min (long) = -200, max (short) = -50, min (short) = -50, max (current) = 20 and min (current) = -20.

FIG. 4D illustrates an exemplary aggregate balance score table 475 for the exemplary table 450 of FIG. 4C, in accordance with various embodiments.

In table 475, each of the long term balance score, the short term balance score, and the current balance score may be aggregated based on coefficients of the long term balance score, the short term balance score, and the current period balance score. For example, the coefficients of the long term balance score, short term balance score, and current period balance score may be 0.2, 0.3, and 0.5, respectively.

In an embodiment, the distances 418 may be unified based on predefined coefficients before calculating the final score. For example, 0.5km may be used as the base step size and the value of region a may be 1, then the uniform distance to region a will be 1, 2, 3, 4, 3 and 2. The final balance score for region a is then: -0.265+0.2975/2+0.0675/3+0.0675/4+ (-0.0675/3) +(-0.0275/2) = -0.113125. Thus, the balance score for region A is-0.113125, which can be considered a demand region.

In an embodiment, an amount of orders to a particular merchant or a group of nearby merchants created by users (customers) in an area is obtained. A similar mechanism is used as the balance score calculation. The amounts of orders in the long-term, short-term, and current periods may be aggregated. Different weights may be given to the long term, short term, and current time periods to estimate the amount of orders created in a time period. Based on the number of orders created, the batch probability of orders from the region may be estimated.

In an embodiment, after calculating the area score (S _Region(s) ) The scores for all possible areas around the merchant may then be normalized. The CAR signal may be used to indicate a driver supply condition. By combining the CAR signal and normalized score: normalization (S) _Region(s) )>λ _x (1-CAR) a decision can be made. In an embodiment, if CAR is high, more areas may access the merchant, while if CAR is low, users (customers) from lower scoring areas will be temporarily stopped creating orders to the merchant. Lambda may be used in the formula _x Giving weight to a particular merchant. For example, higher lambda may be given to partner merchants and/or high GMV merchants _x Whereas low performing merchants (e.g., merchants with long waiting times and/or high cancellation rates) may be given lower lambda _x 。

While the present disclosure has been particularly shown and described with reference to particular aspects, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the present disclosure as defined by the appended claims. The scope of the disclosure is therefore indicated by the appended claims, and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims

1. A system for determining asymmetric merchant visibility, the system comprising:

one or more processors; and

a memory having instructions stored therein, which when executed by the one or more processors, cause the one or more processors to:

Determining a first area for a merchant and a market offer in the first area;

determining one or more second areas for one or more users and market demand in the one or more second areas, wherein the one or more second areas surround the first area;

determining a distribution rate based on the market supply and the market demand;

determining one or more balance scores for each of the one or more second areas, wherein the one or more balance scores indicate a likelihood that a driver receives another job after a first job of delivering items from the first area to the one or more second areas; and

the asymmetric merchant visibility is determined based on the allocation rate and the one or more balance scores.

2. The system of claim 1, wherein the first zone is a supply zone and the one or more second zones are at least one of a demand zone and a mixing zone, wherein the mixing zone is both a second demand zone and a second supply zone.

3. The system of claim 2, wherein when the dispensing rate indicates an oversupply, users in both the demand area and the mixing area are able to order from the first area.

4. The system of claim 2, wherein when the dispensing rate indicates an insufficient supply, users in the demand area are not able to order from the first area, and users in the mix area are able to order from the first area.

5. The system of any of claims 1-4, wherein the one or more balance scores for each of the one or more second regions are determined based on an amount of orders from a user and an amount of orders to a merchant for each of the one or more second regions.

6. The system of any of claims 1 to 5, wherein the one or more balance scores for each of the one or more second regions are determined based on historical long-term demand values and historical long-term supply values, historical short-term demand values and historical short-term supply values, and real-time demand values and real-time supply values.

7. The system of claim 6, wherein the one or more balance scores for each of the one or more second regions are determined based on a first weight for the historical long-term demand value and historical long-term supply value, a second weight for the historical short-term demand value and historical short-term supply value, and a third weight for the real-time demand value and real-time supply value.

8. The system of any of claims 1 to 7, wherein the one or more processors are configured to determine a balance score for the first region and to determine a total balance score based on the balance score for the first region and the one or more balance scores for each of the one or more second regions.

9. The system of claim 8, wherein the one or more processors are configured to determine the asymmetric merchant visibility based on the total balance score.

10. A method for determining asymmetric merchant visibility, the method comprising using one or more processors to:

determining a first area for a merchant and a market offer in the first area;

11. The method of claim 10, wherein the first zone is a supply zone and the one or more second zones are at least one of a demand zone and a mixing zone, wherein the mixing zone is both a second demand zone and a second supply zone.

12. The method of claim 11, wherein when the dispensing rate indicates an oversupply, users in both the demand area and the mixing area are able to order from the first area.

13. The method of claim 11, wherein when the dispensing rate indicates an insufficient supply, users in the demand area cannot subscribe from the first area, and users in the mix area can subscribe from the first area.

14. The method of any of claims 1-13, wherein the one or more balance scores for each of the one or more second regions are determined based on an amount of orders from a user and an amount of orders to a merchant for each of the one or more second regions.

15. The method of any of claims 1-14, wherein the one or more balance scores for each of the one or more second regions are determined based on historical long-term demand values and historical long-term supply values, historical short-term demand values and historical short-term supply values, and real-time demand values and real-time supply values.

16. The method of claim 15, wherein the one or more balance scores for each of the one or more second regions are determined based on a first weight for the historical long-term demand value and historical long-term supply value, a second weight for the historical short-term demand value and historical short-term supply value, and a third weight for the real-time demand value and real-time supply value.

17. The method of any of claims 10-16, wherein the one or more processors are configured to determine a balance score for the first region and to determine a total balance score based on the balance score for the first region and the one or more balance scores for each of the one or more second regions.

18. The method of claim 17, wherein the one or more processors are configured to determine the asymmetric merchant visibility based on the total balance score.

19. A non-transitory computer-readable medium storing computer-executable code comprising instructions for determining asymmetric merchant visibility according to any one of claims 1 to 18.

20. Computer executable code comprising instructions for determining asymmetric merchant visibility according to any one of claims 1 to 19.