Comparing data in two consecutive rows from a single table

[Greg D. Moore \(Strider\)]

Re: Comparing data in two consecutive rows from a single table


"--CELKO--" <jcelko212@eart hlink.net> wrote in message
news:18c7b3c2.0 406041125.3cd71 4a7@posting.goo gle.com...[color=blue][color=green][color=darkred]
> >> Serving them has no duration, no. And we serve (and record the[/color][/color]
> serving) of over 14 million banner ads a day. <<
>
> Perhaps I do not understand what "serving" means; can you give me a
> scenario. I am a customer; I want to run a banner ad. My banner
> needs to be up from Christmas to New Years day. It needs to run
> between 0600 UTC to 1200 UTC everyday, and it is 5 seconds long. What
> are you recording so that I get the exposure for which I am paying?[/color]

Banners don't have a duration. (Well, active content do, but let's come
back to that.).

So, given the criteria you've given, we'd charge you probably (and this
varies but for this we simplify) on number of impressions. I.e the number
of times it's been served.

So an end user goes to a page on our site. The code (generally ASP) goes to
a DB table and queries "what banner should I show." (there may be more than
one scheduled for say the top position on the page). A "coin flip" is made
and the DB hands back a URL to the banner in question. At that point it
records in the database that your banner was served.

Now, the end user may spend 10 seconds at that page or 10 minutes. At that
point we don't really care (and have limited ways of knowing anyway since
the web is generally stateless). You're not paying for that, you're paying
for impressions served.

Now, a standard banner is generally just a gif file, or perhaps an animated
gif. Active content may be fancier, like a flash ad (yuck) or Quicktime,
etc. But again, we don't record any of that, simply the time that the
banner was handed to the user.

This is fairly standard in terms of how banner ads are served. So, no
duration, simply an impression.

[--CELKO--]

Re: Comparing data in two consecutive rows from a single table

>> Banners don't have a duration. (Well, active content do, but let's
come
back to that.) <<

Isn't that content and its duration what the buyer is paying for?
[color=blue][color=green]
>> we'd charge you probably on number of impressions. I.e the number[/color][/color]
of times it's been served. <<

I understand billing by the number of hits. But if you can put 1000
impressions of my ad in banner in one minute, I am not as happy as I
would be having them spaced out and retained at lest long enough for a
human being to read. When I record the hits, I record them in a time
slot -- you can only hit the banner when it is displayed.
[color=blue][color=green]
>> So an end user goes to a page on our site. The code (generally[/color][/color]
ASP) goes to
a DB table and queries "what banner should I show." A "coin flip" is
made
and the DB hands back a URL to the banner in question. At that point
it
records in the database that your banner was served. Now, the end
user may spend 10 seconds at that page or 10 minutes. <<

At that point, I don't care; the user has left the banner and is in
the target URL. I then have to model his URL behavior in a new set of
tables.

But has happened back at the banner, which is what I was modeling? I
hope the banner was there for a duration greater than zero time units.
When my time slot of duration (t1) was used up, can I assume another
banner got a time slot of (t2) in that banner? You do not "machine
gun" banners so fast that they are not readable.

What you are saying is that "the half of the fact" you see is like a
shipping clerk -- packages only leave in his world view. Likewise a
receiving clerk only sees packages arriving in his world view. But
the whole fact is that package makes a trip that takes time until it
arrives someplace (or is declared lost in transit). The correct model
is global, not local.

[Greg D. Moore \(Strider\)]

Re: Comparing data in two consecutive rows from a single table


"--CELKO--" <jcelko212@eart hlink.net> wrote in message
news:18c7b3c2.0 406051347.6cd6a 377@posting.goo gle.com...[color=blue][color=green][color=darkred]
> >> Banners don't have a duration. (Well, active content do, but let's[/color][/color]
> come
> back to that.) <<
>
> Isn't that content and its duration what the buyer is paying for?[/color]

No, since duration can't be measured via the web since it's stateless.

[color=blue]
>[color=green][color=darkred]
> >> we'd charge you probably on number of impressions. I.e the number[/color][/color]
> of times it's been served. <<
>
> I understand billing by the number of hits. But if you can put 1000
> impressions of my ad in banner in one minute, I am not as happy as I
> would be having them spaced out and retained at lest long enough for a
> human being to read. When I record the hits, I record them in a time
> slot -- you can only hit the banner when it is displayed.[/color]


Because that's all we can know.
[color=blue]
>
> But has happened back at the banner, which is what I was modeling? I
> hope the banner was there for a duration greater than zero time units.
> When my time slot of duration (t1) was used up, can I assume another
> banner got a time slot of (t2) in that banner? You do not "machine
> gun" banners so fast that they are not readable.
>[/color]

