U.S. patent application number 13/423098 was filed with the patent office on 2012-09-20 for deal scoring system and method.
Invention is credited to Samy Aboel-Nil, Dane Knecht, Martin Tobias.
Application Number | 20120239484 13/423098 |
Document ID | / |
Family ID | 46829219 |
Filed Date | 2012-09-20 |
United States Patent
Application |
20120239484 |
Kind Code |
A1 |
Tobias; Martin ; et
al. |
September 20, 2012 |
DEAL SCORING SYSTEM AND METHOD
Abstract
Prospective deals for a deal vendor's deal inventory may be
scored according to one or more population-specific expected-yield
scores, such as expected revenue yield, expected new customers
yield, and the like. A prospective deal is categorized and
characterized according to a number of yield-related
characteristics. Some or all of the prospective deal's
characteristics are mapped to yield components derived from
completed deals that have been offered to a particular population.
An expected-yield score for a prospective deal with regard to that
population is obtained by combining the mapped yield
components.
Inventors: |
Tobias; Martin; (Seattle,
WA) ; Knecht; Dane; (Austin, TX) ; Aboel-Nil;
Samy; (Austin, TX) |
Family ID: |
46829219 |
Appl. No.: |
13/423098 |
Filed: |
March 16, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61453855 |
Mar 17, 2011 |
|
|
|
Current U.S.
Class: |
705/14.35 |
Current CPC
Class: |
G06Q 30/0201 20130101;
G06Q 50/01 20130101; G06Q 30/0267 20130101; G06Q 30/0277 20130101;
G06Q 30/0239 20130101; G06Q 30/0235 20130101; G06Q 30/0251
20130101 |
Class at
Publication: |
705/14.35 |
International
Class: |
G06Q 30/02 20120101
G06Q030/02 |
Claims
1. A deal scoring system and method as shown and described.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of priority to U.S.
Provisional Application No. 61/453,855, filed Mar. 17, 2011, titled
"DEAL SCORING SYSTEM AND METHOD," filed under Attorney Docket No.
KASH-2011018, and naming inventors Martin Tobias, Dane Knech, and
Samy Aboel-Nil. The above-cited application(s) are incorporated
herein by reference in their entireties, for all purposes.
FIELD
[0002] The present disclosure relates to e-commerce, and more
particularly to automatically scoring "deals," such as for
"deal-of-the-day" websites.
BACKGROUND
[0003] Many web sites offer some sort of periodic (e.g., daily)
deal. Some retailers, such as Amazon.com and Buy.com, feature a
"deal of the day" item in addition to using conventional sales
methods. Other web sites operated by deal vendors, such as
Tippr.com, Groupon.com, and the like, partially or exclusively sell
"deal" vouchers that are good for discounts on specified goods
offered by other retailers or merchants. For example, a deal vendor
might offer a "deal" voucher that can be purchased for one price
(e.g. $25) and that can be redeemed at a particular merchant for
goods and/or services having a higher value (e.g. $50) than the
purchase price of the deal voucher. Such deal vendors typically
earn revenue by retaining a portion of the purchase price of the
deal voucher (e.g., when a consumer purchases a $25 deal voucher,
the deal vendor may keep $12.50 and pay $12.50 to the merchant at
which the voucher can be redeemed). Many such deals are offered
only for a limited period of time and/or only in limited
quantity.
[0004] Some deal-offering services (e.g., Google Offers, provided
by Google Inc. of Mountain View, Calif.) may refer to such "deals"
as "offers," "special offers," or the like. The term "deal" is used
herein to refer to any such deal, discount offer, discount voucher,
limited-time offer, limited-quantity offer, or the like.
[0005] Consumers often sign up for a deal vendor's mailing list to
receive periodic deal offers from a deal vendor, e.g. via a daily
email or other communication medium. Although a given deal vendor's
mailing list may include consumers from many cities, states, and/or
countries, many deal vendors segment their consumer lists into
regional populations. For example, many deal vendors segment their
consumer lists into populations segregated by city, zip code, or
even neighborhood. Some or all of these populations may be offered
deals targeted to the population's particular locale (e.g. deals
that can be redeemed at a local and/or nearby merchant).
[0006] Such periodic deal services (e.g., deal-of-the-day services)
have been popular with many merchants. Consequently, many deal
vendors may have an inventory of multiple potential deals that the
vendor could select for targeting to a given population for a given
offer period. A good-performing deal may generate many times more
revenue than a bad-performing deal, so many deal vendors may desire
to select good-performing deals to offer. However, at the present
time, deal vendors typically lack tools (automated or otherwise)
for selecting which of a given set of potential deals will maximize
revenue (or some other yield metric) for a given population for a
given offer period. Rather, many deal vendors rely on human
editorial staff to select deals for various populations for a given
offer period.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a network diagram in accordance with one
embodiment.
[0008] FIG. 2 illustrates one embodiment of a deal vendor server in
accordance with one embodiment.
[0009] FIG. 3 illustrates a simplified conceptual overview of
past-deal data associated with different populations, in accordance
with one embodiment.
[0010] FIG. 4 illustrates several exemplary revenue-yield curves
for an exemplary population, in accordance with one embodiment.
[0011] FIG. 5 illustrates a routine for processing historical deal
data, in accordance with one embodiment.
[0012] FIG. 6 illustrates a prospective-deal scoring routine, in
accordance with one embodiment.
[0013] FIG. 7 illustrates a scoring subroutine for scoring a
prospective deal according to one or more expected yields for a
given target population, in accordance with one embodiment.
DESCRIPTION
[0014] Various embodiments, as described below, are directed
generally to answering the question of which deal should be offered
to a particular population for a given offer period to maximize the
purchases and/or margin for a limited inventory window. Some
embodiments may select deals to maximize relevancy to a target
population, while also maximizing margin and/or revenue for the
deal vendor and/or the deal-offering merchant. As discussed further
below, such embodiments may deal with various constraints that are
specific to deal-vending services, such as limited offer periods,
limited deal quantities, target audience demographics and past deal
behavior, deal-vendor margins, and the like.
[0015] In various embodiments, as described below, one or more
potential deals may be evaluated and ranked according to several
predictive yield metrics to optimize deal selection against a
specific target population. Deal vendors may desire to evaluate
potential deals in such a manner because a good-performing deal may
generate many times more revenue than a bad-performing deal.
Moreover, "good" deals may please a deal vendor's customers,
causing them to share the vendor's deals with others and become
loyal, repeat customers of future deals offered by the deal
vendor.
[0016] In various embodiments, several deal characteristics may be
evaluated against past deal-purchasing data for a target population
to rank potential deals, potentially identifying deals that will be
popular with consumers in the target population.
[0017] The detailed description that follows is represented largely
in terms of processes and symbolic representations of operations by
conventional computer components, including a processor, memory
storage devices for the processor, connected display devices, and
input devices. Furthermore, these processes and operations may
utilize conventional computer components in a heterogeneous
distributed computing environment, including remote file Servers,
computer Servers, and memory storage devices. Each of these
conventional distributed computing components is accessible by the
processor via a communication network.
[0018] The phrases "in one embodiment," "in various embodiments,"
"in some embodiments," and the like are used repeatedly. Such
phrases do not necessarily refer to the same embodiment. The terms
"comprising," "having," and "including" are synonymous, unless the
context dictates otherwise.
[0019] Reference is now made in detail to the description of the
embodiments as illustrated in the drawings. While embodiments are
described in connection with the drawings and related descriptions,
there is no intent to limit the scope to the embodiments disclosed
herein. On the contrary, the intent is to cover all alternatives,
modifications, and equivalents. In alternate embodiments,
additional devices, or combinations of illustrated devices, may be
added to, or combined, without limiting the scope to the
embodiments disclosed herein.
[0020] FIG. 1 illustrates a number of interconnected devices in
accordance with one embodiment. Deal database 120, merchant 115,
consumer devices 105A-D, third party data source 110, and deal
vendor server 200 are connected to network 150. In various
embodiments, network 150 comprises communication switching,
routing, and/or data storage capabilities. In various embodiments,
network 150 may comprise some or all of the Internet, one or more
intranets, and wired and/or wireless network portions. In various
embodiments, there may be more than one deal database 120, merchant
115, and/or third party data source 110. Moreover, while FIG. 1
shows a single deal vendor server 200, in alternative embodiments,
the functions, processes, and routines performed by deal vendor
server 200 could be hosted or distributed among two or more
different devices. Many embodiments may use multiple devices to
comprise one logical device--for example, when deal vendor server
200 and/or deal database 120 are executed or hosted in a "cloud
computing" environment.
[0021] Alternatively, in some embodiments, deal vendor server 200
and deal database 120 may be hosted on a single physical computing
device. For example, in some embodiments, deal database 120 may
include a process executing on deal vendor server 200.
[0022] In various embodiments, merchant 115, consumer devices
105A-D, and/or third party data source 110 may include any device
that is capable of communicating with deal vendor server 200,
including desktop computers, laptop computers, mobile phones and
other mobile devices, PDAs, set-top boxes, and the like.
[0023] FIG. 2 illustrates an exemplary deal vendor server 200. The
example system of FIG. 2 depicts a number of subsystems, modules,
routines, and engines, some or all of which may by employed in a
particular embodiment; the systems, modules, routines, and engines
are not, however, limited to those illustrated. Other embodiments
could be practiced in any number of logical software and physical
hardware components and modules. The modules and components are
listed herein merely for example.
[0024] Deal vendor server 200 includes a processing unit 210, a
memory 225, and an optional display 240, all interconnected, along
with network interface 230, via bus 220. Memory 250 generally
comprises a random access memory ("RAM"), a read only memory
("ROM"), and/or a permanent mass storage device, such as a disk
drive. In some embodiments, memory 250 may also comprise a local
and/or remote database, database server, and/or database service,
such as deal database 120. In other embodiments, network interface
230 and/or other database interface (not shown) may be used to
communicate with deal database 120. Memory 250 stores program code
for a deal rank routine 600 (see FIG. 6, discussed below). In
addition, memory 250 stores an operating system 255.
[0025] These and other software components may be loaded from a
non-transient computer readable storage medium 295 into memory 250
of deal vendor server 200 using a drive mechanism (not shown)
associated with a computer readable storage medium 295, such as a
floppy disc, tape, DVD/CD-ROM drive, memory card. In some
embodiments, software components may also be loaded via the network
interface 230 or other transient, non-storage media.
[0026] FIG. 3 illustrates a simplified conceptual overview of
past-deal data associated with different populations, in accordance
with one embodiment. Populations 305 and 306 represent two
different sub-segments of a deal vendor's consumer list. For
example, in one embodiment, population 305 may include a plurality
of consumers in a particular city, zip code, or neighborhood, and
population 306 may include a plurality of consumers in a different
city, zip code, or neighborhood. In other embodiments, populations
305 and 306 may each include a plurality of customers segmented
according to one or more demographic factors (e.g., age, sex,
income, and the like).
[0027] Past deals 310A and 311-312 represent a subset of deals that
have been previously offered to population 305. Similarly, past
deals 310B and 313-314 represent a subset of deals that have been
previously offered to population 306. In some embodiments, past
deals 310-314 may be represented as records in deal database 120.
In the illustrated example, past deal 310 was offered at some point
to both of populations 305 and 306. In many embodiments, one or
both of populations 305 and 306 may have been previously offered
many more deals than those illustrated in FIG. 3. However, it is
not necessary to show all past deals in order to disclose an
illustrative embodiment.
[0028] Each of past deals 310A-B and 311-314 (as well as other past
deals, not shown) is associated with metadata related to various
characteristics of the deal and various past-performance yield
metrics, metadata that is also stored in deal database 120.
[0029] For example, in the illustrated embodiment, past deal 310
(310A and 310B) is associated with (population-neutral) deal
characteristics 320 (discussed in more detail below), including a
category characteristic 321, a price characteristic 322, a discount
characteristic 323, a brand strength characteristic 324, a
limitations/exclusions characteristic 325, and one or more
third-party characteristics 326. In other embodiments, metadata
associated with more, fewer, and/or different characteristics may
be similarly stored.
[0030] In one embodiment, a deal may be associated with a category
characteristic 321, which classifies the goods and/or services for
which the deal may be redeemed. For example, in one embodiment, a
deal may be classified into categories such as the following:
[0031] dining and nightlife; [0032] health and beauty; [0033]
fitness and nutrition; [0034] retail and services; [0035]
activities and adventures; [0036] travel; [0037] and the like.
[0038] Furthermore, in some embodiments, deals may be
sub-classified into sub-categories, sub-sub-categories, and so on
(not shown). For example, in one embodiment, a "dining and
nightlife" category may include several sub-categories, such as
restaurants, bars, coffee, bakeries, nightclubs, and the like. For
example, a deal that can be redeemed for $50 worth of food at
"Joe's Diner" may be classified in the "dining and nightlife"
category and the "restaurants" sub-category.
[0039] In one embodiment, a deal may be associated with a price
characteristic 322, which refers to the purchase price of the deal
itself (as opposed to the value of goods/services for which the
deal can be redeemed). For example, a deal that can be purchased
for $25 may have a price characteristic of $25. Price
characteristic 322 is thus an objective measure.
[0040] In one embodiment, a deal may be associated with a discount
characteristic 323, which refers to the price of the deal (322)
compared to the value of goods/services for which the deal can be
redeemed. For example, a deal that can be purchased for $25 and
redeemed for $50 worth of food may have a "50%" discount
characteristic. Discount characteristic 323 is thus an objective
measure.
[0041] In one embodiment, a deal may be associated with a brand
strength characteristic 324, which refers to the amount of goodwill
associated with the brand name of the goods/services for which the
deal can be redeemed. For example, a first merchant that has
operated for years under a given brand name, with many favorable
reviews, and is well-known as a source of high-quality
goods/services may have more goodwill associated with its brand
than a second merchant that is newly opened, recently changed its
name, and/or is known as a source of low-quality goods/services.
Thus, a deal redeemable at the first merchant may have a better
brand strength characteristic 324 than a deal redeemable at the
second merchant. In some embodiments, brand strength characteristic
324 may be a subjective measure assigned by an editor. In other
embodiments, brand strength characteristic 324 may be an objective
measure derived from automatically-determinable data, such as
quantities of positive reviews for the merchant on social
networking and/or review web sites, quantities of mentions in
publicly accessible media, and the like.
[0042] In one embodiment, a deal may be associated with one or more
limitations/exclusions characteristics 325, which refer to the
quantity and/or quality of restrictions and/or limitations that are
placed on the purchase and/or redemption of a deal. Examples of
such limitations and/or exclusions may include characteristics such
as some or all of the following: [0043] limitations on how many
times a consumer is allowed to purchase a deal (e.g., limit one
deal per person vs. limit ten deals per person); [0044] limitations
on goods/services for which the deal can be redeemed (e.g., the
deal cannot be redeemed for alcoholic beverages or the deal good
only for some, but not all, of a merchant's services); [0045]
limitations on when the deal can be redeemed (e.g., deal can be
redeemed only Sunday-Thursday); [0046] and the like.
[0047] In one embodiment, a deal may be associated with one or more
third-party characteristics 326, which may refer to any number of
metrics maintained by and/or accessible from an entity other than
the deal vendor. Examples of such third-party characteristics 326
may include characteristics such as some or all of the following:
[0048] quantity and/or frequency of "check-ins" at the merchant's
location(s) on a location-based social network service; [0049]
merchant reviews, scores, and/or "star-ratings" on consumer-review
services, local search services, or the like; [0050] quantity of
"likes" associated with the merchant, quantity of "fans" associated
with the merchant, quantity of group members associated with the
merchant, and/or other similar measures of approval or approbation
on one or more social network services; [0051] and the like.
[0052] In addition, each of past deals 310A-B and 311-314 (as well
as other past deals, not shown) is associated with metadata related
to various population-specific characteristics of the deal. For
example, in the illustrated embodiment, past deal 310A is
associated with population-specific deal characteristics 330A
related to population 305, including a locations/distance
characteristic 331A, a market size characteristic 332A, promotion
type characteristic(s) 334A, and one or more third-party
characteristics 323A. Past deal 310B is associated with
population-specific deal characteristics 330B related to population
306, including a locations/distance characteristic 331B, a market
size characteristic 332B, promotion type characteristic(s) 334B,
and one or more third-party characteristics 323B. In other
embodiments, metadata associated with more, fewer, and/or different
population-specific characteristics may be similarly stored. In
some embodiments, some such characteristics (e.g., market size 332)
may be considered to be population-neutral characteristics.
[0053] In one embodiment, a deal may be associated with one or more
location/distance characteristics 331, which refer to the relative
geo-locations of consumers in the relevant population and the
geo-location or locations of the merchant at which the deal can be
redeemed, also referred to as fulfillment locations. Examples of
such location/distance characteristics 331 may include
characteristics such as some or all of the following: [0054]
quantity of fulfillment locations (e.g., an independent spa may
have only one location at which the deal can be redeemed, whereas a
spa that is part of a large chain may have multiple fulfillment
locations); [0055] distance from the target population to
fulfillment location(s) (e.g., how far will a consumer in the
target population likely have to travel to redeem the deal); [0056]
and the like.
[0057] Some deals may be redeemable for services that are unrelated
to any particular geo-location. For example, a deal that can be
fulfilled on-line may require consumers in the target population to
travel zero distance to redeem the deal. For another example, a
deal for on-site auto-detailing (i.e., the merchant travels to the
consumer) may similarly require consumers in the target population
to travel zero distance to redeem the deal.
[0058] In one embodiment, a deal may be associated with a market
size characteristic 332, which refers to the size of the
addressable market within the target population. For example, deals
that are redeemable for food may address a market consisting of
essentially all of the target population (as virtually all
consumers consume food). By contrast, a deal that is redeemable for
a facial or a bikini wax may address a market consisting of a
relatively large fraction of the target population (e.g., 50-60%,
as fewer than all consumers typically consume such services). Deals
for specialized goods/services (e.g., music DJ lessons) may address
only a small fraction of the target population.
[0059] In one embodiment, a deal may be associated with one or more
promotion type characteristic(s) 334, which refer to channels by
which the deal was promoted to the target population. Examples of
such promotion type characteristic(s) 334 may include promotion
types such as some or all of the following: [0060] email promotion;
[0061] social network promotion; [0062] micro-blogging promotion;
[0063] text message promotion; [0064] television promotion; [0065]
radio promotion; [0066] and the like.
[0067] In one embodiment, a deal may be associated with a one or
more third-party population-specific characteristics 323. Examples
of such third-party population-specific characteristics 323 may
include characteristics such as some or all of the following:
[0068] quantity and/or frequency of blog, micro-blog, status
updates or other like posts about the particular deal; [0069]
quantity of "likes" associated with the particular deal, quantity
of "fans" associated with the particular deal, quantity of group
members associated with the particular deal, and/or other similar
measures of approval or approbation on one or more social network
services; [0070] and the like.
[0071] Each of past deals 310A-B and 311-314 (as well as other past
deals, not shown) is also associated with metadata related to
various past-performance yield metrics, such as some or all of the
following: [0072] revenue yield 341 (e.g., how much revenue did a
given deal generate when offered to a given population); [0073]
return customers yield 342 (e.g., in a given population, how many
consumers who purchased a given deal also purchased a later-offered
deal); [0074] referrals yield 343 (e.g., when offered to a given
population, how many referrals did a given deal generate); [0075]
new subscribers yield 344 (e.g., how many new consumers signed up
with the deal vendor when a given deal was offered to a given
population); [0076] and the like.
[0077] In other embodiments, metadata associated with more, fewer,
and/or different yield metrics may be similarly stored.
[0078] Using deal characteristics 331-334 and 321-326 and
past-performance yield metrics 341-344, various expected-yield
curves may be determined for all of part of a population. As the
term is used herein, "expected-yield curve" or "yield curve" refers
to a data structure and/or program code that maps an input value to
an output value according to a pre-determined scheme.
[0079] For example, FIG. 4 illustrates several exemplary yield
curves 441A-F for population 305, which graphically illustrate
relationships between the average revenue yields for a group of
some or all of past deals (e.g., 310A, 311, 312, . . . ) that have
been offered to population 305, in accordance with one
embodiment.
[0080] Revenue/distance yield curve 405A shows that in population
305, average deal-revenue yields 441A vary according to a
location/distance yield component 431. More specifically, average
deal-revenue yields 441A are generally higher for deals in which
fulfillment locations are more numerous and/or are geographically
closer to population 305, and are generally lower for deals in
which fulfillment locations are less numerous and/or are
geographically distant from population 305. Thus, deals having a
location/distance characteristic value 405 may have historically
had an average deal yield value 410 in population 305.
[0081] Similarly, revenue/market size yield curve 405B shows that
in population 305, average deal-revenue yields 441B generally vary
directly according to the size of an addressable market yield
component 432 within population 305. Revenue/limitations yield
curve 405C shows that in population 305, average deal-revenue
yields 441C generally decline as a deal limitation and/or exclusion
yield component 425 increases.
[0082] Revenue/price yield curve 405D shows that in population 305,
average deal-revenue yields 441D are highest for deals that are
priced in the middle of a range of a price yield component 422. For
example, members of population 305 may find that, other deal
characteristics being equal, very low-priced deals are less likely
to be worth the hassle of purchasing and redeeming the deal,
whereas very high-priced deals may entice fewer consumers to
purchase the deal.
[0083] Revenue/discount yield curve 405E shows that in population
305, average deal-revenue yields 441E are higher for deals in which
a discount yield component 423 represents a higher discount level
(e.g., 75%) than for deals in which discount yield component 423
represents a lower discount level (e.g., 25%). In populations that
are more discount-sensitive, the revenue/discount yield curve 405E
may be steeper, whereas in populations that are less
discount-sensitive, the revenue/brand strength yield curve 405E may
be shallower.
[0084] Revenue/brand strength yield curve 405F shows that in
population 305, average deal-revenue yields 441F generally vary
directly according to a brand strength yield component 424 of the
merchant. In populations that are more brand-sensitive, the
revenue/brand strength yield curve 405F may be steeper, whereas in
populations that are less brand-sensitive, the revenue/brand
strength yield curve 405F may be shallower.
[0085] Yield curves 405A-E represent only an exemplary set of yield
components and yield curves that may be determined for a set of
deals that have been offered to a given population. In other
embodiments, any of deal characteristics 331-333 and 321-326, or
other deal characteristics, may be treated as yield components for
a given set of deals and compared for a given population against
any of deal-yields 341-344, or other deal yields. Thus, some
embodiments may determine for a given population, for example,
yield curves such as some or all of the following: [0086]
return-customer/location; [0087] return-customer/market-size;
[0088] return-customer/price; [0089] return-customer/discount;
[0090] return-customer/third-party-characteristic (e.g., return
customers according to quantity of social network "likes" of the
merchant, according to a star rating of the merchant on a
consumer-reviews service, and the like); [0091]
new-subscriber/location; [0092] new-subscriber/market-size; [0093]
new-subscriber/price; [0094] new-subscriber/discount; [0095]
return-customer/third-party-characteristic; [0096] and the
like.
[0097] Moreover, in some embodiments, a set of yield curves may be
further broken down by category. Thus, other embodiments may
determine, for example, a first new-subscriber/price yield curve
for deals in category "X" that have been offered to a given
population, a second new-subscriber/price yield curve for deals in
category "Y" that have been offered to the given population, and a
third new-subscriber/price yield curve for deals in category "Z"
that have been offered to a given population.
[0098] In various embodiments, as discussed below, deal-yield
curves such as those discussed above may be used to determine a one
or more population-specific expected-yield scores for a given
prospective deal.
[0099] FIG. 5 illustrates a routine 500 for processing historical
deal data, in accordance with one embodiment. In various
embodiments, routine 500 may be performed by deal vendor server 200
to add deal data to deal database 120, from which the deal data may
be further processed by routine 600 (see FIG. 6, discussed
below).
[0100] In block 505, routine 500 obtains data related to one or
more completed deal offerings. For example, in one embodiment,
routine 500 may obtain data from a corpus of one or more completed
deals that were previously offered to one or more target
populations.
[0101] Beginning in starting loop block 510, routine 500 processes
each completed deal. In block 515, routine 500 determines one or
more deal characteristics for the current completed deal. For
example, in one embodiment, routine 500 may determine one or more
population-neutral deal characteristics such as a category
characteristic 321, a price characteristic 322, a discount
characteristic 323, a brand strength characteristic 324, a
limitations/exclusions characteristic 325, and/or one or more
third-party characteristics 326, as discussed above in reference to
FIG. 3. In some embodiments, some or all of the deal
characteristics may be (or have previously been) automatically
determined (e.g., price, discount, and the like). In other
embodiments, some of the deal characteristics may have been
determined through a partially automated or manual editorial
process, or may have been specified by the merchant offering the
deal (e.g., category, limitations/exclusions, and the like).
[0102] In block 520, routine 500 determines one or more target
populations to which the current completed deal was offered.
Beginning in opening loop block 525, routine 500 processes each of
the one or more target populations.
[0103] In block 530, routine 500 determines one or more
population-specific deal characteristics for the current completed
deal. For example, in one embodiment, routine 500 may determine one
or more population-specific deal characteristics such as
locations/distance characteristic 331, a market size characteristic
332, promotion type characteristic(s) 334, and one or more
third-party characteristics 323, as discussed above in reference to
FIG. 3.
[0104] In block 533, routine 500 determines one or more
population-specific yield metrics for the current completed deal.
For example, in one embodiment, routine 500 may determine one or
more population-specific yield metrics such as revenue yield 341,
return customers yield 342, referrals yield 343, new subscribers
yield 344, as discussed above in reference to FIG. 3.
[0105] In block 537, routine 500 associates the yield metrics
determined in block 533 and the deal characteristics determined in
blocks 515 and 530 with the current completed deal in a deal
database (e.g., deal database 120).
[0106] In ending loop block 540, routine 500 iterates back to block
525 to process the next target population (if any). In ending loop
block 545, routine 500 iterates back to block 510 to process the
next completed deal (if any). Having processed each completed deal,
routine 500 ends in block 599.
[0107] FIG. 6 illustrates a prospective-deal scoring routine 600,
such as may be performed by deal vendor server 200 in accordance
with one embodiment. In block 610, routine 600 obtains a
prospective deal. For example, in one embodiment, a merchant (e.g.,
merchant 115) may submit a form via a web or other interface, the
form specifying various aspects of a deal that the merchant wishes
to offer via a deal vendor service (such as that offered by deal
vendor server 200). In some embodiments, the prospective deal may
specify deal characteristics such as the goods and/or services for
which the deal can be redeemed; information about the merchant
offering the deal and/or fulfilling the deal; locations at which
the deal can be redeemed; time periods during which the deal can be
redeemed; the price at which a consumer can purchase the deal; the
value of the goods and/or services for which the deal can be
redeemed; populations to which the deal may be targeted; and other
like terms, conditions, and/or characteristics. In some
embodiments, the merchant may also select a category into which the
deal fits.
[0108] In block 615, routine 600 categorizes the prospective deal.
In some embodiments, the prospective deal may be automatically
categorized based on deal characteristics or other information
obtained in block 610. In other embodiments, routine 600 may
automatically determine a category based on a description of goods
and/or services for which the deal can be redeemed, or based on
information about the merchant at which the deal can be redeemed.
In still other embodiments, a partially automated editorial process
may be employed to categorize the prospective deal.
[0109] In block 620, routine 600 determines one or more
(population-neutral) deal characteristics for the prospective deal.
In some embodiments, some or all of such (population-neutral) deal
characteristics may have been obtained in block 610 or may be
automatically determinable from information obtained in block 610.
In other embodiments, routine 600 may determine at least some of
the (population-neutral) deal characteristics using a partially
automated editorial process. In still other embodiments, routine
600 may determine one or more (population-neutral) deal
characteristics using data obtained from a third-party data source
(e.g., data source 110). For example, in one embodiment, routine
600 may obtain information about the merchant offering the deal
and/or about the goods and/or services for which the deal can be
redeemed from third-party social networking services,
location-based services, bogging or micro-blogging services,
consumer-review services, web search services, or the like.
[0110] In block 625, routine 600 determines one or more target
populations to which the prospective deal may be offered. In some
embodiments, routine 600 may be performed by a deal vendor server
200 that offers deals targeted to more than one population. In such
embodiments, one or more target populations may have been specified
in information obtained in block 610. Alternatively, one or more
target populations may be automatically determined based on
information about merchant locations at which the deal can be
redeemed. For example, if the prospective deal can be redeemed at
several locations within the greater Seattle area, then one or more
target populations including consumers in the greater Seattle area
may be determined. Similarly, if the if the prospective deal can be
redeemed only at one location in the Queen Anne neighborhood of
Seattle, then one or more target populations including consumers in
the Queen Anne neighborhood and/or the 98119 and 98109 zip codes
may be determined.
[0111] Beginning in opening loop block 630, routine 600 processes
each of the one or more determined target populations. In block
635, routine 600 determines one or more population-specific deal
characteristics. For example, in one embodiment, routine 600 may
determine a size of the addressable market within the target
population (see market size characteristic 332, discussed above in
reference to FIG. 3). In some embodiments, routine 600 may instead
or in addition determine one or more promotion types for promoting
the prospective deal to the target population.
[0112] In subroutine block 700 (see FIG. 7, discussed below),
routine 600 scores the prospective deal according to one or more
expected yields for the current target population. For example, in
one embodiment, routine 600 may score the prospective deal
according to an expected revenue yield from the current target
population (e.g., if the prospective deal were offered to the
current target population, it would be expected to yield X dollars
in revenue to the deal vendor service and/or to the merchant). In
other embodiments, routine 600 may score the prospective deal
according to other population-specific yields, such as a new
subscriber yield (e.g., if the prospective deal were offered to the
current target population, it would be expected to yield X new
subscribers to the deal vendor service), a return customer yield
(e.g., if the prospective deal were offered to the current target
population, it would be expected to yield X return customers to the
deal vendor service), or the like.
[0113] In decision block 645, routine 600 determines whether to
accept the prospective deal. For example, in one embodiment,
routine 600 may compare one or more expected yield scores against
one or more thresholds to determine whether to accept the
prospective deal for potential offering to the current target
population. If routine 600 determines not to accept the prospective
deal, then in block 650, routine 600 indicates that the deal is
rejected. For example, in one embodiment, routine 600 may indicate
(e.g., via a web interface) to the requesting merchant that the
prospective deal does not meet one or more standard for deals
targeted to the current population. In some embodiments, routine
600 may further provide information about the expected yield(s)
that caused the prospective deal to be rejected, and/or routine 600
may further provide information about how to improve the expected
yield of the deal (e.g., remove limitations, lower the
price/increase the discount level, and the like).
[0114] On the other hand, if in block 645, routine 600 determines
to accept the prospective deal, then in block 655, routine 600 adds
the prospective deal to a deal inventory for the current
population. For example, in one embodiment, routine 600 may
associate the prospective deal with a target-population deal
inventory in deal database 120. In ending loop block 660, routine
600 iterates back to block 630 to process the next target
population (if any).
[0115] At some point after processing all of the target
populations, in block 665, routine 600 uses the expected-yield
scores determined in iterations of block 700 to select deals for
various target populations from various target-population deal
inventories. For example, in one embodiment, routine 600 may fill
an opening to offer a deal on a given day to a given target
population, selecting a deal that is expected to yield a high
return according to one or more population-specific yield metrics
(e.g., revenue, new subscribers, and the like).
[0116] Routine 600 ends in block 699.
[0117] FIG. 7 illustrates a scoring subroutine 700 for scoring a
prospective deal according to one or more expected-yield metrics
for a given target population, in accordance with one embodiment.
Beginning in opening loop block 705, subroutine 700 processes one
or more population-specific expected-yield metrics. For example, in
one embodiment, subroutine 700 may process one or more
population-specific expected-yield metrics such as an
expected-revenue yield, an expected-return-customers yield, an
expected-referrals yield, an expected-new-subscribers yield, and
the like.
[0118] In block 710, subroutine 700 initializes an expected-yield
score data structure for the current expected yield metric. In
block 715, subroutine 700 obtains one or more yield-component
characteristics. In some embodiments, the one or more
yield-component characteristics are selected from a group of deal
characteristics associated with the prospective deal and the target
population. The one or more yield components may in some
embodiments be selected from a group including deal characteristics
321-326 and population-specific deal characteristics 331-333 (as
discussed above in relation to FIG. 3). For example, in one
exemplary embodiment, an expected-revenue-yield score may be
determined from yield curves 405A-F, as illustrated in FIG. 4,
discussed above. In such an exemplary embodiment, the yield
components would include a locations/distance yield component 431,
a market size yield component 432, a limitations/exclusions yield
component 425, a price yield component 422, a discount yield
component 423, and a brand strength yield component 424.
[0119] Beginning in opening loop block 720, subroutine 700
processes each of the one or more yield components obtained in
block 715. In block 725, subroutine 700 obtains and/or determines
one or more completed-deal yield curves for the current yield
component. For example, in one exemplary embodiment, subroutine 700
may obtain one of yield curves 405A-F, as illustrated in FIG. 4,
discussed above.
[0120] In block 735, subroutine 700 determines the value of a deal
characteristic of the prospective deal that corresponds to the
current yield component. For example, in one exemplary embodiment,
if the current yield component were discount yield component 423,
then subroutine 700 would determine the value of the discount deal
characteristic 323 for the prospective deal. Similarly, if the
current yield component were market size yield component 432, then
subroutine 700 would determine the value of the market size deal
characteristic 332 for the prospective deal and the given target
population.
[0121] In block 740, subroutine 700 maps the value of the deal
characteristic obtained in block 735 to an expected yield according
to the current completed-deal yield curve. For example, if the
current yield component were locations/distance component 431, the
current completed-deal yield curve were yield curve 405A, and the
current deal characteristic (locations/distance deal characteristic
331) had value 405, then subroutine 700 would map deal
characteristic value 405 to expected yield 410.
[0122] In block 745, subroutine 700 adjusts the expected yield
obtained in block 745 according to a weighting factor that controls
how various yield components are combined. In some embodiments,
yield components may be weighted equally. For example, in an
exemplary embodiment, each of six yield components
(locations/distance yield component 431, market size yield
component 432, limitations/exclusions yield component 425, price
yield component 422, a discount yield component 423, and brand
strength yield component 424) may be assigned a weighting factor of
1/6, such that the sum of each of the six expected yield components
would represent an overall expected yield for the current yield
metric.
[0123] In other embodiments, different yield components may be
weighted differently, as in some embodiments, a given category of
deal may not be significantly affected by certain yield components
For example, for deals in categories in which goods and/or services
are fulfilled electronically, a locations/distance yield component
may play a small or negligible role in determining an expected
yield. (Alternatively, for such categories, a locations/distance
yield component may be completely omitted from expected-yield
determinations, or assigned a weight of zero to constructively omit
the yield component from the expected-yield determination.)
[0124] Conversely, in some embodiments, for certain populations
and/or categories, some yield components (e.g., a price yield
component and/or a discount yield component) may dominate the
expected yield, such yield components being assigned higher
weighting factors than other yield components.
[0125] In block 750, subroutine 700 accumulates the current
adjusted expected yield into the overall expected-yield score data
structure (initialized in block 710) for the current expected-yield
metric (for the given prospective deal and the given target
population).
[0126] In closing loop block 760, subroutine 700 iterates back to
block 720 to process the next yield component (if any). Once all
yield components have been processed, in block 765, subroutine 700
stores (at least in transient memory) the current expected-yield
score (which includes weighted expected yield values derived from
each yield component for the current expected-yield metric). In
some embodiments, the current expected-yield score is stored at
least until the current expected-yield score is returned in block
799.
[0127] In closing loop block 770, subroutine 700 iterates back to
block 705 to process the next population-specific expected-yield
metric (if any). Having processed each population-specific
expected-yield metric, subroutine 700 ends in block 799, returning
one or more expected-yield scores for the prospective deal.
[0128] Although specific embodiments have been illustrated and
described herein, a whole variety of alternate and/or equivalent
implementations may be substituted for the specific embodiments
shown and described without departing from the scope of the present
disclosure. This application is intended to cover any adaptations
or variations of the embodiments discussed herein.
* * * * *