HK1198069A - Method and system for selection, filtering or presentation of available sales outlets - Google Patents

Description

Method and system for selecting, filtering or presenting available sales channels

(Cross-reference to related applications)

Provisional application No.61/504017 entitled "METHOD and system FOR SELECTION, fire OR detection available systems outputs" is claimed as priority by 35u.s.c. 119 and is incorporated herein by reference in its entirety.

(copyright notice)

A portion of the disclosure of this patent document contains material which is subject to copyright claims. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever.

Technical Field

The present disclosure relates generally to presenting sales channels to customers. In particular, the present disclosure relates to selecting, filtering and/or presenting sales channels while taking into account user characteristics and characteristics of such sales channels.

Background

There may be many types of sales channels. One example of a sales channel may be a retailer that sells a particular product or service. Another example may be a vendor or supplier that provides goods or services to businesses or individuals. As a specific example, in a supply chain, a manufacturer may manufacture products, sell them to a vendor, and the vendor may in turn sell the products to a customer. As used herein, the term "vendor" refers to an entity that sells products to customers.

Today, customers are able to locate vendors by browsing various websites associated with different vendors. Existing search engines allow customers to search for desired products online. These search engines then return a list of vendors to the user, often in the form of "hot links".

However, the search results may have varying degrees of relevance to the desired product and/or customer. Thus, there is always room for innovation and improvement.

Disclosure of Invention

Customers are becoming more intelligent. This is particularly true in the context of online purchases where searching is readily accomplished. Thus, the customer searches for a product or a sales channel (also referred to as a vendor, a seller, a merchant, etc.) online before performing a purchase. With the increasing popularity of searching products or vendors online before a customer makes a purchase, there is an increasing need to develop systems and methods for presenting candidate vendors based on the user's preferences. However, when a user searches for vendors for which he/she can make a purchase of a product (which may be a live purchase or an online purchase), the candidate vendors may have characteristics that may cause the user to prefer some vendors over others. In fact, certain characteristics may result in a lesser, negligible, or non-existent likelihood of sale for some vendors. Similarly, different characteristics of customers may also result in differences in the probability of a customer purchasing from a particular vendor.

However, in the current field of online commerce, there is a lack of an effective system and method for filtering, selecting, or presenting (collectively referred to as filtering) vendors. Common approaches include listing all possible vendors (sometimes with the ability to sort by price, relevance, or other characteristics) or allowing the user to filter results by price, distance, or other product attributes.

In addition, vendors have similar prioritization difficulties because they receive a large number of leads that often overwhelm the resources available to seek out potential customers (used interchangeably herein with the term customers). In order to effectively identify customers who are more likely to purchase items that they express an interest from among customers who are less likely to purchase, a customer ranking process is also required.

Accordingly, systems and methods for filtering, selecting, and/or presenting vendor accounts for user characteristics and vendor characteristics are desirable so that the systems and methods can be used by both customers and vendors alike to better match customer needs with resource-constrained vendors that have a higher probability of occurrence for successful sales. It is also desirable that the system and method for filtering, selecting and presenting vendors handle a bilateral decision process with the correct and best vendor by matching highly interested customers with features from both sides.

Embodiments of systems and methods for filtering, selecting, and/or presenting vendors may implement the following processes: (a) presenting a ranked list of candidate vendors categorized by the probability that a particular vendor has characteristics that attract a particular customer and therefore results in a higher probability of sale, which in one embodiment may maximize the desired intermediary revenue; (b) the presentation of vendors that are less likely to be selected by the customer is suppressed because their characteristics are not consistent with the customer's needs and are therefore less likely to result in a sale. The same logic for selecting potential customers applies to vendors. Thus, this seeks to identify the ideal pairing of the online user and the vendor.

Embodiments of such systems and methods also work in both directions to filter and select customers that are highly interested in vendors based on vendors that have a higher sales to customers. The filtering and sorting may be based on observation data S of the search products t (members of S may be based on geographic proximity or other sharing characteristics) based on collective behavior of individuals sharing similar search characteristics to those in the same group. Similarly, the algorithm does not require a predetermined customer selection rule for the vendor, it uses a statistical modeling approach by presenting the vendor with the most valuable customers and while preserving the vendor's resources and maximum vendor expected revenue.

Embodiments disclosed herein may have the advantage of considering a richer set of vendor and user attributes and adjusting the experience-based information to calculate the probability of reaching a sale and to identify those features that are most heavily considered in the purchase decision process. In particular, certain embodiments may provide the following advantages:

1) empirically determining a probability of sale by using historical data; and

2) by including additional factors such as, for example, driving time, merchant density, available inventory, collateral welfare, customer loyalty, features related to distance, price, and historical sales activities are not limited.

Some embodiments may also score or filter a set of vendors based on the desired revenue. For example, an embodiment may score a set of vendors for each vendor within a geographic area based on a probability of sale and thus an expected revenue generated for yet another entity.

These and other aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the present disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions and/or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions and/or rearrangements.

Drawings

The drawings and forming part of this specification are included to illustrate certain aspects of the disclosure. It should be noted that the features illustrated in the drawings are not necessarily drawn to scale. A full appreciation of the disclosure and the advantages thereof can be gained by reference to the following description in conjunction with the accompanying drawings, in which like reference numerals indicate like features, and,

FIG. 1 shows a simplified diagram of one exemplary embodiment of a system for presenting sales channels;

FIG. 2 illustrates a simplified diagram of one exemplary network architecture in which embodiments disclosed herein may be implemented;

FIG. 3 shows an illustration of a flow chart for presenting a sales channel;

FIGS. 4, 5, 6a and 6b illustrate representations of screenshots for presenting sales channels;

FIG. 7 shows a diagram of one exemplary embodiment of a method for presenting a sales channel to a customer;

FIG. 8 shows a diagram of one exemplary embodiment of a method of generating a driving distance/time for a zip-code-merchant pair;

FIG. 9 shows an illustration of a screenshot displayed on a client device.

Detailed Description

The present invention and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. It should be understood, however, that the detailed description and the specific examples, while indicating preferred embodiments of the present invention, are given by way of illustration only and not by way of limitation. From the present disclosure, those skilled in the art can easily understand various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the inventive concept underlying the invention. The embodiments discussed herein may be implemented by any suitable computer-executable instructions or any combination thereof, which may reside on a computer-readable medium (e.g., a hard disk drive, flash drive, or other memory) or hardware circuit or the like.

Assuming that vendors are presented to online users interested in product purchases, embodiments of the systems and methods disclosed herein can determine a probability of sale. The probabilities can be used to select, filter, or present (collectively referred to herein as filtering) vendors to the user.

For example, in one embodiment, the sales probability P is viewed from the user's perspective_sHas two components:

1) ingredients reflecting various characteristics of the individual vendor and its product offerings including price, available inventory, collateral benefits offered by the vendor, historical sales performance, and the like.

2) Components that reflect the same features but are expressed relative to other vendors that will also be displayed together.

This process of filtering the list of vendors can be extended to additional benefit the vendors. The complementary action would be for the vendor to apply a filter to the list of users who generated online interest and focus on those users (potential customers) who have a higher probability of purchasing a product. For example, the filter may be used when the availability of vendor resources (e.g., sales personnel, email responders, etc.) available to the seeking interested user is insufficient to provide balanced attention to all users of vendor searches that occur in online products.

From the vendor's point of view, the purchase probability P_bIt may also have two components:

1) a component that reflects various demographic characteristics of individual customers including revenue, family size, net worth, their distance from vendors, historical purchase frequency, historical purchase preferences, and the like.

2) Features describing interactions of a particular customer with a particular vendor, including historical sales (loyalty representatives) of the vendor to the customer, historical sales to others in the local area/neighborhood of the customer, and the vendor's location with respect to the customer. In the case of durable large items that require the purchaser to visit on site, distance to the vendor is an additional interaction factor for the customer.

The bilateral decision processes can be combined into a single metric, i.e., probability of achieving a sale:

P_c＝f(P_s,P_b)

this probability can be used equally by the customer and vendor to better match resource-constrained vendors whose customer needs have a higher probability of occurrence with the probability of success. The systems and methods may thus provide benefits to users and vendors by simplifying customer search times, increasing the revenue of vendors by presenting "correct" products and services to targeted customers of vendors, and allocating sales resources to customers that are more likely to generate sales.

In particular, according to some embodiments, the probability of reaching a sale may be broken down into two parts as the probability of selling to a customer and the probability of purchasing from a vendor. From the customer' S perspective, assuming they are presented in a set of other vendors, the probability S that vendor i sells product t is calculated based on a logistic regression of the form:

here, the first and second liquid crystal display panels are,

θ_i,t,S＝β_o+β₁X_i,t,1+β₂X_i,t,2+...+β_mX_i,t,m+β_qX_i,t,S,q+β_q+1X_i,t,S,q+1+...+β_rX_i,t,S,r+ε_i,t,S，

each X_i,t,k(k ═ 1, …, m) reflects the characteristics of vendor i with respect to product t,