Banners are delivered as often as the clicks the page. If they go to a
page, read the page, walk away and come back 3 weeks later, the same banner
is still displayed. If they go to a page, quickly see it's not what they
want and click a link to another page, then they'll get a different banner.

You may HOPE the banner was there for duration greater than zero time units,
but generally the web doesn't work that way.

[color=blue]
> What you are saying is that "the half of the fact" you see is like a
> shipping clerk -- packages only leave in his world view. Likewise a
> receiving clerk only sees packages arriving in his world view. But
> the whole fact is that package makes a trip that takes time until it
> arrives someplace (or is declared lost in transit). The correct model
> is global, not local.[/color]

No it's not. That may be what you want it to be, but that's not the way
banner traffic works.

[Erland Sommarskog]

Re: Comparing data in two consecutive rows from a single table

Greg D. Moore (Strider) (mooregr_delete th1s@greenms.co m) writes:[color=blue]
> So an end user goes to a page on our site. The code (generally ASP)
> goes to a DB table and queries "what banner should I show." (there may
> be more than one scheduled for say the top position on the page). A
> "coin flip" is made and the DB hands back a URL to the banner in
> question. At that point it records in the database that your banner was
> served.[/color]

But, of course, at my end, I am running a banner-filter proxy, so I never
see the bastard anyway. :-)



--
Erland Sommarskog, SQL Server MVP, esquel@sommarsk og.se

Books Online for SQL Server SP3 at

http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[--CELKO--]

Re: Comparing data in two consecutive rows from a single table

>> Banners are delivered as often as the clicks the page. If they go
to a page, read the page, walk away and come back 3 weeks later, the
same banner is still displayed. If they go to a page, quickly see
it's not what they want and click a link to another page, then they'll
get a different banner. <<

I would make a big distiction between the banner (the thing that leads
to my Christmas sale) and the image of the banner that has presisted
for weeks after the holidays in the local storage of a particular
machine. My contract was for a duration (Christmas season) and was
with the website that offered to run my banner. They were to display
from one date to another. If it got clicked (n) times between
December 01 and December 25, then I owe them according to some
formula. Maybe if the click leads to sale between December 01 and
December 25, then I owe them according to another formula. But
outside that (possibly open ended) duration, there is no obligation.

Years ago in Los Angeles, I worked on a data model for a cable TV
shopping network for a major department store chain. This was even
worse because each time a commerical played, we had to compute the
actor's residuals, the assorted union pay rates, and how to credit the
purchase to the nearest local store, and the right department within
that store. Arrgh!

[Greg D. Moore \(Strider\)]

Re: Comparing data in two consecutive rows from a single table


"--CELKO--" <jcelko212@eart hlink.net> wrote in message
news:18c7b3c2.0 406061538.50f3c fbf@posting.goo gle.com...[color=blue][color=green][color=darkred]
> >> Banners are delivered as often as the clicks the page. If they go[/color][/color]
> to a page, read the page, walk away and come back 3 weeks later, the
> same banner is still displayed. If they go to a page, quickly see
> it's not what they want and click a link to another page, then they'll
> get a different banner. <<
>
> I would make a big distiction between the banner (the thing that leads
> to my Christmas sale) and the image of the banner that has presisted
> for weeks after the holidays in the local storage of a particular
> machine.[/color]

You might, but that's irrelevant. I'm discussing what the viewer sees on
the screen.
[color=blue]
> My contract was for a duration (Christmas season) and was
> with the website that offered to run my banner. They were to display
> from one date to another. If it got clicked (n) times between
> December 01 and December 25, then I owe them according to some
> formula. Maybe if the click leads to sale between December 01 and
> December 25, then I owe them according to another formula. But
> outside that (possibly open ended) duration, there is no obligation.[/color]

You're discussing the contract, I'm discussing the serving, those are two
distinct tiems.

