Microsoft KB Archive/246542

From BetaArchive Wiki

Article ID: 246542

Article Last Modified on 4/22/2003


  • Microsoft Site Server 3.0 Commerce Edition

This article was previously published under Q246542

IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry


This article explains the following:

  • How ads are selected.
  • How to modify the selection criteria.
  • How to solve ad delivery problems.
  • Which registry entries are used in the ad selection process.


The Ad Server component of Site Server 3.0 Commerce Edition employs a simple scoring and selection algorithm. Central to the algorithm is the concept of a "score" for each ad, which is a single-precision floating-point number. Each active ad on schedule is given a base (initial) score, various modifications (multipliers) are applied to the score, and at the end of the process, the ad with the highest score is selected. In the case of a tie, an ad is randomly selected from among those ads with the same score.

Base Score of House and Paid Ads

Ad Server supports two types of ads: house ads and paid ads. The distinction between them is that paid ads have goals (a given number of impressions or clicks or other events to serve within a given time period) but house ads do not. Both types of ads go through the same scoring and selection process, but the base score is computed differently for each. For house ads, the base score is fixed (it is configurable through a registry setting). For paid ads, the base score is computed using a formula that takes into account how the ad is performing against its goals over time. The score uses 1.0 as the base line.

Therefore, a paid ad that is behind on its goals is given a base score greater than 1.0, and an ad that is ahead of its goals is given a base score less than 1.0. The farther ahead or behind schedule the ad is, the greater the deviation is from the 1.0 baseline. For example, an ad that is two times ahead of its schedule is given a base score of 0.5. Conversely, one that is two times behind is given a base score of 2.0.

Scoring and Selection Process

When the Ad Server component loads the ad schedule from the Microsoft SQL Server database, it only loads ads that are currently active (that is, for which ad_start_date <= Now <= ad_end_date) and the active flag is True. Then, the time of day and day of week filters are applied, based on the server's clock time. The remaining ads are scored using the following heuristics:

  1. Compute the base score. For house ads, the base score is fixed (default=0.95). For paid ads, this is based on the following need of delivery (NOD) formula:

    NOD=(events_remaining/time remaining)/(events_scheduled/time_total)
  2. Apply the size filter. If an ad.size=xxx tag is passed in the taglist parameter to the GetAd method, then ads that are not of the specified size are eliminated (score=0.0).
  3. Apply the reselect penalty and exposure limit. This is where the history string parameter of the GetAd method comes into play. The last n ads in the history string are penalized to avoid having the same ad be repeatedly selected for the same user. The number of ads penalized, n, is configurable in the registry, as is the multiplier used to penalize the ads. Exposure limits (the number of times an ad may be shown to the same user) can be set for an ad in the Ad Manager. If the ad has reached its exposure limit, then the ad is disqualified (score=0.0).

    NOTE: The maximum length of the history string is also configurable in the registry.
  4. Apply the targeting rules (tag matching). Tags passed in from the taglist are compared against targeting tags that were specified in Ad Manager. Each target tag specified in Ad Manager has an associated action: target, require, or exclude. The result of the targeting process is that for each targeting tag specified for the ad, a multiplier will be applied. The multipliers can be configured in the registry. The following table shows the defaults configured when Site Server Commerce Edition 3.0 is installed.

    Action Multiplier When Tags Match Multiplier When Tags Do Not Match
    Target 1.10 0.95 (See NOTE below.)
    Require 1.15 0.0
    Exclude 0.0 1.0
    NOTE: The PenalizeMismatchedTargets property affects the "no match" multiplier for the Target action. The default is True and corresponds to a (default) multiplier of 0.95; when set to False, the value is always 1.0, meaning that the ad's score is not affected if the tag is not matched.

How the Target Action Works

The way the Target action works is unique to the Microsoft Ad Server. It's a "fuzzy" operation rather than a filter like the Require action. Most Web sites would like to support demographic targeting but do not have a high enough percentage of survey results on their user base to reliably use this feature. In order to address the shortfall of demographic data but still support the ability of sites to offer rich targeting associated with demographics, Microsoft has developed this fuzzy targeting feature.

For example, say 10 percent of your user population has supplied you with their gender information and you have 30,000 visitors per day. That would mean you could sell 3,000 ads based on gender, or with a 50% distribution, 1,500 males or 1,500 females. Say an advertiser wants to place an order for 2,000 ad requests in a day. The product being advertised is targeted mainly to males. Since you only know for sure that 1,500 visitors in a day are male, you can't use the Require action to target males. If you did, the ad would fall short of its goal of 2,000 ad requests in the day. Instead, you schedule the ad to "target" males and "exclude" females. Now when a known male visitor hits the site, the score for the targeted ad is boosted and it's quite likely to be selected. If a known female hits the site, the ad is disqualified by the exclusion.