each X_i,t,S,q(q ═ m +1, …, r) reflects the characteristics of vendor i and the other vendors in set S that appear with vendor i with respect to product t.

From the perspective of vendor i, the probability that customer c purchases product t from vendor can be calculated by a logistic regression of the form:

here, the first and second liquid crystal display panels are,

δ_c,t,i＝α_o+α₁Y_c,t,1+α₂Y_c,t,2+...+α_nY_c,t,n’+α_qY_c,i,q’+α_q+1Y_c,i,q+1+...+α_rY_c,i,r‘+ε_c,t,U，

each Y_c,t,k(k '═ 1, …, n') reflects the characteristics of customer c interested in product t,

each Y_c,i,q(q '═ n +1, …, r') reflects characteristics of the historical behavior of customer c purchasing from vendor i.

Rather than considering the components separately and since the bilateral decision process implies interaction between the buyer and the seller, in some embodiments a single value may be calculated based on the following logic function considering the customer and vendor matches:

logistic regression is a statistical method for predicting the probability of occurrence of an event by fitting data to logistic functions. It is an experience-based statistical method for modeling binomial results (sales versus non-sales).

Independent variables that reflect 1) individual vendor characteristics, 2) individual vendor characteristics related to other vendors, 3) individual customer characteristics, and 4) historical preferences of customers may be proposed as potential factors based on their empirical knowledge of the relationship to achieving sales.

In some embodiments, data transformations may be used for variables with large variances or skewed distributions. The miss value may be input based on a suitable estimate, such as using a local average of historical data. In some embodiments, forward, reverse, and step model selection processes available in statistical analysis software (e.g., SAS ProLogistic) may be used to select independent variables. To reduce the variance of certain variables and increase the robustness of the coefficient estimation, scaling or additional derived variables may also be defined. Given the historically displayed vendor, the final model coefficients may be selected such that the resulting sales estimate probability coincides with the actual observed sales action.

In one embodiment, cross-validation may be performed to test the model estimates for consistency. The final data set was randomly divided into two groups for re-fitting the model. The objective is to test whether the model estimates are robust across different sample sets. The final model may also be subject to other types of cross-validation due to changes in market environment, customer behavior, merchant characteristics over time. For example, if the final model data source is collected over a longer time interval, the final data set may be divided in half by time. The final model will then be re-fitted to the "before" and "after" samples to test the consistency of the coefficients over time.

It is clear that there are various uses for such models and algorithms. For example, in one embodiment, such models and algorithms may be used in a Vendor's Vendor Score Algorithm (VSA) or calculation (also referred to as "Dealer ScoringAlgorithm" (DSA), the terms Vendor and trader being used interchangeably herein) that may be used to select, filter, or render products in response to a user-submitted search. For example, after a user specifies his/her geographic location (e.g., ZIP code or address) and a desired product, the VSA may identify all vendors that sell that particular product in the user's local area. The VSA may then score qualified vendors and then present those with the highest probability of sale to the user. The VSA algorithm may incorporate, for example, price-distance tradeoffs, vendor satisfaction, historical performance, inventory characteristics, and network characteristics to derive a probability of reaching a sale for a customer from a certain geographic area. Such VSAs may be used in various customer environments, in various channels, or through various types of products or services.

While embodiments of the systems and methods are applicable to searching for or purchasing almost any product or service that enables purchasing and searching online or offline, embodiments may be particularly useful in the case of searching online or purchasing new vehicles. In particular, in some embodiments, such a VSA may be used to filter vendors' online searches. In particular, in certain embodiments, such VSAs may be used in the context of online car searches to filter online searches for new cars or vendors based on the probability of reaching a sale.

For example, TrueCar (www.truecar.com) is an automated website that provides competitive, public offers. Embodiments of the systems and methods disclosed herein may be used by such web sites in a merchant selection process to present merchants (e.g., 3 selected merchants) most likely to make a sale in a TrueCar network in response to a published price search submitted by a user. In some embodiments, only leads from customers with higher purchase probabilities are sent to the merchant. In this embodiment, the DSA may incorporate various merchant characteristics such as merchant price, driving distance, driving time from the merchant to the customer ZIP code, merchant on-demand benefits, historical performance, merchant location, crowning and inventory. Some scaling variables may be further derived from the merchant characteristics to reflect those characteristics compared to other candidate merchants. Customer attributes such as search vehicle brand, customer local merchant network density, and ZIP code level historical purchasing behavior indicators such as search for sales numbers in ZIP codes are included to model the probability of a unique customer purchasing from a merchant as compared to other users. The expected revenue for each merchant may further be calculated from the combined information from the probability of sale, local demand, and inventory data for the merchant from the DSA model.

It may be helpful here to present a use environment for embodiments of the systems and methods presented herein. It is helpful to an understanding of these embodiments to review the method and system shown IN U.S. patent application No.12/556137 entitled "SYSTEM AND method tools GENERATION IN connection WITH AVEHICLE DATA SYSTEM" filed 9.9.2009, the entire contents of which are incorporated herein by reference. Using the TrueCar website, each user types in his/her ZIP code and their desired make/model/option of the vehicle that is of interest to pricing. In one embodiment, DSA may be used to present 3 TrueCar certified merchants, and for some programs will only represent non-certified merchants. Examples of user observable screens are shown in fig. 4, 5, 6a and 6b, as described below.

Turning now to FIG. 1, a simplified diagram of an exemplary system 100 that includes a brick and mortar computing environment or network 130 of an online scenario provider is shown. As shown in FIG. 1, a user 110 may interact with a website 140 (via a client device communicatively connected to one or more server hosting websites 140) to conduct their product search and may purchase new or used vehicles via the website 140. In one embodiment, the user's automobile purchase process may begin when the user directs a browser application running on the user's computer to send a request to website 140 over a network connection (e.g., over network 120). The user's request may be processed by control logic 180 coupled with website 140 within the brick-and-mortar computing environment 130.

Examples of a user's computer or client device may include a central processing unit ("CPU"), read only memory ("ROM"), random access memory ("RAM"), hard drive ("HD"), or memory and input/output devices ("I/O"). The I/O may include a keyboard, monitor, printer, and/or electronic pointing device. Examples of I/O may include a mouse, a trackball, or a stylus. Also, examples of suitable client devices may include a desktop computer, a laptop computer, a personal digital assistant, a cellular telephone, or virtually any device capable of communicating over a network.

The tangible computing environment 130 may be a server having hardware components such as CPU, ROM, RAM, HD, and I/O. Portions of the methods described herein may be implemented by appropriate software code that may reside in ROM, RAM, HD, database 150, model 190, or a combination thereof. In some embodiments, computer instructions to implement embodiments disclosed herein may be stored on a digital access storage array, magnetic tape, floppy disk, optical storage device, or other suitable computer-readable storage medium or storage device. Accordingly, a computer program product implementing embodiments disclosed herein may include one or more computer-readable storage media storing computer instructions that are interpretable by a CPU to execute embodiments of the methods disclosed herein.

In the illustrated embodiment, the computer instructions may be compiled C⁺⁺A line of Java or other language code. Other configurations may be used. For example, the data may be provided by multiple computers in the physical computing environment 130Distributes and performs the functions of control logic 180. Thus, each of the computer-readable storage media storing computer instructions that implement embodiments disclosed herein may reside on or be accessed by one or more computers in the physical computing environment 130. The various software components and subcomponents including website 140, database 150, control logic 180 and model 190 may reside on a single server computer or any combination of separate server computers. In some embodiments, some or all of the software components may reside on the same server computer.

In some embodiments, control logic 180 may be capable of determining a probability of reaching a sale based in part on a probability that vendor 125i sells products to a customer and a probability that the customer purchases products from a particular vendor 125 i. In some embodiments, information about merchants and vendors 125i known to control logic 180 may be stored on database 150 accessible by control logic 180 shown in FIG. 1.

The control logic 180 may be configured to filter, select, and present to the customer, by using the model 190, a list of vendors 125i that have a higher probability of reaching a sale. The model 190 may be based in part on the probability that the vendor 125i sells products to the customer and the probability that the customer purchases products from the vendor 125i, which may utilize information from a plurality of system components, including data from a list of available merchants and data from the database 150 and the merchants' performance histories, information stored in the database 150 related to the user, and/or information stored in the database 150 related to the vendors 125 a-n.

FIG. 2 illustrates one embodiment of a layout 200 that may be used to implement embodiments of the systems and methods disclosed herein. In particular, layout 200 includes a set of entities including an entity computing environment 220 (also referred to herein as a TrueCar system) and an inventory company 240, an Original Equipment Manufacturer (OEM) 250, a sales data company 260, a financial institution 282, an external information source 284, a motor vehicle Department (DMW) 280, and one or more computing devices at one or more relevant point-of-sale locations, in this embodiment vendors 230, coupled to a computing device 210 (e.g., a computer system, a personal digital assistant, a dedicated terminal, a mobile phone, a smart phone, etc.) via a network 270.

