As described earlier, when we receive a request to target an ad, we’re generally looking
to find the highest eCPM ad that matches the viewer’s location. In addition to
matching an ad based on a location, we’ll gather and use statistics about how the content
of a page matches the content of an ad, and what that can do to affect the ad’s
CTR. Using these statistics, content in an ad that matches a web page can result in
bonuses that contribute to the calculated eCPM of CPC and CPA ads, which can result
in those types of ads being shown more.
Before showing any ads, we won’t have any bonus scoring for any of our web page
content. But as we show ads, we’ll learn about what terms in the ads help or hurt the
ad’s expected performance, which will allow us to change the relative value of each of
the optional targeting terms.
To execute the targeting, we’ll union all of the relevant location SETs to produce an
initial group of ads that should be shown to the viewer. Then we’ll parse the content of
the page on which the ad will be shown, add any relevant bonuses, and finally calculate
a total eCPM for all ads that a viewer could be shown. After we’ve calculated those
eCPMs, we’ll fetch the ad ID for the highest eCPM ad, record some statistics about our
targeting, and return the ad itself. Our code for targeting an ad looks like this.
In this first version, we hide away the details of exactly how we’re matching based on
location and adding bonuses based on terms so that we can understand the general
flow. The only part I didn’t mention earlier is that we’ll also generate a target ID, which
is an ID that represents this particular execution of the ad targeting. This ID will allow
us to track clicks later, helping us learn about which parts of the ad targeting may have
contributed to the overall total clicks.
As mentioned earlier, in order to match based on location, we’ll perform a SET
union over the locations (city, state, country) that the viewer is coming from. While
we’re here, we’ll also calculate the base eCPM of these ads without any bonuses
applied. The code for performing this operation is shown next.
This code listing does exactly what I said it would do: it finds ads that match the location
of the viewer, and it calculates the eCPM of all of those ads without any bonuses
based on page content applied. The only thing that may be surprising about this listing
is our passing of the funny _execute keyword argument to the zintersect()
function, which delays the actual execution of calculating the eCPM of the ad until
later. The purpose of waiting until later is to help minimize the number of round trips
between our client and Redis.
The interesting part of targeting isn’t the location matching; it’s calculating the
bonuses. We’re trying to discover the amount to add to an ad’s eCPM, based on words
in the page content that matched words in the ad. We’ll assume that we’ve precalculated
a bonus for each word in each ad (as part of the learning phase), stored in ZSETs for each
word, with members being ad IDs and scores being what should be added to the eCPM.
These word-based, per-ad eCPM bonuses have values such that the average eCPM of
the ad, when shown on a page with that word, is the eCPM bonus from the word plus
the known average CPM for the ad. Unfortunately, when more than one word in an ad matches the content of the page, adding all of the eCPM bonuses gives us a total eCPM
bonus that probably isn’t close to reality.
We have eCPM bonuses based on word matching for each word that are based on
single word matching page content alone, or with any one or a number of other words
in the ad. What we really want to find is the weighted average of the eCPMs, where the
weight of each word is the number of times the word matched the page content.
Unfortunately, we can’t perform the weighted average calculation with Redis ZSETs,
because we can’t divide one ZSET by another.
Numerically speaking, the weighted average lies between the geometric average
and the arithmetic average, both of which would be reasonable estimates of the combined
eCPM. But we can’t calculate either of those averages when the count of matching
words varies. The best estimate of the ad’s true eCPM is to find the maximum and
minimum bonuses, calculate the average of those two, and use that as the bonus for
multiple matching words.
BEING MATHEMATICALLY RIGOROUSMathematically speaking, our method of
averaging the maximum and minimum word bonuses to determine an overall
bonus isn’t rigorous. The true mathematical expectation of the eCPM with a
collection of matched words is different than what we calculated. We chose to
use this mathematically nonrigorous method because it gets us to a reasonable
answer (the weighted average of the words is between the minimum and
maximum), with relatively little work. If you choose to use this bonus method
along with our later learning methods, remember that there are better ways
to target ads and to learn from user behavior. I chose this method because it’s
easy to write, easy to learn, and easy to improve.
We can calculate the maximum and minimum bonuses by using ZUNIONSTOREwith the
MAX and MIN aggregates. And we can calculate their average by using them as part of a
ZUNIONSTOREoperation with an aggregate of SUM, and their weights each being .5. Our
function for combining bonus word eCPMs with the base eCPM of the ad can be seen
in the next listing.
As before, we continue to pass the _execute parameter to delay execution of our various
ZINTERSTORE and ZUNIONSTOREoperations until after the function returns to the
calling target_ads(). One thing that may be confusing is our use of ZINTERSTORE
between the location-targeted ads and the bonuses, followed by a final ZUNIONSTORE
call. Though we could perform fewer calls by performing a ZUNIONSTOREover all of
our bonus ZSETs, followed by a single ZINTERSTORE call at the end (to match location),
the majority of ad-targeting calls will perform better by performing many
smaller intersections followed by a union.
The difference between the two methods is illustrated in figure 7.5, which shows
that essentially all of the data in all of the relevant word bonus ZSETs is examined
when we union and then intersect. Compare that with figure 7.6, which shows that
when we intersect and then union, Redis will examine far less data to produce the
After we have an ad targeted, we’re given a target_id and an ad_id. These IDs
would then be used to construct an ad response that includes both pieces of information,
in addition to fetching the ad copy, formatting the result, and returning the
result to the web page or client that requested it.
If you pay careful attention to the flow of target_ads() through finish_scoring()
in listings 7.11 and 7.13, you’ll notice that we don’t make any effort to deal with the
case where an ad has zero matched words in the content. In that situation, the
eCPM produced will actually be the average eCPM over all calls that returned that ad
itself. It’s not difficult to see that this may result in an ad being shown that
shouldn’t. Can you alter finish_scoring() to take into consideration ads that
don’t match any content?
The only part of our target_ads() function from listing 7.11 that we haven’t defined
is record_targeting_result(), which we’ll now examine as part of the learning
phase of ad targeting.
4 It may seem strange to be estimating an expectation (which is arguably an estimate), but everything about
targeting ads is fundamentally predicated on statistics of one kind or another. This is one of those cases where
the basics can get us pretty far.