Ask them how long each individual banner was displayed on an end-user's
system (the "duration" as you're referring to it.) They can't do it. (and
if they claim they can, they are most likely fudging some of the data).

[color=blue]
>
> Years ago in Los Angeles, I worked on a data model for a cable TV
> shopping network for a major department store chain. This was even
> worse because each time a commerical played, we had to compute the
> actor's residuals, the assorted union pay rates, and how to credit the
> purchase to the nearest local store, and the right department within
> that store. Arrgh![/color]

Years ago I was involved as a sub-contractor (big mistake) on a system for a
major network who shall remain nameless. System was to handle the
scheduling of commercials on the network and had to deal with all sorts of
items such as regional variations within a broadcast (might show snow-tire
commercials up north while showing a vacation commercial down south.) At
that time I wasn't too involved with the schema, but more so the hardware.
It was an interesting situation trying to deal with handling things like
failures and having to predict the required hardware for a reload (forget
the number of transactions that would have to occur in 10 minutes but at the
time, it was a fairly impressive number. Of course the contractor I was
working for kept saying, "Oh, don't worry, the hardware can handle it." I
was the one that kept saying, "no, we have to model this." (generally I've
got enough faith in "gut instinct" I can model some systems in my head, this
was definitely not one of them.)

Anyway, I just thought of a good distinct here.

Whereas things like commercials have a fixed run time, etc. serving banners
is more like blow-ins in the newspaper. You contract for a specific number
over a specific time, but generally don't care about the exact time the
blow-in is blown-in (and can't model when the reader actually reads it or
tosses it in the trash.)

Yes, the contract has a duration which is critical to model (i.e. when to
start serving, stop serving) but the individual serving is only an
"instant."

[-P-]

Re: Comparing data in two consecutive rows from a single table

"Greg D. Moore (Strider)" <mooregr_delete th1s@greenms.co m> wrote in message
news:dS8wc.5276 9$j24.31693@twi ster.nyroc.rr.c om...[color=blue]
>
> "--CELKO--" <jcelko212@eart hlink.net> wrote in message
> news:18c7b3c2.0 406041125.3cd71 4a7@posting.goo gle.com...[color=green][color=darkred]
> > >> Serving them has no duration, no. And we serve (and record the[/color]
> > serving) of over 14 million banner ads a day. <<
> >[/color][/color]

<snip>
[color=blue]
> Banners don't have a duration. (Well, active content do, but let's come
> back to that.).
>
> So, given the criteria you've given, we'd charge you probably (and this
> varies but for this we simplify) on number of impressions. I.e the number
> of times it's been served.
>
> So an end user goes to a page on our site. The code (generally ASP) goes to
> a DB table and queries "what banner should I show." (there may be more than
> one scheduled for say the top position on the page). A "coin flip" is made
> and the DB hands back a URL to the banner in question. At that point it
> records in the database that your banner was served.
>[/color]


Sounds like a Traffic system to me... ;)
We do the same thing for Television advertising. We should talk...

--
Paul Horan
Sr. Architect
Video Communications, Inc.

https://www.vcisolutions.com

[-P-]

Re: Comparing data in two consecutive rows from a single table

Joe,
I think what you're missing in this discussion is the distinction between the ORDER for an impression and the audit
trail of the DELIVERY of that impression.

Both Greg and I work in the Advertising "Traffic" business. Our respective software products are basically Order
Fulfillment processes - my company writes Traffic software for television stations, and Greg's company works in the
internet medium.

The attributes of an Order most definitely DO contain "duration" - both a start_date/end_date duration (so that you
don't run Christmas special ads in February - we call those discrete periods of time a "flight"), as well as two columns
for storing the start/end time within which the spot should "air". Some advertisers only want their spots to be seen in
"prime time", for example...

Our TV clients are also concerned with the duration of the spot itself. Is this a regular :30 second spot? a :15? a
28:30 infomercial? Greg's clients don't have that concept - but I'm sure they do have X/Y and width/height parameters.
Once the HTML is rendered and delivered to the browser, that is officially recorded as one "impression " that happened at
a specific nanosecond in time.

We collect the order "parameters " as attributes of the Order entity itself. Then comes the process of matching up
Orders and available "Inventory" , and delivering the content. We print out a daily program log so Master Control knows
which commercials to air in what order, and Greg serves up links to banner ads in "real-time". All that's left is the
recording of that delivery, so that the advertisers (or ad agencies) can pay their bills.

--
Paul Horan[TeamSybase]

"--CELKO--" <jcelko212@eart hlink.net> wrote in message news:18c7b3c2.0 406061538.50f3c fbf@posting.goo gle.com...[color=blue][color=green][color=darkred]
> >> Banners are delivered as often as the clicks the page. If they go[/color][/color]
> to a page, read the page, walk away and come back 3 weeks later, the
> same banner is still displayed. If they go to a page, quickly see
> it's not what they want and click a link to another page, then they'll
> get a different banner. <<
>
> I would make a big distiction between the banner (the thing that leads
> to my Christmas sale) and the image of the banner that has presisted
> for weeks after the holidays in the local storage of a particular
> machine. My contract was for a duration (Christmas season) and was
> with the website that offered to run my banner. They were to display
> from one date to another. If it got clicked (n) times between
> December 01 and December 25, then I owe them according to some
> formula. Maybe if the click leads to sale between December 01 and
> December 25, then I owe them according to another formula. But
> outside that (possibly open ended) duration, there is no obligation.
>
> Years ago in Los Angeles, I worked on a data model for a cable TV
> shopping network for a major department store chain. This was even
> worse because each time a commerical played, we had to compute the
> actor's residuals, the assorted union pay rates, and how to credit the
> purchase to the nearest local store, and the right department within
> that store. Arrgh![/color]