The network 270 may include, for example, a wireless or wireline communication network, such as the internet or a Wide Area Network (WAN), a public switched telephone network (PTSN), or any other type of electronic or non-electronic communication link, such as mail or courier service, etc.

The tangible computing environment 220 may include one or more computer systems having a central processing unit that executes instructions embodied on one or more computer-readable media, where the instructions are configured to perform at least some of the functions associated with embodiments of the present invention. These applications may include a vehicle data application 290 comprising one or more applications (embodied on computer-readable media) configured to implement the interface module 292, the data collection module 294, and the processing module 296. Also, the entity computing environment 220 may include a database 222 operable to store procurement data 224 such as merchant information, merchant inventory, and merchant public pricing, data 226 determined in operation such as a quality score of the merchant, a model 228 that may include a set of merchant cost models or price ratio models, or any other type of data relevant to or determined in the implementation of embodiments.

In particular, in one embodiment, the data stored in database 222 may contain a set of merchants with corresponding merchant information such as the name and location of the merchant, the manufacture sold by the merchant, and the like. The data in database 222 may also include an inventory list associated with each of a group of merchants, including the vehicle configurations that are currently in stock for each of the merchants.

The entity computing environment 220 may provide various functionality, including utilizing one or more interfaces 292, for example, such interfaces 292 being configured to perform the following processes: receiving and responding to queries or searches from users on computing device 210; interfacing with inventory company 240, manufacturer 250, sales data company 260, financial institution 270, DMW 280, or merchant 280 to obtain data; or provide data obtained or determined by the entity computing environment 220 to any of the inventory company 240, the manufacturer 250, the sales data company 260, the financial institution 282, the DMV 280, the external data source 284, or the vendor 230. It is to be appreciated that the particular interface 292 utilized in a given environment can depend upon the functionality implemented by the entity computing environment 220, the type of network 270 utilized to communicate with any particular entity, the type of data obtained or presented, the time interval at which data is obtained from an entity, the type of systems utilized in the various entities, and the like. Thus, these interfaces may include, for example, web pages, web services, data entries or database applications that may be entered or otherwise accessed by an operator, or virtually any other type of interface desired for use in a particular environment.

Generally, through these interfaces 292, the entity computing environment 220 can obtain data from a variety of sources including one or more of the inventory company 240, the manufacturer 250, the sales data company 260, the financial institution 282, the DMW 280, the external data sources 284, or the vendor 230, and store such data in the database 222. This data may then be grouped, analyzed, or otherwise processed by the brick and mortar computing environment 220 to determine the desired data 226 or model 228, which is also stored in the database 222.

A user on computing device 210 may access the physical computing environment 220 through the provided interface 292 and specify certain parameters, such as a desired vehicle configuration. The entity computing environment 220 may select or generate data through the use of the processing module 296. A list of vendors 230 can be determined from the selected data set, which is determined from the processing and presented to the user on the user's computing device 210. In particular, in one embodiment, the interface 292 can visually present this data to the user in a highly intuitive and usable manner.

In particular, in one embodiment, the visual interface may present at least a portion of the selection data set as a price curve, bar graph, histogram, or the like, reflecting at least a portion of the selected data for a quantifiable price or price range (e.g., "average," "good," "very good," "over-bid," etc.) relative to a baseline pricing data point (e.g., invoice price, MSRP, merchant cost, market average, internet average, etc.). The visual interface may also contain a list of vendors 230 having the highest probability of reaching a sale, based in part on the probability of sale from the customer's perspective and the probability of purchase from the vendors' perspective.

Turning to various other entities in the layout 200, the vendor 230 may be a sales channel for vehicles manufactured by one or more of the OEMs 250. To track or otherwise manage sales, finance, departments, services, inventory, and post-office management needs, the vendor 230 may use a merchant management system (DMS) 232. Since many DMS 232 are Active Server Pages (ASPs) based, the transaction data 234 may be obtained directly from the DMS 232 by a "key" (e.g., an ID and password with set permissions within the DMS system 232) that enables retrieval of the data from the DMS system 232. Many vendors 230 may also have one or more network points accessible over the network 270.

Additionally, the vendor's current inventory may be obtained from the DMS 232 and correlated with merchant information in the database 222. The vendor 230 may also provide one or more open prices (on the network 170, in some other electronic format or in some non-electronic format) to the operator of the entity computing environment 220. Each of these public prices can be associated with a vehicle configuration such that a listing of vehicle configurations and associated public prices can be associated with the vendor 230i in the database 222.

The inventory company 240 may be one or more inventory polling companies, inventory management companies, or inventory aggregators that may obtain and store inventory data from one or more of the vendors 130 (e.g., obtain such data from the DMS 232). The inventory polling company is typically commissioned by the vendor to pull data from the DMS 232 and format the data for use on the website and by other systems. The inventory management company manually uploads inventory information (photos, descriptions, specifications) on behalf of the vendor. Inventory aggregators obtain their data by "crawling" or "acquiring" web sites that display inventory content and receiving direct feeds from inventory web sites (e.g., Autotrader, ford vehicles.

DMV 280 may also contain any type of government entity to which a user provides data related to a vehicle. For example, when a user purchases a vehicle, it must be registered by a country (e.g., DMV, Cynanchum paniculatum) for tax and topical purposes. For tax purposes, this data typically contains vehicle attributes (e.g., year, make, model, mileage, etc.) and the price of the sales transaction for tax purposes.

Financial institution 282 may be any entity, such as a bank, savings loan, credit union, etc., that provides any type of financial service to participants participating in a vehicle purchase. For example, when a buyer purchases a vehicle, they may utilize a loan from a financial institution, where the loan process typically requires two steps: applying for a loan and entering into a loan contract. These two steps may utilize vehicle and consumer information in order for the financial institution to properly evaluate and understand the risk prediction for the loan. Generally, loan applications and loan agreements contain proposed and actual vehicle sales prices.

Sales storage 260 may include any entity that collects any type of vehicle sales data. For example, a federated sales data company aggregates new and used sales transaction data from the DMS 232 system of a particular vendor 230. These companies may have formal agreements with the vendors 130 that enable them to retrieve data from the merchants 230 for the purpose of federated collection of data for internal analysis or external purchase of data by other data companies, merchants, and OEMs.

Manufacturers 250 are those entities that actually build the products sold by vendor 230. To guide pricing of their products, such as vehicles, the manufacturer 250 may provide an invoice price and Manufacturer Suggested Retail Price (MSRP) for vehicles and options for those vehicles-used as a general guideline for the cost and price of merchants. These fixed prices are set by the manufacturer and may vary slightly with geographical area.

The external information sources 284 may include any number of other various sources online or otherwise that may provide other types of desired data, such as data regarding vehicles, pricing, demographics, economic conditions, markets, venues, consumers, and so forth.

It should be noted here that in embodiments of the present invention, not all of the various entities shown in layout 200 are necessary or even desirable, and some of the functionality described with respect to the entities shown in layout 100 may be combined into a single entity or eliminated altogether. Additionally, in some embodiments, other data sources not shown by layout 200 may be utilized. Accordingly, the layout 200 is merely exemplary and is in no way to be construed as setting forth any limitations on embodiments of the present invention.

Before delving into the details of the various embodiments, it may be helpful to again give a general overview over the above-described layout embodiments using the exemplary merchandise of the vehicle. At certain intervals, the entity computing environment 220 may then be obtained by collecting data from one or more of the inventory company 240, the manufacturer 250, the sales data company 260, the financial institution 282, the DMW 280, the external data source 284, or the vendor 230. This data may include sales or other historical transaction data for various vehicle configurations, inventory data, registration data, financial data, vehicle data, public prices from merchants, etc. (various types of data obtained will be discussed in more detail later). The data may be processed to produce a data set corresponding to a particular vehicle configuration.

Then, at some point, a user on the computing device 210 may access the physical computing environment 220 by using one or more interfaces 292, such as a set of web pages provided by the physical computing environment 220. Using this interface 292, a user can specify a vehicle configuration by defining values for a certain set of vehicle attributes (make, model, repair, drive train, options, etc.) or other relevant information such as geographic location. Information related to the prescribed vehicle configuration may then be presented to the user via interface 292. This information may include pricing data corresponding to the specified vehicle and public pricing information and/or a list of vendors 230i with the highest probability of achievement.

In particular, a list of vendors 230i with the highest probability of reaching a sale may be determined and visually presented to the user on the computing device 210. In other exemplary embodiments, the user may be presented with a list of possible vendors 230i that have the highest revenue generating for the parent organization associated with the entity computing environment 220. The revenue for the parent organization may be based in part on the probability of reaching a sale along with the revenue factor.

Turning now to FIG. 3, one embodiment of a method for determining a vendor to present to a user is illustrated. In step 310, assuming a particular vendor is present in a set of vendors, a probability (P) that the vendor sells the product to a user interested in purchasing the product may be determined (P)_s). In one embodiment, for example, the probability (P) that a particular vendor sells a product to a user_s) Two components may be included. The first component may reflect various characteristics of a particular vendor, and the second component may reflect characteristics that are the same as the first component but expressed with respect to other vendors within a set of vendors.

