Re: Ad serving discrepancies

From: Allen Wyke <allen_wyke_at_engage.com>
Date: Thu 05 Oct 2000 15:51:06 -0500

Another overall thing to remember here is that counting
ads from a third party is completely different that
what you expect to see on your own site with an
analytical tool like a Webtrends. And this does not
mean something is wrong. Trying to make these numbers
line up simply will not happen - you are comparing
apples to oranges. Here is a quick example to help
explain this issue that we are all feeling in the
industry right now.

Lets say your site serves a page that has a single ad
call on it, like an <img> tag pointing to a third party
ad server. When the browser requests this page the web
server will return it along with HTTP header
directives. These directives, which are items you never
see in browsers, tell the browser things like what type
of information is being returned (HTML, text, image,
etc.) and important to this discussion, when it expires
or any cache control directives. When the browser gets
this page it is *suppose* to store this information
along with the content (ie: page1.html expires in 10
days).

Next the browser goes out and grabs the rest of the
elements that make up the content on the page. In
short, it goes and gets everything specified using the
src attribute of an HTML tag. Like <img src=...>,
<iframe src=....>, <script src=...>, etc. Here is where
the 3rd party comes in. What the 3rd party returns has
HTTP directives as well, and is something that you do
not generally want to cache because you want as many
impressions as you can get. So, if you look at the HTTP
header directives (there are programs that let you do
this) for these 3rd parties, you will see short
expirations (5 minutes) or other cache control
directives (like no-cache) -- all to maximize your
number of impressions.

Now, today's browsers do not always play correctly. In
fact, I am sure that any of you using IE 5 or 5.5 have
noticed that when you hit the back button the page
loads really fast and it often has the same ads.
Technically, following the HTTP specification, it
should not do this. The browser is suppose to verify
the user's requested page with what it has in cache (if
it has it), then send the server a request to see if
anything has changed. It is like saying, "please send
me someimage.gif if it is newer than <insert date
here>". At that time the server can send back a
response saying nothing has changed, or it can send
back the new piece of content. This is why you can make
changes to your site and see them immediately on the
Web. But at the same time, if your HTTP headers are
configured incorrectly or if you have overridden the
headers by changing the browser defaults, you may see
the old content. This is fun, huh?

My whole point here is that things are different and
they should be. From your website's perspective, you
want to cache as much as you can without having old
data on the browser and at proxies (they are generally
located at ISPs and are "big caches"). This means your
site will appear to be faster to the user. For ads,
however, you do not want to cache the initial request
because you want to maximize your ad space.

I don't want to go way overboard here, so I will stop.
But if you get this part, you are half way there.
Unfortunately, there is another half that gets into the
technical details of which headers are better than
others, are browsers doing what they are suppose to be,
where you count, and how do you count. This is where
you will hear things like "counting insertions instead
of impressions" or "counting 302 redirects versus
images served". I work for Engage and have for
sometime, so I know what we do. Additionally, I have
worked first hand with some of DoubleClick's technical
people in Europe, so I know what they do as well (which
is different).

The real issue is that no one in the industry has
started a group to standardize this type of thing so
that we can all get on the same page. And to be honest,
this is something that should be driven by the
publisher or advertiser, not the ad companies (ie: Ford
doesn't set speed limits - they enable their vehicles
to comply with them, but it is still the owner's
responsibility).

If you want more information, I can certainly provide
it. I am all to aware of the issues here.

Allen

Director, Product Technology
awyke_at_engage.com
Engage Software
3020 Highwoods Blvd. 919.719.4603
Raleigh, NC 27604 ICQ#: 27822748





Received on Thu Oct 05 2000 - 15:51:06 CDT