U.S. patent application number 14/054365 was filed with the patent office on 2014-09-18 for rule-based bidding platform.
This patent application is currently assigned to PRICEGRABBER.COM, INC.. The applicant listed for this patent is PRICEGRABBER.COM, INC.. Invention is credited to Dominique Jean, Graham Jones, Robert Ritter.
Application Number | 20140279055 14/054365 |
Document ID | / |
Family ID | 44309679 |
Filed Date | 2014-09-18 |
United States Patent
Application |
20140279055 |
Kind Code |
A1 |
Jones; Graham ; et
al. |
September 18, 2014 |
RULE-BASED BIDDING PLATFORM
Abstract
A computing system is configured to accept bid rules from
merchants for the placement of ads for a plurality of products. The
bid rules comprise a bid amount, a rule definition and a priority.
The bid amount may be an absolute bid or it may be relative to base
advertising rate. The rule definition comprises criteria for
describing products to determine when the bid rule is applied to a
product for sale. The priority indicates whether the bid rule
applies to a particular product when the rule definition of more
than one bid rule could be applied to a product. The computing
system is also configured to generate a list of product offers
based at least in part on the bids. The system may also generate
reports for merchants.
Inventors: |
Jones; Graham; (Los Angeles,
CA) ; Jean; Dominique; (Los Angeles, CA) ;
Ritter; Robert; (Los Angeles, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
PRICEGRABBER.COM, INC. |
Los Angeles |
CA |
US |
|
|
Assignee: |
PRICEGRABBER.COM, INC.
Los Angeles
CA
|
Family ID: |
44309679 |
Appl. No.: |
14/054365 |
Filed: |
October 15, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13013591 |
Jan 25, 2011 |
8566166 |
|
|
14054365 |
|
|
|
|
61298176 |
Jan 25, 2010 |
|
|
|
Current U.S.
Class: |
705/14.71 |
Current CPC
Class: |
G06Q 30/08 20130101;
G06Q 30/02 20130101; G06Q 30/0275 20130101 |
Class at
Publication: |
705/14.71 |
International
Class: |
G06Q 30/02 20060101
G06Q030/02 |
Claims
1. A method comprising: generating, by a bidding platform computing
device, a computer interface usable by a merchant in order to place
bids for placement of ads for a plurality of products based on one
or more bid rules, wherein each bid rule comprises: a bid amount
indicating an absolute advertising rate or a relative bid
adjustment to be made to a base advertising rate; a rule definition
comprising criteria for identifying products of the merchant
associated with the respective bid rule, the criteria comprising
one or more price criteria, taxonomy criteria, or product
manufacturer criteria; and a bidding priority indicating a
respective priority of the bid rule in relation to other bid rules;
transmitting the computer interface to a computing device of the
merchant, and receiving one or more bid rules of the merchant from
the merchant computing device.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to and is a continuation of
U.S. application Ser. No. 13/013,591, filed Jan. 25, 2011, which
claims priority to U.S. Provisional Application No. 61/298,176,
filed Jan. 25, 2010, each of which is hereby incorporated by
reference in its entirety.
[0002] Additionally, this application relates to U.S. Pat. No.
8,321,279, issued Nov. 27, 2012, which is hereby incorporated by
reference in its entirety.
BACKGROUND
[0003] 1. Field of the Disclosure
[0004] This disclosure relates to systems and methods for adjusting
base advertising rates.
[0005] 2. Background of the Disclosure
[0006] Currently, many merchants advertising products for sale
on-line are charged for advertising based on a cost-per-click
("CPC") model. In the CPC model, a merchant is charged a fee each
time a potential consumer clicks on an advertisement for the
merchant's product offer. The CPC rates for goods or services are
generally defined by a rate card. A rate card defines advertising
rates based on the type of good or service being sold. Rate cards
are traditionally set and updated by a merchant's account manager
or by a media outlet offering advertising. When rate cards are set
by the media outlet, a problem arises when many merchants offer the
same product or service as it may become difficult for merchants to
receive advantageous ad placement. Furthermore, the static nature
of rate cards prevents merchants from adjusting their advertising
based on dynamic sales data. Thus, there is a need for allowing
merchants more flexibility in setting CPC rates.
SUMMARY OF THE DISCLOSURE
[0007] In one embodiment, a system accepts bid rules for making
dynamic adjustments to the CPC rates of products offered for sale
by a merchant. The system generates a computer interface for
inputting bid rules. Each bid rule may include a bid amount, a rule
definition, and/or a priority. The bid amount indicates what
adjustment is to be made to the CPC rate of a product offer. The
bid amount may be absolute where it overrides the CPC rate defined
in the rate card for the product. In that case, the merchant is
charged the bid amount as an advertising rate. Alternatively, the
bid amount may be relative to the amount defined in the rate card
for the product. When the bid amount is relative, the merchant is
charged the CPC rate defined in the rate card for the product plus
the bid amount. Relative bid amounts may be negative. The rule
definition (also referred to as a "bid criteria") includes criteria
for matching products to the bid rule. A rule definition comprises
one or more product conditions. Each product condition may be one
of price, taxonomy, manufacturer, and/or any other product
attribute. In the case where bid criteria of multiple bids each
match a particular product offer, the system determines which bid
rule applies to the product offer using the priorities associated
with the multiple matching bid rules. The system transmits the user
interface to a merchant computing system and then accesses the bid
rule entered by the merchant. The present disclosure also describes
systems and methods of accepting bid rules. In one embodiment, a
bidding platform computing device generates a computer interface
that may be used by merchants to provide bid rules for the
advantageous placement of ads offering products for sale. The bid
rules may comprise a bid amount, a rule definition and a priority.
The user interface is transmitted to a merchant computing device
and the bidding platform computing device receives the bid rules
entered by the merchant.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1A is a block diagram illustrating one embodiment of a
rule based bidding platform computing system in communication with
a consumer computing system, a syndicate partner computing system
and one or more merchant computing systems.
[0009] FIG. 1B is a block diagram illustrating another embodiment
of a rule based bidding platform computing system in communication
with a consumer computing system, a syndicate partner computing
system and one or more merchant computing systems, where an
exemplary temporal flow of data is outlined.
[0010] FIG. 1C is a flowchart illustrating the temporal flow of
data for setting the CPC rate in one embodiment of a rule based
bidding platform system in communication with a consumer, a
syndicate partner computing system and one or more merchants.
[0011] FIG. 1D is a flowchart illustrating the temporal flow of
data for determining the applicable bid rule for setting the CPC
rate in one embodiment of a bidding platform computing system in
communication with a consumer, a syndicate partner and one or more
merchants.
[0012] FIG. 2 is a block diagram illustrating one embodiment of a
bidding platform computing system.
[0013] FIG. 3 illustrates an exemplary user interface for viewing,
editing and adding bid rules for merchant products.
[0014] FIG. 3A illustrates an exemplary user interface for adding
bid rules for merchant products based on the price of the
products.
[0015] FIG. 3B illustrates an exemplary user interface for adding
bid rules for merchant products based on the taxonomy of the
products.
[0016] FIG. 3C illustrates an exemplary user interface for adding
bid rules for merchant products based on the manufacturer of the
products.
[0017] FIG. 3D illustrates an exemplary user interface for adding
bid rules for merchant products based on the taxonomy and the
manufacturer of the products.
[0018] FIG. 3E illustrates an exemplary user interface for adding
bid rules for merchant products based on the price, the taxonomy
and the manufacturer of the products.
[0019] FIG. 3F illustrates an exemplary user interface for entering
a bid amount. The bid amount can either be absolute, relative to
the CPC rate card value, or equal to the CPC rate card value.
[0020] FIG. 4A illustrates an exemplary user interface for setting
the source of bids for merchant product offers.
[0021] FIG. 4B is a flowchart illustrating one embodiment of a
method for determining the rule for setting the CPC value for a
product offer based on the selected source of bids.
DETAILED DESCRIPTION
[0022] Embodiments of the invention will now be described with
reference to the accompanying figures, wherein like numerals refer
to like elements throughout. The terminology used in the
description presented herein is not intended to be interpreted in
any limited or restrictive manner, simply because it is being
utilized in conjunction with a detailed description of certain
specific embodiments of the invention. Furthermore, embodiments of
the invention may include several novel features, no single one of
which is solely responsible for its desirable attributes or which
is essential to practicing the inventions herein described.
[0023] FIG. 1A is a block diagram illustrating one embodiment of
bidding platform computing system 130 (or "bidding system 130") in
communication with consumer computing system 110, syndicate partner
computing system 120 (or "partner system 120"), and one or more
merchant computing systems 140 (including merchant computer system
140A, merchant computing system 140B, and merchant computing system
140N). Partner system 120 may, for example, host a website where
visitors may search for products and/or product information. In
addition, partner system 120 may present product offers from
multiple merchants offering products for sale. Consumer computing
system 130 may access partner system 120 to search for products or
product information in an attempt to find the most attractive
purchasing option. Partner system 120 may aggregate multiple
product offers and generate a user interface displaying the product
offers and transmit it to consumer computing system 110. In one
embodiment, partner system 120 may present multiple product offers
from multiple merchants for the same product. Merchant computing
systems 140 may, for example, offer several products for sale. For
example, consumer computing system 110 may access a website hosted
by one of merchant computing systems 140 to purchase a product. A
user of consumer computing system 110 may be able to purchase a
product directly from one of merchant computing systems 140.
[0024] In one embodiment, the system outlined in FIG. 1A is
computerized, wherein each of the illustrated components comprises
a computing device that is configured to communicate with other
computer devices via network 190. For example, consumer computing
system 110 may comprise a computing device, such as a desktop,
notebook, or handheld computing device that is configured to
transmit and receive data to/from other computing devices via
network 190. Similarly, each of the merchant computing systems 140,
syndicate partner computing system 120 and bidding platform
computing system 130, may include one or more computing devices
that are configured to communicate data with other computing
devices via network 190. Depending on the embodiment, network 190
may comprise one or more of any type of network, such as one or
more local area networks, wide area networks, personal area
networks, telephone network, and/or the Internet, which may be
accessed via any available wired and/or wireless communication
protocols. Thus, network 190 may comprise a secure LAN through
which bidding platform computing system 130 and partner system 120
communicate, and network 190 may further comprise an Internet
connection through which bidding platform computing system 130 and
consumer computing system 110 communicate. Any other combination of
networks, including secured and unsecured network communication
links, are contemplated for use in the systems described
herein.
[0025] FIG. 1B is a block diagram illustrating another embodiment
of bidding platform computing system 130, consumer computing system
110 and one or more merchant computing systems 140 of FIG. 1A,
where an exemplary temporal flow of data is outlined. In
particular, the circled numerals of FIG. 1B illustrate the order in
which data flows between the various components of FIG. 1B
according to one embodiment. In another embodiment, the steps
outlined by the circled numerals may be performed in a different
order, and the method may include fewer or additional steps.
[0026] In step one of FIG. 1B, bidding platform computing system
130 receives bid rules and product offers from one or more merchant
computing systems 140. In one embodiment, the bid rules are
received through bidding tool user interface 300 (FIG. 3) or
similar user interface generated by bidding platform computing
system 130. Bidding tool user interface 300 may then be transmitted
through network 190 to merchant computing systems 140. A user of
merchant computing systems 140 may enter one or more bid rules
through bidding tool user interface 300. In one embodiment, a bid
rule may modify the base CPC rate of a particular product offer
when the rule definition of the bid rule matches the product of the
product offer.
[0027] Rule definitions (also referred to as "bid criteria") may
comprise criteria for identifying one or more products the merchant
is offering for sale. In one embodiment, the rule definition
criteria may include one or more product conditions related to
product prices. A product condition related to price, for example,
may indicate that a bid rule applies to products below a specific
price, above a specific price or between two prices. In another
embodiment, the rule definition criteria may include one or more
product conditions related to the product taxonomies. For example,
bidding platform computing system 130 may define categories that
describe groups of products with different levels of granularity,
where each level provides a more specific description of the group
of products. The highest level, for example, may be appliances, and
the second highest level may be large kitchen appliances. The
number of levels of granularity may vary from embodiment to
embodiment as needed to accurately represent the products for which
bidding platform computing system 130 accepts bid rules. In one
embodiment, product taxonomy information provided by merchants is
analyzed in order to associate respective products into one or more
of the categories established by bidding platform computing system
130.
[0028] In another embodiment, the rule definition may include one
or more product conditions related to the manufacturer of the
product. For example, a product condition may indicate that a bid
rule applies to products made by Brand X. In another embodiment,
the rule definition criteria may include one or more product
conditions related to any one of price, taxonomy or manufacturer. A
rule definition, for example, may indicate that a bid rule applies
to products that are laptop computers, priced below $1000, and
manufactured by Brand X.
[0029] In some embodiments, rule definition criteria may include
other descriptive information that may be used to identify a
product or a set of products the merchant is offering for sale. For
example, a rule definition may include other attributes independent
of price, taxonomy or manufacturer, such as conversion rate (e.g.,
how many products sold per time period), product condition (new,
used, excellent, good, fair, etc.), gender (e.g., for clothing),
product compatibility (e.g., for auto parts, appliance parts,
computers, etc.), size (e.g., for TVs, hard drives, etc.) or any
other product-related attributes. Such attributes may be extracted
from the product offers received from merchant computing systems
140. In one embodiment, the extracted attributes of product offers
may not directly correspond to attributes that are used by bidding
system 130. In such cases, bidding system 130 may normalize
multiple sets of different product attributes received from
multiple merchants by mapping them all to a common set of
attributes defined by bidding system 130. These common attributes
may then be used to associate respective products to one or more
categories defined by the merchant 130. In this way, relationships
between products of different merchants may be better compared
using the same framework of attributes and categories. In another
embodiment, bidding system 130 may map merchant defined product
attributes to product categories (either merchant or bidding system
defined product categories).
[0030] In one embodiment, bid rules are assigned priorities that
are usable by bidding system 130 to select a highest priority bid
rule in the case where bid criteria of multiple bid rules each
match a particular product offer. For example, this may occur when
the rule definitions of the bid rules are defined in such generic
terms that they overlap with respect to a particular product
offered for sale by the merchant. In such cases, the priority of
the bid rules may be used to determine which bid rule to apply to
the product offer. For example, a merchant may enter a first bid
rule to modify the base CPC rate of all appliances and assign the
bid rule a priority of 2. The merchant may enter a second bid rule
that modifies the base CPC rate of all items manufactured by Brand
X and assign the bid rule a priority of 1. If the merchant offers
for sale an appliance made by Brand X, the rule definitions of the
first bid rule and second bid rule will apply to the product offer
since the first bid rule is triggered when the product is an
appliance and the second bid rule is triggered when the product is
made by Brand X. The priority of the first bid rule and second bid
rule will then be used to determine which bid rule to apply to the
product offer. In this example, the second bid rule that modifies
the CPC rate based upon the manufacturer would apply to the product
offer since it has a higher priority. Accordingly, the base CPC
rate will be adjusted based upon the bid amount of the second bid
rule.
[0031] In one embodiment, bid rules are assigned bid amounts that
are used to determine how the base CPC rate defined in the rate
card may be modified when the rule definition of the bid rule
applies to a product offer. In one embodiment, the bid amount may
be absolute such that the bid amount is used in place of a base CPC
rate defined in the rate card. In another embodiment, the bid
amount may be relative such that the bid amount is used to modify
the base CPC rate defined in the rate card by the bid amount.
[0032] In another embodiment, bid rules may be set for specific
products, such that the bid amounts of the product-specific bid
rules override the base CPC rate of a product offer for the
specific product. The bidding platform computing system 130 may
generate a user interface for inputting product-specific bid rules
and transmit the user interface to merchant computing systems 140.
The user interface may provide search functionality allowing any
one of merchant computing systems 140 the ability to find a
particular product. The search functionality, for example, may
include searching by price, taxonomy or manufacturer. In another
embodiment, the search functionality may include searching based on
any one of, or any combination of, price, taxonomy, manufacturer,
and/or any other product attribute. The user interface may allow
entry of bid amount. In one embodiment the bid amount be absolute,
and in another embodiment it may be relative.
[0033] Referring back to step 1 of FIG. 1B, in another embodiment,
bidding platform computing system 130 may receive CPC rates (e.g.,
bids) from a data feed as opposed to bidding tool user interface
300. In one embodiment, the data feed may include bid for specific
products as opposed to a group of products, such that the bid
amounts of the product-specific bid override the CPC rate of a
product offer for the specific product. In another embodiment, the
data feed may support entry of bid that modify the base CPC rate of
a product offer based upon one or more rule definitions as
described above. The data feed may comprise a text file, an
spreadsheet, an XML file, a serialized object, a byte stream or any
other mechanism known in the art to communicate data between
computing systems.
[0034] Referring again to step 1 of FIG. 1B, in one embodiment,
merchant computing systems 140 may provide bidding platform
computing system 130 a list of product offers. Bidding platform
computing system 130 may receive the list of product offers from
the merchant computing system via the data feed described above.
Each product offer may include, for example, a product description,
a price, a model number and one or more descriptors related to the
taxonomy of the product. The taxonomy of the product may relate to
the category of good of the product offered for sale.
[0035] In one embodiment, bidding system 130 calculates the
adjusted CPC rate of product offers whenever merchant computing
systems 140 send an updated product offer list. Thus, the CPC rate
for each of the products in a merchant's product offer list is
determined and stored by the bidding system 130 so that the CPC
rates are available in response to requests for placement of the
various products to consumers. In some embodiments, bidding system
130 may calculate the adjusted CPC rate of product offers
periodically or based on a predetermined schedule. Alternatively,
bidding system 130 may calculate the adjusted CPC rate of product
offers when merchant computing systems 140 submit new bid rules. In
another embodiment, bidding system 130 may calculate the adjusted
CPC rate of product offers based on any combination of the above
methods.
[0036] In step 2 of FIG. 1B, consumer computing system 110 may make
a request for product offers for one or more products, such as via
a product search interface wherein the consumer typed a product
search query. In one embodiment, the request may be for a uniquely
identified product, such as a request for a particular make/model
of product. In another embodiment, the request may be for a
generically identified product, such as a general type of product.
In one embodiment, the request, includes a set of criteria
specified by the user of consumer computing system 110, such as one
or more product category, search keyword(s), and/or any other
product attribute filter. In one embodiment, the request may be
received by a syndicate partner computing system 120. The syndicate
partner computing system 120 may provide a user interface for entry
of requests from a consumer computing system 110.
[0037] In step 3 of FIG. 1B, bidding platform computing system 130
receives a request for product offers from partner computing system
120. In one embodiment, the request that bidding system 130
receives from syndicate system 120 is the same request that
syndicate system 120 received from consumer computing system 110.
In another embodiment, syndicate system 120 modifies the request
received from the consumer computing system 110. In another
embodiment, bidding platform computing system 130 may receive a
request for a product offer directly from consumer computing system
110. For example, partner system 120 may not be involved in the
provision of product offers to the consumer computing system 110 in
this embodiment. Instead, bidding system 130 may provide a user
interface for entry of a request directly to the consumer computing
system 110. Depending on the embodiment, the request may be for a
uniquely identified product, for a generically identified product,
and/or for products that match keywords provided by the consumer
computing system 110. For example, product requests, whether from
the consumer computing system 110 or the partner system 120, may
not be for specific products, but rather, for a group of products
based on product category, a search keyword or any product
attribute filter describing one or more products.
[0038] In step 4 of FIG. 1B, bidding system 130 generates a list of
product offers for the products matching the request received from
partner computing system 120 (or in another embodiment, received
directly from consumer computing system 110). In one embodiment,
bidding system 130 determines the product offers matching the
request. If more than one product offer matches the request,
bidding system 130 may order the product offers based at least in
part on the calculated CPC rate of products when it generates the
list of matching product offers. In another embodiment, bidding
system 130 may determine that some product offers matching the
request will be excluded from the generated list of matching
product offers. For example, product offers may be excluded based
at least in part on the calculated CPC rate of the product offer
and conditions established by syndicate partner computing system
120. In another embodiment, product offers may be excluded based on
the identity of the merchant making the product offer. In one
embodiment, once the list of matching product offers is created,
bidding system 130 sends the list to partner computing system 120.
In another embodiment, the list is sent to consumer computing
system 110. In another embodiment, bidding system 130 generates a
list of products, as opposed to product offers, matching a general
request, such as one or more product category, search keyword(s),
and/or any other product attribute filter, for products from
partner computing system 120, or in other embodiments, consumer
computing system 110. Bidding system 130 may determine a particular
product offer to feature in the product list based at least in part
on the calculated CPC rate for the particular product offer. For
example, bidding system 130 may use special fonts, graphics or
other displays to highlight a particular product offer having a
highest CPC. In one embodiment, bidding system 130 uses the
determined featured product offer as a representative product offer
for a product category in a list including one or more product
categories each associated with products matching a general product
request. For example, if bidding system 130 received a request for
washing machines from partner system 120, bidding system 130 may
determine that product categories A, B and C match the request.
Bidding system 130 may also determine that product offer X should
be featured for category A, product offer Y should be featured for
category B, and product offer Z should be featured for category C.
When generating the list of products, bidding system 130 may use
product offers X, Y and Z as representative offers of product
categories A, B and C, respectfully.
[0039] Moving to step 5 of FIG. 1B, consumer computing system 110
receives the list of product offers. In one embodiment, the list is
received from partner computing system 120. In another embodiment,
the list is received from bidding system 130. In one embodiment,
the product offer list may include one or more hyperlinks to a user
interface generated by merchant computing systems 140 offering the
product for sale. In another embodiment, consumer computing system
110 receives the list of products, but not product offers. The
product list may include one or more hyperlinks to a user interface
generated by bidding system 130 listing the product offers
corresponding to the product. The user interface may order the
product offers based at least in part on the calculated CPC rate of
each product offer.
[0040] In step 6 of FIG. 1B, bidding system 130 receives data
representing a product offer selected by the consumer using the
consumer computing system 110. In one embodiment, the received data
indicates which merchant computing system 140 offered the product
for sale. This data may be used, for example, to determine the
amount to charge the operator of the merchant computing system for
the selection of its product offer by consumer computing system
110. In one embodiment, this determination is based in part on the
calculated CPC rate of the selected product offer. In another
embodiment, bidding system may use the received data when
generating reports for merchants.
[0041] FIG. 1C is a flowchart illustrating one embodiment of a
method for setting the CPC rates of a plurality of products. In one
embodiment, the method of FIG. 1C is performed by bidding system
130. However, the method may be performed by any other suitable
computing device. Depending on the embodiment, the method may
include fewer or additional blocks and/or the blocks may be
performed in a different order than is illustrated.
[0042] Beginning in block 145, bidding system 130 receives bid
rules from merchant computing systems 140. As described above, the
bid rules may be received via a bidding tool user interface 300 or,
in another embodiment, a data feed.
[0043] Next, in block 150, for each product the merchant offers for
sale, bidding system 130 determines the applicable bid rule for
setting the CPC rate of the product. For example, the bidding
system 130 applies the bid rules established by the merchant in
order to determine the appropriate CPC for each product. This
process is described in further detail with reference to FIG. 1D,
below.
[0044] Finally, in block 160, once the applicable bid rule is
determined for respective products, bidding system 130 sets the CPC
for the products based upon the respective applicable bid rule. In
one embodiment, the CPC calculation may include the cost of
additional services to increase product offer visibility in
addition to the bid amount. For example, the CPC calculation may
include the cost of displaying a logo, custom colors, custom fonts,
displaying special images, banner placement, designation as a
featured product, designation as a featured merchant, or any other
means of increasing product offer visibility.
[0045] In one embodiment, the CPC rate may be calculated using a
bid rule where the bid amount is absolute and overrides the base
CPC rate defined in the rate card for the product. In another
embodiment, the CPC rate may be calculated using a bid rule where
the bid amount is relative to the base CPC rate defined in the rate
card for the product. When the bid amount is relative to the base
CPC rate for the product, the base CPC rate is adjusted by the bid
amount and the final CPC rate is calculated using the adjusted base
rate and the rate for any additional services to increase product
visibility. Relative bid amounts may be a price value, such as
$0.10, or in other embodiments, may be a percentage, such as 10%.
Percentages may be positive, indicating a percentage increase in
the rate card rate, or negative, indicating a percentage decrease
in the rate card rate
[0046] FIG. 1D is a flowchart illustrating one embodiment of a
method of determining of the applicable bid rule for each of a
plurality of products offered by a merchant. The method 150 of FIG.
1D may be part of the method of FIG. 1C. In one embodiment, the
blocks of FIG. 1D may be performed when a merchant submits a data
feed describing the products the merchant wishes to offer for sale.
In another embodiment, the blocks of FIG. 1D may be performed on a
periodic basis by bidding system 130, e.g., using a product list
and/or bid rules that may have been updated by the merchant since
the CPC rates were last set. In another embodiment, the blocks of
FIG. 1D may be performed by bidding system 130 in response to
receiving a new bid criteria from merchant computing system 140.
Depending on the embodiment, the method of FIG. 1D may include
fewer or additional blocks and blocks may be performed in a
different order than is illustrated.
[0047] As described herein, the method of FIG. 1D is performed for
each product offered for sale by a merchant, such that one bid rule
is selected for each product and that bid rule can be used to set
the CPC for the respective product offer. Beginning in block 152,
the bidding system 130 selects a product from the plurality of
products offered by a particular merchant, and accesses information
regarding the product. For example, the bidding system 130 may
select products in a sequential order, or in any other order.
[0048] Once a specific product is selected, in block 156 the
bidding system 130 selects the next bid rule defined by the
merchant for comparison with the currently selected product.
Bidding system 130 may cycle through the bid rules in any
order.
[0049] In block 156, bidding system 130 analyzes the rule
definition of the bid rule in order to determine if the product
satisfies the rule definition. As stated above, a rule definition
may have one or more product conditions associated with various
product attributes. Bidding system 130 compares the product
conditions of the selected bid rule to the selected product. If the
product satisfies all of the product conditions, the method
continues to block 158 where the bid rule is added to a set of
matching bid rules. If the product does not match the rule
definition at block 156, the method continues to block 160 without
adding the select bid rule to the list of matching bid rules.
[0050] In block 160, the bidding system 130 determines if there are
more bid rules defined by the merchant offering the product for
sale. If so, the method returns to block 154 and the bidding system
130 repeats blocks 154-160 for another bid rule defined by the
merchant.
[0051] When the bidding system 130 determines in block 160 that
there are no further bid rules to compare to the selected product,
the method continues to decision block 162 where the bidding system
130 determines if there are one or more bid rules matching the
product (e.g., if there are any bid rules on the list of matching
bid rules). If there are no matching bid rules, bidding system 130
sets the CPC to the rate card value for the product in block 164
(or to some other value that is predetermined by the bidding system
130 and or the merchant in other embodiments).
[0052] In block 166, the bidding system 130 determines the
applicable bid rule for the selected product based on the
priorities of the matching bid rules. If there is only one matching
bid rule, then the bid amount from that bid rule will be used to
set the CPC, without consideration of the priority for the one
matching bid rule. However, if there is more than one matching bid
rule, then bidding system 130 determines the applicable bid rule
based on the respective priority of each bid rule. In one
embodiment, the bid rule with the highest priority will be set to
the applicable bid rule. In one embodiment, the priority is a
numerical value. The numerical value may represent a ranking order
for the bid rules. For example, a bid rule with a priority of 1
would have a higher priority than a bid rule with a priority of 2.
In another embodiment, the priority may be represented with letters
or other symbols indicating an ordinal value. As noted in block 160
of FIG. 1C, once the applicable bid rule is determined, the base
CPC rate for the product is set using the bid amount of the
applicable bid rule. As stated above, bid amounts may be absolute
or relative to the rate card rate. If the bid amount is absolute,
the CPC rate is set to the bid amount. If the bid amount is
relative, the rate card rate for the product is adjusted by the bid
amount to determine the base CPC rate.
[0053] In another embodiment, the order of the calculation of
modified base CPC rates may be based on the priority of the bid
rules defined by merchant computing systems 140. For example, in
one embodiment, bidding system 130 may select all of the bid rules
for a merchant and start modifying CPC rates based on the bid rule
with the highest priority. This may be, for example, the bid rule
where the priority is set to 1. Next, bidding system 130 may
determine all product offers that match the rule definition for the
bid rule and modify the base CPC rates for those product offers.
Then, bidding system 130 may analyze the bid rule with the second
highest priority, for example, the bid rule where the priority is
set to 2. Bidding system 130 then determines all product offers
that match the rule definition for the bid rule of the second
highest priority and for which bidding system 130 did not already
modify the base CPC rate. Bidding system 130 then modifies the base
CPC rates of the determined products. Bidding system then repeats
the process for each bid rule of decreasing priority until all bid
rules have been analyzed. In this embodiment, each time a bid rule
is matched to one or more products, the lower priority bid rules
are applied to a smaller set of products (because products that
already have a higher priority matching bid rule are not again
analyzed with reference to lower priority bid rules). Thus, the
lower priority bid rules may be applied to a smaller (possibly much
smaller) portion of the products, allowing the bid system 130 to
more quickly assign advertising rates for product offers.
[0054] FIG. 2 is a block diagram illustrating one embodiment of
bidding system 130. In one embodiment, bidding system 130 is
configured to interface with multiple devices and/or data sources,
such as in the exemplary network configurations of FIGS. 1A and 1B.
Bidding system 130 may be used to implement certain systems and
methods described herein. For example, in one embodiment bidding
system 130 may be configured to generate bidding tool user
interface 300, access bid rules from merchant computing systems
140, determine CPC rates for merchant products based on
merchant-defined bid criteria, access requests from consumer
computing system 110 and partner computing system 120 in order to
identify product offers to be provided to consumer computing system
110, generate a list of matching product offers to provide to the
consumer computing system 110 (which doesn't necessarily include
all of the matching product offers), and generate a user interface
for displaying the list of matching product offers. The
functionality provided for in the components and modules of bidding
system 130 may be combined into fewer components and modules or
further separated into additional components and modules.
[0055] In general, the word module, as used herein, refers to logic
embodied in hardware or firmware, or to a collection of software
instructions, possibly having entry and exit points, written in a
programming language, such as, for example, C, C++, or C#. A
software module may be compiled and linked into an executable
program, installed in a dynamic link library, or may be written in
an interpreted programming language such as, for example, BASIC,
Perl, or Python. It will be appreciated that software modules may
be callable from other modules or from themselves, and/or may be
invoked in response to detected events or interrupts. Software
modules may be stored in any type of computer-readable medium, such
as a memory device (e.g., random access, flash memory, and the
like), an optical medium (e.g., a CD, DVD, BluRay, and the like),
firmware (e.g., an EPROM), or any other storage medium. The
software modules may be configured for execution by one or more
CPUs in order to cause the computing system 140 to perform
particular operations.
[0056] It will be further appreciated that hardware modules may be
comprised of connected logic units, such as gates and flip-flops,
and/or may be comprised of programmable units, such as programmable
gate arrays or processors. The modules described herein are
preferably implemented as software modules, but may be represented
in hardware or firmware. Generally, the modules described herein
refer to logical modules that may be combined with other modules or
divided into sub-modules despite their physical organization or
storage.
[0057] In one embodiment, bidding system 130 includes, for example,
a server or a personal computer that is IBM, Macintosh, or
Linux/Unix compatible. In another embodiment, bidding system 130
comprises a laptop computer, smart phone, personal digital
assistant, or other computing device, for example. In one
embodiment, the exemplary bidding system 130 includes one or more
central processing units ("CPU") 220, which may include one or more
conventional or proprietary microprocessors. Bidding system 130
further includes a memory 240, such as random access memory ("RAM")
for temporary storage of information and a read only memory ("ROM")
for permanent storage of information, and a data store 200, such as
a hard drive, diskette, or optical media storage device. In certain
embodiments, the data store 200 stores product data, bid data
and/or merchant data. Embodiments of data store 200 may store data
in databases, flat files, spreadsheets, or any other data structure
known in the art. Typically, the modules of bidding system 130 are
in communication with one another via a standards based bus system.
In different embodiments, the standards based bus system could be
Peripheral Component Interconnect (PCI), Microchannel, SCSI,
Industrial Standard Architecture (ISA) and Extended ISA (EISA)
architectures, for example. In another embodiment, bidding system
130 leverages computing and storage services available over the
Internet (cloud computing).
[0058] Bidding system 130 is generally controlled and coordinated
by operating system and/or server software, such as the Windows 95,
98, NT, 2000, XP, Vista, Linux, SunOS, Solaris, PalmOS, Blackberry
OS, or other compatible operating systems. In Macintosh systems,
the operating system may be any available operating system, such as
MAC OS X. In another embodiment, bidding system 130 may be
controlled by a proprietary operating system. Conventional
operating systems control and schedule computer processes for
execution, perform memory management, provide file system,
networking, and I/O services, and provide a user interface, such as
a graphical user interface ("GUI"), among other things.
[0059] The exemplary bidding system 130 may include one or more
commonly available input/output (I/O) interfaces and devices 230,
such as a keyboard, mouse, touchpad, and printer. In one
embodiment, the I/O devices and interfaces 230 include one or more
display device, such as a monitor, that allows the visual
presentation of data to a user. More particularly, a display device
provides for the presentation of GUIs, application software data,
and multimedia presentations, for example. In one embodiment, I/O
interfaces and devices 230 comprise devices that are in
communication with modules of bidding system 130 via a network,
such as network 190 and/or any secured local area network, for
example. In the embodiment of FIG. 2, the I/O devices and
interfaces 230 provide a communication interface to various
external devices. For example, in this embodiment bidding system
130 is in communication with a network, such as any combination of
one or more LANs, WANs, or the Internet, for example, via a wired,
wireless, or combination of wired and wireless, connections via a
network interface of the I/O devices and interfaces 230.
[0060] In the embodiment of FIG. 2, bidding system 130 also
includes several application modules that may be executed by CPU
220. More particularly, the application modules include custom bid
rule module 250, product retrieval module 260, product bid module
270, import data feed module 280, consumer interface module 290,
and reporting module 210.
[0061] In one embodiment, custom bid module 250 may comprise
software code executable by CPU 220 that handles the generation of
user interfaces for inputting bid information such as bidding tool
user interface 300. Custom bid module 250 may also access bid rules
inputted into the generated user interfaces by merchant computing
systems 140. In one embodiment, the generated user interfaces may
be transmitted via network 190 using I/O interfaces and devices
230. In one embodiment, custom bid module 250 may store and access
merchant bid rules in/from data store 200.
[0062] Product retrieval module 260, in one embodiment, may
comprise software code executable by CPU 220 that handles retrieval
of product offers from data store 200. For example, the retrieval
may be in response to a request from consumer computing system 110
or partner computing system 120. In one embodiment, product
retrieval module 260 may be configured to calculate CPC rates for
product offers as described above with reference to FIGS. 1C and
1D.
[0063] Product bid module 270, in one embodiment, may comprise
software code executable by CPU 220 that handles the calculation
and modification of CPC rates for product offers. For example, in
one embodiment, product bid module 270 may calculate CPC rates as
described in FIG. 1C and FIG. 1D. In another embodiment, product
bid module 270 may calculate CPC rates for each merchant in bid
priority order. For example, for each merchant, product bid module
270 may first determine the advertising rates for the product
offers matching the rule definition of the bid rule having a
priority of 1. Then, product bid module 270 may determine the
advertising rates for the product offers matching the rule
definition of the bid rule having a priority of 2 which were not
already determined. Product bid module 270 may repeat this process
until all bid rules for a merchant have been analyzed. In one
embodiment, product bid module 270 may store and access modified
CPC rates in/from data store 200.
[0064] In one embodiment, import data feed module 280 is software
code executable by CPU 220 that handles the import of data feeds.
Data feeds may be received from merchant computing systems 140 and
may include the product offers of the merchants as well as bid
rules to modify the base CPC rate for particular products. In
another embodiment, import data feed module 280 may also access bid
rules from merchant data feeds that include rule definitions as
described above.
[0065] Consumer interface module 290 may include, in one
embodiment, software code executable by CPU 220 that generates user
interfaces sent to consumer computing systems 110. The generated
user interfaces may be used by consumer computing devices to
request product offers from bidding system 130.
[0066] In one embodiment, bidding system may include reporting
module 210, which may comprise software code executable by CPU 220
that handles creation of reports that can be accessed by merchant
computing systems 140. The reporting module may generate reports
that list all of the products a merchant may offer for sale. The
generated reports may include historical product information and
may include information pertaining to the number of clicks a
product has received over time. Reports may include information,
for example, pertaining to product description, rate card rates,
bid rules, CPC increases for holidays, costs for additional
services for increasing visibility of the product, product
identifiers such as UPC/ISBN, manufactures, prices, and number of
clicks.
[0067] In one embodiment, reports may be provided as user interface
that allows manipulation of the data in the report by the user of
the merchant computing device. For example, reports may allow
merchants to specify date ranges for display, where the date ranges
may be inputted via a calendar pop-up interface. In another
embodiment, reports may allow the user to sort the information
based on the number of clicks a product has received. In addition,
the reports may allow merchants to search for individual products
or groups of products by price, taxonomy or manufacturer.
Furthermore, the reports may allow merchants to show or hide data
columns. In one embodiment, reporting module 210 may permit
merchant computing systems 140 to export data in a customized
format. The customized format may include .CSV files, spreadsheets,
text files, proprietary formats for databases or reporting engines,
serialized objects or some other data format known in the art. In
one embodiment, the reporting module 210 may be configured to
automatically generate and send a custom report to the merchant
computing device.
[0068] As noted above, a bid rule may comprise a bid amount that is
relative to the rate card rate. In one embodiment, the relative
rate card rate may be negative, that is, the bid rule will adjust
the base CPC for the product to a value below the rate card rate
for the product. In one embodiment, the report generated by
reporting module 210 may include a visual indicator such as a red
"!" icon next to product offers with a CPC rate below the rate card
to indicate the product offer may not appear in some lists
generated in response to consumer product requests.
[0069] FIG. 3 illustrates an exemplary bidding tool user interface
300 for viewing, editing, and adding bid rules for merchant
products. In one embodiment, bidding tool user interface 300 is
generated by custom bid rule module 250 of bidding system 130 and
is accessed via a web browser (or other software) on the merchant
computing device. In the embodiment of FIG. 3, bidding tool user
interface 300 includes a bid rule table 310 including several
columns. This sample bid rule table 310 includes columns listing
the bid rule type (e.g. the product offer attributes relevant to
the bid, such as taxonomy, manufacturer, or price), the bid
criteria (e.g., the rule definition), the bid type (e.g., relative
or absolute), the bid amount, and the bid priority for each bid
rule. In other embodiments, additional or less information may be
received for each bid rule. Bidding tool user interface 300 may
also include add new bid rule panel 320. Add new bid rule panel 320
may include bid definition panel 330 as well as bid amount panel
340.
[0070] In the embodiment of FIG. 3, bid rule table 310 includes
user interface elements allowing the user to alter the elements of
bid rules. For example, edit icon 312 and delete icon 311 allow a
user to edit or delete a bid rule, respectfully, from bid rule
table 310. In one embodiment, when a user selects delete icon 311,
the user interface may display a confirmation (not shown) asking
the user to confirm that bidding system 130 should delete the bid
rule. In addition, when a user selects edit icon 312, a user
interface for editing the bid rule may be displayed. The user
interface for editing a bid rule may be similar to the user
interfaces described in FIGS. 3A-3F with the bid rule information
pre-populated.
[0071] The user interface 300 also indicates bid priorities in
column 316 and provides interfaces for adjusting the priorities of
bid rules. In this particular embodiment, the priority of bid rules
may be adjusted up or down using the up arrow 313 and down arrow
314 user interface elements. For example, when a user selects up
arrow 313, the priority of the associated bid rule will increase by
one. Alternatively, when a user selects down arrow 314, the
priority of the associated bid rule will decrease by one. In one
embodiment, the priority may also be adjusted in bid rule table 310
by directly inputting the bid priority in bid rule table 310. When
the priority of one bid rule is adjusted by the user, bidding
system 130 will then adjust the priorities of other bid rules, as
necessary. For example, when Bid rule A has priority 5 and Bid rule
B has priority 4 and a user selects up arrow 313 associated with
Bid rule A, bidding system 130 will change Bid rule A's priority to
4 and Bid rule B's priority to 5. Alternatively, if a user enters a
priority that already exists when adding or editing a bid rule,
bidding system 130 will assign the new bid rule the entered
priority and will adjust all other affected bid rules accordingly.
For example, if a user defines new Bid rule X with priority of 5,
and Bid rule Y already has priority 5, bidding platform will adjust
Bid rule Y's priority to 6. In this manner, bidding system 130 will
insure that each bid rule in the system has a unique priority for a
given merchant so that if there are multiple bid rules applicable
to a product, only one bid rule will be applied to the product in
accordance with the process outlined in FIG. 1D.
[0072] FIGS. 3A-3E each illustrates the bid definition panel 330 of
FIG. 3 with different bid rule conditions selected. As noted above,
the bid definition panel 330 may be used to add or edit merchant
bid rules based on any combination of price, taxonomy or
manufacturer. Bid definition panel 330 includes check box inputs
331, 334 and 336 for selecting what product conditions (e.g.,
price, taxonomy, or manufacturer) will be used to define a bid
criteria. For example, in the user interface depicted in FIGS.
3A-3E, a user may select any one of price, taxonomy or
manufacturer. As illustrated in FIG. 3D, more than one product
condition may be selected for a rule definition. While taxonomy and
manufacturer are selected in the embodiment depicted in FIG. 3D, it
can be appreciated that any combination of price, manufacturer or
taxonomy may be selected. Furthermore, other product conditions may
be used in other embodiments. In the embodiment of FIGS. 3A-3E, the
bid definition panel 330 also allows input of a priority for each
bid rule in priority definition text field 333. It can be
appreciated that when a user defines a priority using priority
definition text field 333, bidding system may need to adjust the
relative priority of already entered bid rules as described
above.
[0073] FIG. 3A specifically illustrates an exemplary user interface
for adding bid rules for merchant products based on the price of
the products. In one embodiment, a user may select checkbox 331
indicating that a price condition is part of the rule definition
for the bid rule. In one embodiment, a user may select one of a set
of radio buttons 332 indicating the logical condition associated
with the price value entered. For example, a user may define a
price condition to be equal to, greater than, or less than a
particular price. Alternatively, a user may define a range for the
price condition such that the rule definition is satisfied if the
price of a product is greater than a first value, but lower than a
second value.
[0074] FIG. 3B specifically illustrates an exemplary user interface
for adding bid rules for merchant products based on the taxonomy of
the products. In one embodiment, a series of drop-down lists 335
are provided for a user to select an appropriate channel, category
and/or sub-category for a particular product. Drop-down lists 335
may only be visible and active if taxonomy check box 334 is
selected. The channel drop-down list may be pre-populated with
descriptions of predefined product-groups at the most generic
level. For example, the channel drop-down list may be pre-populated
with descriptions such as appliances, sporting goods, computers,
musical instruments and the like. Once a user selects a channel,
bidding system 130 then populates the category drop-down list with
the available categories within that channel. For example, if a
user selects appliances as the channel, the category drop-down may
populate with descriptions such as air cleaners and heating
appliances, home appliances, large kitchen appliances, laundry,
small kitchen appliances, vacuum cleaners, and the like. After a
user selects a category, bidding system 130 will then populate the
sub-category drop-down list with the available sub-categories
within the category. For example, if a user selects appliances as
the channel and laundry as the category, the sub-category drop-down
may populate with descriptions such as clothes dryers, clothes
irons, laundry parts and accessories, washer/dryer combos, washing
machines, and the like. By allowing pre-population of drop-down
lists for product conditions based on taxonomy, bidding system 130
insures that only valid rule definitions may be submitted by
merchant computing systems 140.
[0075] FIG. 3C specifically illustrates an exemplary user interface
for adding bid rules for merchant products based upon product
manufacturers. In one embodiment, check box 336 may be selected
indicating that a rule definition comprising a manufacturer product
condition is being added. Once check box 336 is selected,
manufacturer text field 337 may be visible so that a user may enter
a manufacturer for triggering the product condition. In one
embodiment, a list of available manufacturers matching the text
entered by the user is displayed so that the user may select a
manufacturer from the available list. For example, in FIG. 3C, the
user typed "Sony" and all manufacturers starting with "Sony" were
displayed in an available list. The user may then select a
manufacturer from the list of available manufacturers. By allowing
selection from an available list of manufacturers, bidding system
130 insures that only valid rule definitions may be submitted by
merchant computing devices.
[0076] FIGS. 3D and 3E illustrate exemplary user interfaces for
adding bid rules for merchant products based on multiple product
conditions. In FIG. 3D, check boxes 334 and 336 are selected
indicating that the rule definition for the bid rule will comprise
a product conditions related to taxonomy and manufacturer. In FIG.
3E, check boxes 331, 334 and 336 are selected indicating that the
rule definition for the bid rule will comprise a product conditions
related to price, taxonomy and manufacturer. While not shown in the
figures, it may be appreciated that the rule definition of a bid
rule may include any combination of price, taxonomy and/or
manufacturer. In one embodiment, the entry of price conditions,
taxonomy conditions and manufacturer conditions are completed in
the same manner as described regarding FIGS. 3A-3C.
[0077] FIG. 3F illustrates an exemplary user interface for entering
a bid amount, specifically, bid amount panel 340 that may be part
of add new bid rule panel 320. In one embodiment, bid amount panel
340 may include text field 341 for entering a bid amount. Bid
amount panel, in one embodiment, may also provide a set of radio
buttons 342 for selecting the bid type. For example, a bid type may
be absolute, relative to the CPC rate card rate, or equal to the
rate card value. In one embodiment, when the absolute radio button
is selected, a user may enter a value in text field 341 that will
override the current CPC rate card rate for any products matching
the associated bid criteria (where the bid rule is the highest
priority matching bid rule). Alternatively, when the relative to
the CPC rate card rate radio button is selected, a user may enter a
value in text field 341 that is relative to the CPC rate card rate.
In one embodiment, a negative value may be entered for a relative
bid. In such cases, the resulting bid will result in a base CPC
rate that is lower than the CPC rate card rate. In another
embodiment, a percentage value may be entered for a relative bid.
Percentages may be positive, indicating a percentage increase in
the rate card rate, or negative, indicating a percentage decrease
in the rate card rate. Alternatively, when the use rate card value
radio button is selected, the resulting bid will be at the rate
card rate. In one embodiment, when the use rate card value radio
button is selected, text field 341 may be hidden from bid amount
panel 340. In another embodiment, text field 341 may be
deactivated, grayed out, or may prevent user input in some other
manner.
[0078] FIG. 4A illustrates an exemplary user interface for setting
the source of bids for merchant product offers, specifically, bid
source panel 400. Bid source panel 400 may include a set of radio
buttons 410 indicating the source of bids. In one embodiment, set
of radio buttons 410 may include a radio button for setting the
source to the input feed. When selected, bids will be determined
based on values imported from the data feed received by bidding
system 130 from merchant computing systems 140 as described above.
Set of radio buttons 410 may also include a use bidding tool radio
button. When selected, bidding system 130 may use bids as
determined based on bid rules defined via a bidding tool, such as
bidding tool user interface 300, for example. The set of radio
buttons may also include an option to allow the user to set the
source of bids to the rate card. When selected, bids entered from
the import feed or the bidding tool will be ignored by bidding
system 130, and the base CPC rate of product offers will be set to
the value indicated in the rate card.
[0079] FIG. 4B is a flowchart illustrating one embodiment of a
method for determining the rule for setting the CPC value for a
product offer based on the selected source of bids. In one
embodiment, if the source of bids is set to use rate card values,
then the base CPC for product offers is set to the rate card value
for each of the respective products. Alternatively, if the source
of bids is set to use the import data feed, the base CPC for
product offers is set based upon information received from the data
feed imported from merchant computing systems 140. Alternatively,
if the source of bids is set to use custom bid rules, bidding
system 130 calculates the CPC for each product based on the bid
rules previously received from merchant computing systems 140. For
example, bidding system 130 may access the bid rules defined by the
merchant and identify the highest priority matching bid rule for
each product in order to determine the CPC rate for the
products.
Other Embodiments
[0080] Another embodiment of bidding platform computer system 130
allows a group voucher retailer ("GVR") to dynamically adjust CPC
rates for the vouchers it offers for sale. A GVR is a merchant that
sells vouchers or coupons that are redeemable for the goods or
services of a different merchant or services provider. For example,
a GVR might offer to sell a coupon for $10 providing for a 50%
discount for a meal at a restaurant, or might offer to sell a
coupon for $50 providing for a $100 discount for an appliance. A
GVR, similar to a merchant operating merchant computing system 140,
may provide a website where consumers may purchase the vouchers it
offers for sale. To promote its voucher offers, a GVR may wish to
direct consumer traffic to its website and might do so through
advertising based on a CPC model. Like CPC rates for product
offers, CPC rates for voucher offers may be defined by a rate card.
A GVR may host a website where visitors may search for
vouchers/coupons offered for sale. Additionally, one or more
partners may host websites listing offers from one or more GVRs.
Consumer computing system 130 may access the GVR or partner system
to search for vouchers or coupons in an attempt to find the most
attractive voucher/coupon. The GVR or partner system may, in turn,
request from bidding system 130 a list of voucher offers. The
bidding system 130 may return a list to the GVR or partner based in
part on the CPC rate of voucher offers matching the request.
[0081] In one embodiment, bidding system 130 facilitates
advantageous ad placement by accessing bids from computing systems
operated by GVRs. GVRs may submit bid rules that determine when a
bid to modify the CPC rate of voucher offers should trigger. Entry
and application of bid rules to voucher offers is similar to the
entry and application of bid rules to product offers as described
in other embodiments above. For example, a GVR may enter a bid rule
into bidding tool user interface 130 with a rule definition
comprising criteria for identifying one or more vouchers the GVR is
offering for sale. In another embodiment, bidding system 130 may
receive bids from a data feed as opposed to a bidding user
interface (similar to bidding tool user interface 300). The rule
definition criteria may comprise price, taxonomy, brand (similar to
manufacturer), and/or other criteria. For example, a rule
definition may include taxonomy criteria such that a bid rule is
triggered when the voucher or coupon may be redeemed at a services
provider that belongs to channel "restaurants" and category
"Italian." In another embodiment, the rule definition criteria may
include brand or manufacturer criteria such that a bid rule
triggers when the voucher may be redeemed at Restaurant A or a
coupon applies to a product made by Brand X. In some embodiments,
the rule definition criteria may include other attributes
independent of price, taxonomy or brand, such as location (e.g.,
city and zip code), timing (e.g., expiration), or any other
voucher-related attributes.
[0082] In one embodiment, bid rules submitted by the GVR may be
assigned respective priorities. These priorities may be used in a
similar manner as discussed above in order to determine an
applicable bid rule of multiple bid rules each having bid criteria
that match a particular offer.
[0083] Based on the bid rules defined by a particular GVR, the
bidding platform may assign advertising rates to respective
voucher/coupon offers of the GVR. For example, when a GVR provides
a new voucher offer to the bidding platform, the bidding platform
may analyze attributes of the offer, categorize the offer, and scan
the bid rules to determine which of the GVR's bid rules match the
attributes and/or categories. The matching bid rule (or the highest
priority matching bid rule in the case where there are multiple
matching bid rules) may then be used to set an advertising rate for
the new voucher offer.
[0084] Depending on the embodiment, the bid amount may be absolute
such that the bid amount is used in place of a base CPC rate
defined in the rate card, or the bid amount may be relative such
that the bid amount is used to modify the base CPC rate defined in
the rate card by the bid amount.
[0085] All of the methods and tasks described herein may be
performed and fully automated by a computer system. The computer
system may in some cases include multiple distinct computers or
computing devices (e.g., physical servers, workstations, storage
arrays, etc.) that communicate and interoperate over a network to
perform the described functions. Each such computing devices
typically includes a processor (or multiple processors) that
executes program instructions or modules stored in a memory or
other non-transitory computer-readable storage medium. The various
functions disclosed herein may be embodied in such program
instructions, although some or all of the disclosed functions may
alternatively be implemented in application-specific circuitry
(e.g., ASICs or FPGAs) of the computer system. Where the computer
system includes multiple computing devices, these devices may, but
need not, be co-located. The results of the disclosed methods and
tasks may be persistently stored by transforming physical storage
devices such as solid state memory chips and/or magnetic disks,
into a different state.
[0086] The foregoing description details certain embodiments of the
invention. It will be appreciated, however, that no matter how
detailed the foregoing appears in text, the invention can be
practiced in many ways. It should be noted that the use of
particular terminology when describing certain features or aspects
of the invention should not be taken to imply that the terminology
is being re-defined herein to be restricted to including any
specific characteristics of the features or aspects of the
invention with which that terminology is associated. The scope of
the invention should therefore be construed in accordance with the
appended claims and any equivalents thereof.
* * * * *