In step 320, given the user's historical preferences, a probability (P) that the user purchased a product from a vendor may be determined_b). In one embodiment, for example, the probability (P) that a user purchases a product from a vendor_b) Two components may be included. The first component may reflect various demographics of an individual customer, while the second component may reflect the interaction of an individual customer with a particular vendor.

In step 330, a probability (P) of each vendor within the group reaching a sale may be determined_c) Here, (P)_c) Is (P)_s) And (P)_b) As a function of (c). As discussed above, the bilateral decision process may be expressed as:

P_c＝f(P_s,P_b)

in step 340, based on (P) associated with each vendor_c) One or more vendors from a set of vendors are selected. Probability of achieving sale (P)_c) Can be used by both customers and vendors to better match the customer's needs with vendors that have a higher probability of occurrence for successful sales. In other exemplary embodiments, one or more vendors from a set of vendors may be selected based on a desired revenue factor for each vendor.

In step 350, one or more selected vendors may be presented to a user interested in purchasing a product through a user interface on a user device associated with the user. By presenting the user with one or more selected vendors, the user may be presented with only a subset of the original set. Thus, by only displaying the vendors with the highest likelihood of completion, the benefits of the user and the vendors can simplify the search time for the customer while increasing the revenue for the vendors.

FIG. 4 illustrates one embodiment of an interface 400 provided by the TrueCare system for presenting the user with the public pricing information 420 for a particular vehicle configuration in conjunction with the presentation of pricing data for that vehicle configuration. Within interface 400, a user may be able to enter information relating to a particular make and/or model of a vehicle. Within interface 400, the user may also enter geographic information such as a zip code associated with the user. In response, the TrueCare system may generate a price report 410 and present it to the user via the interface 400.

Price report 410 may include a gaussian curve 430 showing a normalized distribution of pricing (e.g., a normalized distribution of transaction prices). On the X-axis of the curve, the average price paid may be displayed along with the determined merchant cost, invoice or bid to represent the association and relationship of these prices to the transaction price. The determined "good", "very good", "over-priced" equivalent grid ranges are also visually displayed under the display curve to enable the user to recognize these ranges.

Additionally, the pricing information 420 may be displayed on the x-axis as a visual indication so that the user can see where the pricing information 420 pertains to other presented prices or price ranges within the geographic area.

FIG. 5 illustrates an embodiment of an interface 500 for presenting merchant information related to pricing information. The interface 500 may represent the top three merchants 520, 530, 540 (2010 Ford Explorer RWD 4DR XLT near ZIP code 02748) of a particular make and model of vehicle 510 after clicking "locator". For each address, the interface 500 may contain merchant information, pricing data, vehicle configuration data, and instructions for obtaining a offered public price from the merchant for the particular make and model of the vehicle 510.

Based in part on the make and model of the vehicle 510, the interface 500 may present one or more vendors 510, 520, 530 to a user interested in purchasing the vehicle 510. One or more vendors 510, 520, 530 may be determined and/or selected based in part on a probability of reaching a sale associated with each vendor within a set of vendors.

Interface 500 may also contain a form 550 into which a user may enter personal information such as the user's name, address, and contact information. The user's personal information may be utilized to more accurately or efficiently determine the probability of the vendor reaching a sale.

Referring to fig. 6A and 6B, the identities of rated (at least partially using embodiments of DSA) merchants 610, 620, 630 are displayed or presented to potential customers through interface 600 along with a price guarantee and any merchant collateral benefits (note that in fig. 6B, the colloid Ford has two listed collateral benefits: free local shipment and express checkout) when entering personal information.

Some embodiments OF DSA are shown in patent application No.12/655462 entitled "SYSTEM, method and PROGRAM PRODUCT FOR predictive value OF LEAD" filed on 30.12.2009, which is incorporated herein by reference in its entirety. Here, it is helpful to describe more details about one such embodiment of how DSA for this case may be implemented.

a. Description of data

1) DSA data

Based on data collected, for example, from 9 months 2010 to 4 months 2011, there were a total of 82994 non-mismatched sales and 18296 mismatched sales. Mismatched sales are sales from customers who do submit leads but appear to the vendor not to submit leads to the vendor by selection or because the DSA has not selected. In one embodiment, the mismatch is identified by comparing the merchant identification code listed in the first three digits with the merchant identification code of the seller. If the seller is not in the first three digits, a mismatch occurs.

Since historical merchant achievement rates and other merchant performance variables are calculated by using a 45 day moving window. Sales that occurred after 10, 15 days 2010 were included in the final model sample. 634185 observations and 81016 sales were used in the final model. Due to the lack of missing vendor's price offset information, we only contained 4263 mismatches (5.3%) in 81016 sales for which the price offset is available in the final model. Non-mismatches are defined as those sales that occur based on DSA by one of the three recommended merchants. Mismatch conditions are defined as those that occur by other merchants who are not recommended by the top three DSA or those that show the vendor but do not generate a lead.

The grouping may be a list of vendors responding to a single user query. An example of a grouping is a list of DSA candidate merchants that may be used to sell vehicles requested in distinct user queries. In one embodiment, three merchants in the group are selected for display to the user. In one embodiment, packets with leads of less than 15 days may also be excluded because leads take time to transition to sales, and those leads may be excluded to prevent underestimating the trader's rate of attainment.

2) Driving distance data

Com obtains the driving distance and driving time from the search ZIP to the location of the merchant. In the case of a missing value, the driving distance and the driving time are input based on the average driving distance of similar nearby ZIP codes and a large circle distance ratio.

3) Stock data of businessmen

The merchant's new vehicle inventory information may be obtained from a data feed provided by the merchant.

b. Feature(s)

In one embodiment, at least four types of features may be considered in the achievement probability calculation in the algorithm.

1) Features describing a single vendor (X)_i,t）

Each vendor has certain special features that may cause the user to prefer one over the other. These specific factors include vendor price, available inventory, server and accompanying welfare and historical performance, etc.

Price always plays an important role in the competitive market. Price offsets that differ from the invoice price of a vehicle are considered to be important factors in DSA models. To reduce the large price variance of different vehicles, a price offset, which is a percentage of the invoice price, is used as the primary price variable in the model. For those merchants who do not offer public prices or have monopoly prices, the program maximum is used for their price offset. The program maximum may be an upper limit of the price offset set by a particular program. Once the merchant's public price is greater than the program maximum, the program maximum may be displayed to the user instead of the merchant's price. Also, some merchants do not provide price offsets for certain cuts; these cases are considered monopolized prices. When the trader has a monopolized price, the program maximum is used for display.

In one embodiment, the DSA model adds to the merchant's overall new vehicle inventory as a factor in the model because the customer has indicated that the unavailability of the vehicle is a large cause of missed sales or failure to reach sales. Customers may suspect whether they are unable to get those cars they see on the price certificate when they arrive at the business. Therefore, new inventory values are introduced as variables to measure the total agent size. It is reasonable to assume that a large agent will have a higher probability of having a searched vehicle than a small agent. Heretofore, merchants that do not provide inventory information have been given an average of the inventory in the candidate merchant list for each group.

Car purchasers also consider warranties, maintenance, and other services in making decisions, in addition to the vehicle itself. A website using an embodiment of DSA may display specific services of the merchant along with their public price and location in the search results. Thus, whether a merchant offers a particular service is also considered a potential factor that may affect the probability of reaching a sale. The "with benefit" pseudo variable is defined as "1" if the merchant offers any of the services such as limited warranty, refund guarantee, free scheduled maintenance, quality check, shipping, free car wash, and "0" otherwise.

The probability of sale is also highly correlated with the historical performance of the merchant. Merchants with excellent marketers and good reputations should have a higher rate of achievement than others. These factors are measures derived from their historical achievement rates. In one embodiment, the DSA model calculates the respective trader's achievement rate based on their performance over the previous 45 days. The 45 days may be selected as the moving window because it is a historical performance of the provider but may also quickly reflect the changing mid-length time of the entire vehicle market due to factors such as gas price changes or new model releases. For details of the calculation of the merchant achievement rate, see the following formula 1. Since some merchants only take directions from areas located 60 miles or closer. The achievement rate is based only on sales and guidance within a driving distance of 60 miles. When the achievement rate is missed due to no sales or guidance within the past 45 days, a Designated Market Area (DMA) average or any other geographical boundary average achievement rate is used.

The merchant achievement rate (sales count over the past 45 days)/(sales count over the last 15 days + lead count over the last 30 days) is given by equation (1)

To better predict the agent's inventory status and to weight the merchant's recent performance more heavily, another variable "crown army" may be added to the model as another type of performance measurement variable. The crown champion assigns a higher weight to recent sales than to previous sales. For example, if yesterday were to have a successful sale than 30 days ago, the merchant would get more credit. Suppose that a merchant who has recently sold a brand will have a higher chance of having similar cars in their inventory than a merchant who has not sold for some period of time.