But when a visitor of unknown gender hits the site, the ad's score is decreased by the 0.95 multiplier (unless you have set the PenalizeUnmatchedTargets property to False). However, over time the ad starts starving for males (after all, you only have 1,500 of the 2,000 scheduled requests), so the ad's base score (using NOD) starts rising. Soon the NOD will overtake the action of the penalty and the ad will be delivered to persons of unknown gender, so that it doesn't fall short of its goals.

The result is that all or nearly all of the 1500 males are shown the ad, with the other 500 impressions going to persons of unknown gender. The tags passed to the Ad Server are logged in the URI Query field in the Internet Information Server (IIS) log file, along with the IDs of the ads selected on the page, so an analysis can be made of exactly how many of the ads were shown to males.

Diagnosing Ad Delivery Problems

The first place to look when you have a problem is the Application Event Log. Ad Server logs warnings and fatal errors here.

The DumpSchedule method on the Ad Server component is useful for showing the set of ads that are currently loaded into memory and the current values of various parameters for the ad. The easiest way to use this method is to copy the Dump.asp file from the AdSamples virtual directory (an installation option in Site Server Commerce Edition 3.0) into the IIS virtual directory where Ad Server is running. The NOD column displays each ad's base score, or need of delivery.

A common problem encountered when using Ad Server is that the same ad or set of ads is being selected, but other ads are not being selected at all. Ad Server 1.0 was optimized to run in the case where the inventory of ad requests (number of page views where GetAd is called) is greater than or equal to the number of ad requests scheduled in Ad Manager during the same time period. House ads should be scheduled so that they can be "mixed in" more often as the paid ads get ahead of their goals.

How to Determine When an Ad Schedule is Oversold (Runaway Schedule)

An ad schedule that is oversold can be detected when the data returned by DumpSchedule shows that all or most of the ads have an NOD greater than 1.0 and the house ads are not being shown. In this situation, the ad that has the most ad requests or clicks scheduled will be served more often (or even exclusively) than ads with lower goals. This situation is called a "runaway schedule."

Compensating for a Runaway Schedule

In order to solve this problem, you must either decrease or push out the timeline for the paid ad schedule until the house ads begin to show. Use Site Server's analysis tool or other reporting packages to ensure that you have not oversold your inventory.

NOTE: A common mistake is to incorrectly use the "ad requests" column as a weight and therefore enter numbers much larger than the inventory of ad requests that are available. Ad Server 1.0 does not oblige and will exclusively serve the ad with the highest "ad requests" value, because it is farthest behind on its goals.

Ad Shown Repeatedly When History String Not Used

Another cause of one ad being shown repeatedly to the same user is failure to use the history string parameter of the GetAd method. Without the history of ads a user has already seen, the Ad Server cannot know that it has recently shown an ad to the user. The Ad Server will continue to show the same high-scoring ad over and over. The common means of storing the history string are the ASP session collection, HTTP cookies, Site Server 3.0 Personalization and Membership, and SQL Server database tables. The storage and retrieval of the history string must be implemented by an ASP developer on the page where the ad call is made. The History.asp file in the AdSample virtual directory shows how to do this using the ASP session.

Use Ad Server Logging to Analyze Tags

It may be helpful when diagnosing targeting problems to analyze the tags logged by the Ad Server component in the IIS log file. Make sure that QueryString logging is enabled so that this information is recorded.

Registry Settings

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

The following registry settings are under the key HKLM\SOFTWARE\MICROSOFT\SITE SERVER\3.0\ADSERVER.

Value Description Default setting
ExposureListSize The maximum length the history string is allowed to grow to, in ad IDs. 25
ReselectLookback When applying the reselect penalty, the number of ads at the end of the history string that should be penalized. 5
ReselectPenalty Penalty applied to the last ReselectLookback items in the history string. 50 (0.50)
EndOfrunBoost Boost applied to the ad's score in the last 20 percent of the run or one day, whichever is smaller (in hundredths). 110 (1.10)
HouseAdNeedOfDelivery Base score for house ads (in hundredths). 95 (0.95)
TargetMatchMultiplier Multiplier for "target" match. 110 (1.1)
TargetNoMatchMultiplier Multiplier for "target" miss. 95 (0.95)
RequireMatchMultiplier Multiplier for "require" match. 115 (1.15)
RequireNoMatchMultiplier Multiplier for "require" miss. 0 (0.0)
ExcludeMatchMultiplier Multiplier for "exclude" match. 0 (0.0)
ExcludeNoMatchMultiplier Multiplier for "exclude" mismatch. 100 (1.0)

Additional query words: ssce ss3ce original score advertisement advertisements

Keywords: kbhowto KB246542