The vehicle brand is another merchant characteristic that can affect the probability of reaching a sale. Different brands may have different probability functions. For example, in one embodiment of the DSA algorithm, the Mercedes-Benz merchant exhibits a different pattern than other brands and the rate of reach of the Mercedes-Benz merchant is relatively high compared to network merchants selling other brands.

2) Features (X) of a single vendor compared to other vendors_i,t,S）

The absolute value of the attributes of a single vendor does not affect its merit or competitiveness. These features are confirmed by comparison with other vendors. Thus, in our algorithm, vendor characteristics relative to other competitors are important factors in predicting sales probability.

In one embodiment of the DSA algorithm, the majority of the individual merchant characteristics, such as driving time, price drift, historical achievement rate, inventory, and crown army, are retuned among all candidate merchants in each group. Readjusting historical merchant achievement rate, new vehicle inventory, of individual merchants by using the following equation:

readjust driving time, coronal march, price by using different equations:

all readjusted variables may range from 0 to 1. When readjusting the variables, different equations may be used, as it may be desirable to get the value 1 for the best merchant for all merchant characteristics. For example, the merchant with the highest historical achievement rate may receive a readjusted achievement rate of 1, and the merchant with the lowest achievement rate may receive a value of 0. Similarly, the merchant with the shortest drive time may obtain a value of 1 and the merchant with the longest drive time may obtain a value of 0.

The pseudo-variable indicates the best price and also contains the price and distance of the nearest merchant to compare the merchant against others. For the case where the maximum and minimum values are not significantly different, additional variables for measuring the absolute difference in price and drive time can be constructed to adjust their impact on sales.

Network merchant density is another factor related to merchant i (a vendor of some type) itself and another merchant j in proximity to the merchant. Merchants need to compete with others in areas of high merchant density and will have dominance in areas of low merchant density. In one embodiment, the brand and merchant density interaction is considered only for the same brand level. However, merchants with similar brands (e.g., Nissan and Honda) may also be competitors.

3) Features (X) describing individual customers_c,t）

Demographics of individual customers may result in products having different interests and purchasing the same product from different vendors. These factors may include income, home size, net worth, gender, historical purchasing behavior, and the like. Such user data may be obtained from common data sources such as U.S. census data or online user databases of different industries.

In one embodiment of the DSA algorithm, the purchase probability (P) is predicted for the packet_b) Including the vehicle brand searched and the customer local merchant density. The customer's vehicle brand selection is a potential indication of customer revenue, family size. Those buying luxury automobiles are likely to be less price sensitive and more time sensitive to driving. In this case, the DSA algorithm may weight the distance more heavily when the customer is from a high income ZIP code to increase the probability of attainment (P)_c). It can also be assumed that price is more important in sales to customers located in large cities with high merchant densities, while distance is more important to people located in rural areas where only 2 agents are available in 200 miles. Using available merchants within a certain driving time radiusAs a customer local merchant density variable. Including pseudo-variables for each brand in the model selection process using statistical software (e.g., SAS Proc logic), three of the 35 brands (Mercedes-Benz, Mazda, Volkswagen) result in distinct p-values for their pseudo-variables, indicating that the three brands have different sales probabilities compared to the other brands. Also, brand and merchant density interaction items were tested and the interaction between Mercedes-Benz and merchant density remained significant. Therefore, these factors may also be included in embodiments of the model for DSA. Although brand and network characteristics do not affect the merchant rank within each group since each group has the same brand and density information for different candidate merchants, these factors will affect the desired revenue (e.g., for merchants, or for entities that are guided by merchant payments such as TrueCar) since these three brands have different sales probability functions than other brands.

In addition to demographics, a customer's historical purchasing preferences may also affect a person's purchasing behavior. These types of factors are transaction frequency and transaction amount, the purchase level category (low, medium, high) in which its exchange is traded, previous purchase history, etc. A customer may purchase a 2-door Mini Cooper before wishing to purchase a 4-door car that may be used in a different environment. Thus, the brand's previous purchase selection, vehicle body type, is also an indication of the next purchase.

4) Features (Y) describing the interaction of a particular customer with a particular vendor_c,i）

With respect to car purchases, distance is the most important interaction item between the customer and merchant that affects the purchaser's decision. The same is true for large products similar to vehicles. In one embodiment, the great circle distance of the businessman may be considered. However, some areas have islands and Lakes (such as Great Lakes or Long Beach in new york), where driving distance may be a better indicator of distance than Great circle distance. Since the same driving distance at different locations may involve different driving times, driving times may also be used in embodiments of the DSA model. For example, 60 miles in a rural area may involve 1 hour of driving, but in a large city may be 2 hours or more. Thus, drive time may be a variable that may be comparable to people in different locations.

To capture the sales versus distance relationship for some special cases, five driving distance derived pseudo variables were developed that indicated whether the merchant was within a certain distance range. The driving times of the nearest and the farthest merchants may not differ much. In these cases, these variables will adjust the weight on the shortest drive time so that we do not overestimate the impact of the shortest drive time on sales.

Additionally, merchant locations are also important for sales when customers are located at a juncture of two states. Because vehicle regulations and registration rules differ, people may tend to travel to merchants located in the same state as the state they belong to. A "same state" pseudo-variable is therefore included in our model to indicate whether the customer and merchant are in the same state.

In some cases, some merchants have a prominent performance in a certain ZIP code area compared to their average performance across all ZIP codes. This may be due to some customer demographics in a certain ZIP code. For example, a denser ZIP code for immigrants whose first language is not english may go to an agent where a salesperson may speak their first language or where a merchant website has their first language. Therefore, the DSA model embodiment also includes the variable measurement merchant's performance in certain ZIP codes. It is defined as the number of sales a particular customer in the past 45 days searches for a ZIP.

Additionally, if they have previously purchased a car from a merchant, the customer may also travel to the same merchant. Customer loyalty impact may be more apparent in some other industries that offer services rather than actual products. It may be one of the most important factors in predicting the probability of a particular customer purchasing from a certain vendor.

Operationally, embodiments of DSA may use the estimation model by substituting values of independent variables into the model, calculating probabilities for each candidate merchant in a set s, and presenting the merchant with the highest probability of attainment to customer c.

The following is a non-exclusive list of variables that may be used in the DSA model:

proximity of

Merchant achievement rate

Price

Selection of

Business with benefits/benefits

Customer residence attributes

Additional customer attributes

o credit rating

o garage data (vehicle current owner of the same brand, etc.)

Additional merchant attributes

o Profile integrity

o merchant rating

o customer satisfaction level

o merchant payment history

Transaction attributes

Type of transaction (e.g., rental, cash, credit)

Business (i.e., whether or not it includes a business vehicle)

As an example, DSA may consider locating a ZIP code Z (Z is 1, …, Z) located in the same region_L) The user in (1) sells all merchants (i ═ 1, … K) of the same decoration (T ═ 1, …, T) (if the driving time distance from the customer's search ZIP code center to the merchant's location is less than or equal to 3 hours, Z ∈ L). Model usage is based onLogistic regression of inventory, DSA historical data, driving distance, and combined data with business benefits.

Here, θ_i，t，S＝β_o

{ characteristics of individual traders i }

+β₁Price of x merchants within each group

+β₂x inventory of merchants within groups

+β₃x business's attendant welfare

+β₄Historical achievement rate of x merchants

+β₅Coronal army of x businessman

+β₆x decorative t sold by Mercedes-Benz

+β₇x possibility of Merchant i paying to mother company

+β₈x if Merchant i completes the Profile

+β₉x grade of trader i

+β₁₀Customer statistics for x Merchant i

{ characteristics with respect to other candidate traders i, S }

+β₁₁x Mercedes-Benz Brand and Density interaction

+β₁₂x Mazda Brand and Density interaction

+β₁₃X Volkswagen brand and density interaction

+β₁₄x if the trader has the shortest driving time

+β₁₅x if the trader has the lowest price within each group

+β₁₆x difference between merchant's price and maximum price offset in percent of invoice

+β₁₇Difference between X businessman's driving time and shortest driving time businessman

δ_c,t,I＝α_o

{ characteristics of individual customers c }

+α₁x family income of customer c

+α₂x family size of customer c

+α₃x size of residence for customer c

+α₄Count of merchants within x 30 minute drive

+α₅Count of merchants within x 1 hour of driving

+α₆Count of merchants within x 2 hours of driving

+α₇x whether customer c has previously purchased the model or brand

+α₈x credit worthiness rating of customer c

+α₉x garage data of customer c (whether customer c is the current owner of the same brand of vehicle, etc.)

+α₁₀x transaction type (lease, cash, credit, etc.)

+α₁₁x is a transaction related to a potential purchase

{ features describing the interaction of customer c with merchant i }

+α₁₂x time of driving from customer c to merchant i

+α₁₃x whether customer c has previously purchased from merchant i

+α₁₄x number of sales of Merchant i in ZIP code of customer c

+α₁₅x if merchant i is within 10 miles of customer c

+α₁₆x whether merchant i is within 10-30 miles of customer c

+α₁₇x whether the merchant i is within 30-60 miles of the customer c

+α₁₈x whether merchant i is within 60-100 miles of customer c

+α₁₉x whether merchant i is within 100-250 miles of customer c

+α₂₀x if the merchant i is withCustomer c is in the same state

+ε_c,t,j

Although each of the above factors is used to determine the probability (P) of achieving a sale_c) Is critical, but the embodiment need not give every factor in DSA. For example, in an embodiment, a DSA may contain the following features for a single merchant: price (beta) of the merchant in each group₁) The inventory of the merchants in each group (beta)₂) Historical achievement rate (beta) of the merchant₄) And a driving time (alpha) from customer c to merchant i as a feature describing the interaction of customer c with merchant i₁₂）。

Although the merchant level may change if the customer characteristics and customer historical preference variables are excluded from the DSA, it may be decided to include them in an embodiment of the DSA model, since the total achievement probability may be different for different brands. This probability can be applied to calculate the expected revenue for each merchant, and this amount will be influenced by the choice of brand and the customer local merchant density.

The determination of P is now described by these exemplary parameters_cAnd selects a non-limiting example of a set of merchants i for presentation to interested customer c: search for zip ═ 01748 "Hopkinton, MA, Make ═ Toyota", Trim _ id ═ 252006 ", Trim ═ 2012 Toyota RAV4 FWD 4dr I4 sport".

TABLE 1

As shown in table 1, the weights or coefficients may be related to features utilized in the DSA model. For example,if merchant i is closer to customer c (e.g., driving distance or DD is smaller), then merchant i will have a higher coefficient than another merchant that is further from customer c. Also, the feature with "_ i" may be a dual-mode attribute, where the attribute is added to the DSA arbitrarily or not. The characteristic of the retuning may be the retuning variable described above. Std represents the standard deviation of the coefficient, Pr>ChiSq may represent whether an attribute is important, and odds ratio represents the relative importance of an attribute. The network attributes may represent the competition or number of other networked merchants within the geographic area. By using the above coefficients for the attributes, the DSA model can determine P_s、P_b。

Table 2 below shows by way of example the attributes of a group of merchants i (dealership _ id) that are closest to customer c and that sell the specific vehicle trim that customer c is interested in purchasing. In this non-limiting example, "gcd", "drive _ time", and "drive _ distance" may be raw data/attributes related to a distance variable from merchant i to consumer c. For example, "gcd" may represent the air distance ("fly-by-crow") from merchant i to consumer c, and "drive _ time" may represent the driving time distance in seconds from merchant i to consumer c, and "drive _ distance" may represent the driving distance from merchant i to consumer c. "DD 10", "r _ DT", "DT _ diff" may represent the calculated attributes of the variables of each merchant i within group S. For example, "DD 10" may represent a dual mode variable when a merchant is within 10 miles of consumer c, "r _ DT" may represent a retuned driving time relative to other merchants in the group, "DT _ diff" may represent a retuned value between merchant i and the maximum driving time distance of consumer c within group S.

TABLE 2

Table 3 below represents the attributes of merchant i that are closest to consumer c. "Price _ offset" represents the difference between the Price at which merchant i sells the vehicle and the Price of the "invoice". And, "Min _ price _ i" and "pct _ offset _ diff" represent the calculated attributes of the variables of the respective merchants within the group. Specifically, "Min _ price _ i" is an attribute that reflects which merchant i within group S has the lowest price, and "pct _ offset _ diff" represents the price percentage difference between the price at which merchant i sells vehicles and the highest price at which merchant i sells prices within group S.

TABLE 3

Table 4 below represents attributes associated with a particular merchant in table 3. Note that in this case, the merchant "9054" is shown as the "coronet in the group. Merchant "7708" is shown as having an achievement rate of 1.00 and is not in the same state as consumer c.

TABLE 4

Table 5 below represents the P-base_cExample of the DSA rating of (1), P_cCan be expressed as:

here, the first and second liquid crystal display panels are,

Z＝6.8384+DD10*2.934+DD30*2.3662+DD60*1.5721+DD100*0.9368+DD150*0.3467+min_DT_I*1.0288+min_price_I*0.3095+0.1758*r_inventory+0.0654*perks+3.6415*r_DT+0.5079*r_defending_champ+2.2467*r_price-0.1204*dealer_cnt_120-1.5562*DT_Price+0.2872*r_zip_sale+0.3175*same_state+0.1961*r_CR-0.1303*DT_diff+7.819*pct_offset_diff-0.1316*dealer_cnt_30+1.7942*make_id27-0.0964*dealer_cnt_60-0.0332*make_id26_d-0.7554*make_id27_d-0.0147*make_id40_d

TABLE 5

In this non-limiting example, merchants "3730", "9054" and "9756" from Table 4 are selected for presentation to consumer c based on their DSA rating. Table 5 shows an example of a merchant that may present or display a selection on a display of a client device associated with a potential customer. Those skilled in the art will appreciate that while dealership "8086" has the lowest price for the product, it is not included in the highest ranking dealership due to other attributes such as distance to the customer.

In some embodiments, the potential revenue that a parent organization may receive as a result of a transaction of merchant i with consumer c may be considered. For example, assuming that the expected revenue associated with merchant "9756" is significantly less than the expected revenue associated with merchant "6895", then even though merchant "9756" has a higher DSA rating than merchant "6895", it may be an option to present merchant "6895" to consumer c.

In some embodiments, the expected profit ER for an individual merchant may be calculated by using the following equation:

ER＝P_c·R_g·θ_n

here, ER represents the expected benefit from guidance, P_cRepresenting the probability of reaching a sale, R_gRepresenting the total revenue from sales, θ_nRepresenting a net revenue adjustment. In one embodiment, the total profit R may be generated from a linear regression model_g. In various embodiments, the total profit R may be determined from a business model, a multiplicative model, or any other type of model of a parent company_g。

As a non-limiting example, the total profit R_gCan be expressed as follows:

R_g＝Xβ

here, the β coefficient is determined from least squares regression, and the X matrix contains a variable selected as a difference value of the isolated estimation gains.

In particular, the benefit equation may be expressed as follows:

R_g＝β_o

+β_1ix an indication of the brand of vehicle being purchased,

here, i represents the brand of the vehicle

+β₂x (if the transaction type is Lease)

+β₃x (if the transaction type is Finance)

+β₄x (if there is an operation)

+β₅x (New car indication)

+β_6kx (indication of affinity partner)

Here, k representsAffinity partners

In one embodiment, all of the total revenue thus calculated is multiplied by their net pay ratio to account for the difference in the likelihood of payment for each agent. To achieve this, a separate multiplication factor θ may be applied_nHere, θ_nTo be estimated as the net pay ratio. Note that θ_nMay be calculated based on a series of variables in the linear regression, or may be a simpler factor such as a rolling 12-month window of payment history for a given merchant. For example, for merchant Z, the total bill billed to merchant Z over the past 12 months (by an intermediate entity such as a TrueCar system implementing the invention disclosed herein) would be $10000, but its total payment (due to rebates and/or payment failures, etc.) may only be $ 7800. Thus, for merchant Z in this example, the net payout ratio would be θ_n＝0.78。

These components may then be integrated (e.g., by the DSA module) to show a merchant to obtain an intermediate expected profit ER (ER P) to a customer-based (lead) request from a particular vehicle to that particular customer_c·R_g·θ_n）。

Thus, not only can consumers benefit from the DSA disclosed herein by reducing search time and money, but also intermediaries can benefit. Also, vendors may benefit from the DSA disclosed herein. For example, a merchant may adjust their particular characteristics to increase the achievement rate, better manage their inventory by reducing storage costs, and/or increase reserves by avoiding potential loss of product shortages.

In some embodiments of DSA, all expected revenue for each merchant in local region L (within a driving distance radius of 60 mi) may be calculated by using the following equation:

here, d_t,zIs a requirement for the decoration t in ZIP codes z, n_i,tIs the stock of the decoration t of the merchant i, pi_i,tIs the revenue of each sale (constant or different across all decoration/merchant pairs), σ_t,sReflecting the substitutability of decoration. For example, if the user becomes the master of the vehicle trim a, there is a possibility that he/she can actually purchase the vehicle trim B. Alternatives arise when a purchaser is presented with on-site inventory that may be different from his/her on-line search.

Independent variables that can affect the sales of the vehicle are included in the variable selection process. The purchase offset is converted to a percentage over the invoice price so that prices are offset in the same proportion among different automobile brands. Merchant-related features are recalled in a group to reflect their impact on other merchants. Some non-readjusting variables may also be included to avoid overestimating the best price or the impact of the nearest merchant on sales when the best price and the worst price are not related too much or both are within the same distance range. Given a historical display of merchants, the final model may be selected by maximizing the percentage of correspondence in the logistic regression so that the resulting sales estimation probability may be most consistent with the actual observed sales behavior.

Various types of cross-validation may be applied to the DSA model. For example, the final data set may be randomly divided into two groups for A-B testing, and may also be divided into two portions according to two time windows.

Embodiments of the DSA disclosed herein may also be applied to the merchant side by rating customers according to the probability of purchasing a vehicle from the merchant. In some embodiments, all merchant characteristics may be fixed, and the probability of sale may be based on characteristics of the customer, such as its family income, gender, choice of car brand, distance to the merchant, customer loyalty, and customer local merchant density, among others. Demographic information such as average revenue, average home size, and historical merchant preferences from the population of the same ZIP code would be a good estimate input for each unique group. The probability of sales of a decoration t for a customer c of a group of interested customers U can be calculated by using the following function:

examples of latent variables are as follows:

δ_c,t＝α_o

{ characteristics of individual customers c }

α₁x family income of customer c

α₂x family size of customer c

α₃x size of residence for customer c

α₄Local merchant density of x customers

α₅x whether customer operates used car

α₆x type of payment (e.g., cash or finance) of customer c

{ features describing customer c interaction with merchant }

α₇x distance from customer c to merchant

α₈x if customer c has previously purchased from a merchant

α₉x number of sales of merchant in ZIP code of customer c

α₁₀x if customer c is in the same state as the merchant

+ε_c,t,i

Once customers are rated by the probability of purchase from the merchant, the sales person can better assign their impact and time by first arriving at customers with higher purchase opportunities. More advertising and marketing efforts should target those populations and areas with higher purchase probabilities.

Fig. 7 illustrates an exemplary embodiment of a method using a DSA model. Map data 700 may be data that maps between merchant information 710 and customer information 720 generated from multiple sources, such as merchant-related information 710 and potential customer-related information 720.

Merchant information 710 may include information 725 provided by the merchant, observation performance 730 of the merchant, and merchant information 735 about other merchants. The merchant-provided information 725 may be information contained such as the location, collateral benefits, inventory, and pricing of products sold by each merchant in a group of merchants. This information may be provided by and/or communicated from each of the individual merchants. However, if the merchant is not on the network or otherwise provides merchant information 725, the merchant information 725 may be collected or obtained through a network search, from manufacturer data, or any other source.

Observed performance 730 of the merchant may be correlated to performance of the individual merchant, such as the merchant's achievement rate. First, the observed performance 730 of the merchant may be set to search a data set or module, such as the DSA model discussed above. This information may be used to update and/or modify the observed performance 730 of the merchant as more data is collected and transmitted through the feedback loop 780. In particular, the research data set may be a set of coefficients and variables that are initially based on empirical data, and these coefficients and variables may be adjusted, updated, and/or modified based on further interaction with potential customers and merchants. Thus, as more data, such as merchant information 710 and/or customer information 720, is accumulated, an updated DSA model may be determined, which may adjust the observed performance 730 of the merchant.

Merchant information 710 may also contain merchant information 735 relative to other merchants (competitors). This information may be based in part on merchant provided information 725 relating to merchants stored in the database and online third party mapping services. The data may be normalized data for one merchant in the geographic area to other merchants in the geographic area. For example, if a first merchant has a price for a particular product, an incremental relationship may be determined by comparing the price for the particular product of the first merchant with the prices for the particular products of other merchants within the geographic area. Similarly, merchant information 725 may include normalized driving times to merchants within a geographic area relative to other merchants. The geographic area may be a radial distance from the potential customer, a geographic area associated with a drive time from the potential customer, and/or a geographic area containing a threshold number of potential merchants. For example, a geographic area may contain a threshold number of merchants within a driving time distance from a potential customer. An exemplary range for such a threshold number may be 6-10. In embodiments, merchant information relative to other merchants may be updated dynamically, daily, weekly, and/or monthly.

Customer information 720 may be information related to a potential customer. For example, customer information 720 may contain information pertaining to customer merchant relationship 740, such driving times from a potential customer to a particular merchant, or the number of alternative merchants within a geographic area associated with the location of a potential customer.

The customer information 720 also includes customer supply information 745, such as the location of the potential customer, income of the potential customer, and vehicle preferences of the potential customer, which may include make/model/trim. In an embodiment, the customer information 720 may be obtained by the potential customer by typing data directly into a web form on a website. In another embodiment, this may be done by a process such as yahooOr AAAObtain customer information 720, which may have previously obtained and mapped customer information 720 such as age, income, and location from potential customers. In another embodiment, the customer information 720 may be obtained by a third party. In this embodiment, any information obtained from the customer, such as demographic information, contact information, etc., may be communicated to the third party. The third party may then map or compare the transmitted customer information 720 against its database and transmit anyAdditional customer information 720.

Research data set 750 may include a research data set based on statistical methods associated with merchant information 710 and customer information 720. Regression coefficients may then be set based on statistical methods to determine the study data set 750 and logistic regression method. Also, the regression coefficients 750 may be set at a certain time, but when the merchant information 710 and the customer information 720 are updated, modified, or changed, the research data set 750 and the regression coefficients 760 may be modified accordingly.

The front end 765 represents the front end use of DSA models associated with a particular potential customer. Using the determined regression coefficients 750, the DSA model may determine the scores 770 of the customer/merchant combinations for each merchant within the group. The customer 775 may then be presented with the highest scoring merchant 775 on the front end 765. And, information related to the regression coefficients 760 may then be communicated on the feedback loop 780 to update and/or modify the observed performance 730 of the merchant.

FIG. 8 illustrates an exemplary embodiment for determining driving time distances for merchants within a network. The merchant may provide the network provider with the address 820. Using the online geocoding API service 810, a geocode address 820 of a merchant may be determined. The geocoded address 820 of the merchant, including the latitude of the merchant, may then be stored in the database 830. Also, database 830 may contain merchants within network geocoded addresses. The database may contain a zip code centroid 840 associated with the zip code surrounding the merchant. Using the online direction API service 850 and the zip code center centroid 840, driving directions from the zip code centroid 840 from the geocoded address of the merchant stored in the database 830 may be determined. Also, the number of driving directions from the geocoded address of the merchant to the unique zip code centroid may be based on empirical evidence relating to the geographic location of the merchant. For example, in one embodiment, the driving direction 860 from the merchant may be determined for 6-10 zip code centroids. Using driving direction 860, a driving distance between zip code centroid/merchant pair 870 may be determined. In other embodiments, the process may be repeated each time a new merchant is added to the network.

Figure 9 illustrates another example of how a customer may interact with an embodiment disclosed herein that implements DSA through a user interface on a client device. Web page 900 may contain a table 910 relating to customer information that may be entered or completed by the user, target prices to the nearest merchant TrueCar certifier to potential customers, and specific decoration of vehicles in the geographic area.

Although the present invention has been described with respect to specific embodiments, these embodiments are merely illustrative, and not restrictive of, the present invention. The description herein of illustrated embodiments of the invention, including what is described in the abstract and the summary, is not exhaustive or intended to limit the invention to the precise forms disclosed herein (and in particular, the inclusion of any particular embodiment, feature, or function in the abstract or the summary is not intended to limit the scope of the invention to such embodiment, feature, or function). Rather, the embodiments, features and functions illustrated are described in order to enable those skilled in the art to understand the invention without limiting the invention to any specifically described embodiments, features or functions, including any such embodiments, features or functions described in the abstract or summary. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the present invention, as those skilled in the relevant art will recognize. As indicated, these modifications may be made to the present invention in light of the foregoing description of illustrated embodiments of the present invention and are to be included within the spirit and scope of the present invention. Thus, while the invention has been described herein with reference to specific embodiments, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the present invention.

Reference throughout this specification to "one embodiment," "an embodiment," or "a particular embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment and may not be present in all embodiments. Thus, appearances of the phrases "in one embodiment," "in an embodiment," or "in a particular embodiment" or similar language in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics of any specific embodiment may be combined in any suitable manner with one or more other embodiments. It is to be understood that other variations and modifications of the embodiments described and illustrated herein are possible in light of the teachings herein and are to be considered as part of the spirit and scope of the present invention.

In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that an embodiment may be practiced without one or more of the specific details, or with other apparatus, systems, assemblies, methods, components, materials, and/or parts, etc. In other instances, well-known structures, components, systems, materials, or acts have not been shown or described in detail to avoid obscuring aspects of embodiments of the invention. While the invention has been shown by using specific embodiments, it is not intended to limit the invention to any specific embodiment, and those skilled in the art will appreciate that additional embodiments are readily apparent and are a part of the present invention.

The embodiments discussed herein may be implemented in a computer communicatively coupled to a network (e.g., the internet), another computer, or a stand-alone computer. One skilled in the art will appreciate that a suitable computer may include a central processing unit ("CPU"), at least one read only memory ("ROM"), at least one random access memory ("RAM"), at least one hard drive ("ROM"), and one or more input/output ("I/O") devices. The I/O devices may include keyboards, monitors, printers, electronic pointing devices (e.g., mice, trackballs, styluses, touch pads, etc.), and the like.

ROM, RAM and HD are computer memories for storing computer-executable instructions that are executable by the CPU or that can be compiled or interpreted for execution by the CPU. Suitable computer-executable instructions may reside on computer-readable media (e.g., ROM, RAM, and/or HD), hardware circuitry, and the like, or any combination thereof. Within this disclosure, the term "computer-readable medium" is not limited to ROM, RAM, and HD, and may include any type of data storage medium that is readable by a processor. For example, computer-readable media may refer to a data cartridge, a data backup tape, a floppy disk, a flash memory drive, an optical data storage drive, a CD-ROM, a RAM, or a HD, among others. The processes described herein may be implemented in suitable computer executable instructions that may reside on a computer readable medium (e.g., disk, CD-ROM, memory, etc.). Alternatively, the computer executable instructions may be stored as software code components on a direct access storage device array, magnetic tape, floppy disk, optical storage device, or other suitable computer readable medium or storage device.

Any suitable programming language may be used to implement the routines, methods or programs of the embodiments of the invention described herein, including C, C + +, Java, JavaScript, HTML, or any other programming or scripting code, or the like. Other software/hardware/network architectures may be used. For example, the functionality of the disclosed embodiments may be implemented on one computer or shared/distributed between two or more computers in or across a network. Communication between computers implementing embodiments may be accomplished using any electrical, optical, radio frequency signals, or other suitable communication methods and tools conforming to known network protocols.

Different programming techniques may be used, such as procedural or object oriented. Any particular routine may be executed on a single computer processing device or multiple computer processing devices, a single computer processor, or multiple computer processors. Data may be stored in a single storage medium or distributed across multiple storage media, and may reside in a single database or multiple databases (or through other data storage techniques). Although the steps, acts, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent that multiple steps are presented in succession in the specification, some combinations of steps in alternative embodiments may be executed concurrently. The order of acts described herein may be suspended, or otherwise controlled by another process, such as the operating system, kernel, or the like. The routines can act within an operating system environment or as stand-alone routines. The functions, routines, methods, steps and actions described herein may be performed in hardware, software, firmware, or any combination thereof.

The embodiments described herein may be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium, such as a computer readable medium, as a plurality of instructions adapted to direct an information processing apparatus to perform a set of steps disclosed in various embodiments. Based on the disclosure and techniques provided herein, one of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.

It is also within the spirit and scope of the present invention that the steps, acts, methods, routines, or parts thereof described herein be implemented by software programming or code that may be stored in a computer readable medium and that may be operated by a processor to allow a computer to perform any of the steps, acts, methods, routines, or parts thereof described herein. The invention may also be implemented using software programming or code in one or more general purpose digital computers, using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms. Generally, the functionality of the present invention can be achieved by any means known in the art. For example, distributed or networked systems, components, and circuits may be used. In another example, the communication or transfer of data (or otherwise moving from one location to another) may be wired, wireless, or by any other means.

A "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, system or device. By way of example, and not limitation, a computer readable medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, system, device, propagation medium, or computer storage. Such computer-readable media should generally be machine-readable and contain software programming or code (e.g., source code) that may be human-readable or machine-readable (e.g., object code). Examples of non-transitory computer readable media may include random access memory, read only memory, hard drives, data cartridges, magnetic tape, floppy disks, flash memory drives, optical data storage devices, compact disk read only memory, and other suitable computer memory and data storage devices. In an illustrative embodiment, some or all of the software components may reside on a single server computer or any combination of separate server computers. Those skilled in the art will appreciate that a computer program product that implements embodiments disclosed herein may include one or more non-transitory computer-readable media storing computer instructions that are interpretable by one or more processors in a computing environment.

It will also be appreciated that one or more of the elements shown in the drawings/figures can also be implemented, useful in particular applications, in a more separated or integrated manner, or even removed or rendered inoperable in certain cases. Additionally, any signal arrows in the drawings/figures should be considered only as exemplary, and not limiting, unless otherwise specifically noted.

As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, article, or apparatus that comprises a list of elements is not necessarily limited only to those elements but may include other elements not expressly listed or inherent to such process, article, or apparatus.

Also, as used herein, the term "or" is generally intended to mean "and/or" unless indicated otherwise. For example, any one of the following aspects satisfies condition a or B: a is true (or present) and B is false (or not present), a is false (or not present) and B is true (or present); and both A and B are true (or present). As used herein, the following claims are inclusive, and the terms "a" or "an" (and, where the preceding basis is "a" or "an," the "are inclusive) include the singular and the plural of such terms (i.e.," a "or" an "expressly indicates only the singular or only the plural), unless expressly stated otherwise within a claim. Also, as used in the description herein and throughout the claims that follow, the meaning of "in" includes "in" or "on" unless the context clearly dictates otherwise. The scope of the present disclosure should be determined by the following claims and their legal equivalents.

Claims (20)

1. A system, comprising:

a server computer; and

at least one non-transitory computer-readable medium storing instructions that are translatable by the server computer to perform processes comprising:

for each vendor in a set of vendors:

assuming that the vendor is present in the set of vendors, a probability (P) is determined that the vendor sells the product to a user interested in purchasing the product_s）；

Given the user's historical preferences, a determination is made of the probability (P) that the user will purchase products from the vendor_b) (ii) a And

determining a probability (P) of reaching a sale_c) Here, P_cIs P_sAnd P_bA function of (a);

based on P associated therewith_cSelecting one or more vendors from the set of vendors; and

the one or more vendors are presented to a user interested in purchasing products through a user interface on a user device associated with the user, the user device communicatively coupled to the server computer through a network connection.

2. The system of claim 1, wherein P_sIncluding a first component expressing features associated with the vendor and a second component expressing features with respect to other vendors in the set of vendors.

3. The system of claim 2, wherein the characteristics include historical sales performance levels of the vendor.

4. The system of claim 1, wherein P_bA first component is included that expresses features associated with the user and a second component that expresses interactions between the user and the vendor.

5. The system of claim 4, wherein the first component comprises a socio-economic status of the user.

6. The system of claim 4, wherein the second component is associated with a drive time between the user and the vendor.

7. The system of claim 1, wherein each vendor in the set is within a distance to the user that is less than a threshold or within a geographic boundary.

8. The system of claim 1, wherein selecting one or more vendors from the set is based at least in part on an expected revenue of each vendor in a particular area.

9. A method, comprising:

for each vendor in a set of vendors:

assuming that the vendor is present in the set of vendors, a probability (P) is determined that the vendor sells the product to a user interested in purchasing the product_s）；

Given a user's historical preferences, a determination is made of the probability (P) that the user will purchase a product from a vendor_b) (ii) a And

determining a probability (P) of reaching a sale_c) Here, P_cIs P_sAnd P_bA function of (a);

based on P associated therewith_cSelecting one or more vendors from the set of vendors, wherein the selecting is performed by a computer; and

the one or more vendors are presented to a user interested in purchasing products through a user interface on a user device associated with the user, the user device communicatively coupled to the computer through a network connection.

10. The method of claim 9, wherein P_sIncluding a first component expressing features associated with the vendor and a second component expressing features with respect to other vendors in the set of vendors.

11. The method of claim 10, wherein the characteristics include historical sales performance levels of the vendor.

12. The method of claim 9, wherein P_bA first component is included that expresses features associated with the user and a second component that expresses interactions between the user and the vendor.

13. The method of claim 12, wherein the first component comprises a socio-economic status of the user.

14. The method of claim 12, wherein the second component is associated with a drive time between the user and the vendor.

15. The method of claim 9, wherein each vendor in the group is within a distance to the user that is less than a threshold or within a geographic boundary.

16. The method of claim 9, wherein selecting one or more vendors from the set is based at least in part on an expected revenue for each vendor in a particular area.

17. A computer program product comprising at least one non-transitory computer readable medium storing instructions that are computer-interpretable to perform a process comprising:

for each vendor in a set of vendors:

assuming that the vendor is present in the set of vendors, a probability (P) is determined that the vendor sells the product to a user interested in purchasing the product_s）；

Given the user's historical preferences, a determination is made of the probability (P) that the user will purchase products from the vendor_b) (ii) a And

determining a probability (P) of reaching a sale_c) Here, P_cIs P_sAnd P_bA function of (a);

based on P associated therewith_cSelecting one or more vendors from the set of vendors; and

the one or more vendors are presented to a user interested in purchasing products through a user interface on a user device associated with the user, the user device communicatively coupled to the computer through a network connection.

18. The computer program product of claim 18, wherein selecting the one or more vendors from the set is based at least in part on an expected revenue for each vendor in a particular area.

19. The computer program product of claim 18, wherein P_sIncluding a first component expressing features associated with the vendor and a second component expressing features with respect to other vendors in the set of vendors.

20. The computer program product of claim 18, wherein P_bA first component is included that expresses features associated with the user and a second component that expresses interactions between the user and the vendor.