Ad Rotator structure

[byersa]

Has there been any work done on an ad rotator service?

If not, I think I would like to build off of the subscription model.
I would create virtual products with different variants for impression
counts (eg. 1k, 5k, etc) per month (or time period).
I would not link Product to SubscriptionResource via
ProductSubscriptionResource because I want to reuse the same product for
different customers and I can't have static content (ie. ad images) tied to
a product.

I want to use Subscriptions so that I have a persistent object to tie
Content entities to. I would use the ShoppingList to handle recurring
billing - which generates a new order on each cycle. I want to use the
subscription model because there will be functionality to handle commissions
and billing - but those things are not really tied to Subscription, but it
seems that there would be some common elements.

So I think I will need a new entity, AdContentHit, that would provide a sort
of de-normalized record for both capturing the ads tied to a user and
managing their delivery.

AdContentHit
 - subscriptionId
 - subscriptionSeqId
 - contentId
 - imageUrl - a quick way to deliver the image, rather than going thru the
contentId. Would need to get modified if the content location changed
 - currentQuota - number of impressions scheduled for the month (or time
period)
 - currentHits - number of impressions delivered within month or time period
 - deliveryRate - i am thinking about indexing this field and using it to
find the next image to deliver. It would be the currentQuota / currentHits
if currentHits is > 0
                                or just equal to currentQuota if currentHits
== 0. This formula seems like it would work even if you go over your quota -
which will certainly happen.
                        Okay, I see where this will not work unless all
currentHits get zeroed out each night and currentQuota is for a 24 hour
period - so that all ads are on the same point
                         of reference. There is probably a better way to do
this. Have not looked at it much. Hoping for some suggestions.
 - fromDate
 - thruDate
 - totalHits
 - imageSize (medallion, banner, etc)

These are just some initial thoughts. Anyone out there have some knowledge
to share?

Thanks,

Al

[byersa]

Shi,

Thanks for the feedback. So in your case the products would be ad positions,
whereas, I was thinking they would be count packages (eg. 1K, 2K, etc). In
your case, you would just make the impression count the order quantity
listed for that package in the OrderItem record? That sounds like it would
work. We could use promotions to put together special packages. Thanks for
bringing up the point that people want to buy ad positions - I had not
thought of that. I don't have much experience with this. I guess there are
other conditions buyers will want to specify - what would they be? Of
course, we want to be able to tie ads to the user profile if they are logged
in - we should be talking about how those facts will be stored.

Your comments don't deal with how the ad images are tied in, do they? Any
thoughts there?

I will want the ad content to be rendered on the front end via the screen
widget code. It may require some changes in the content management package
to go straight to content. My thought is to use the CMS to place images in
the file system where they can be accessed directly via the web server or
via the CMS.

-Al

On 12/30/06, Shi Yusen <[hidden email]> wrote:

>
> Hi Al,
>
> I don't know why I can't send this to the list, so I send it to you
> directly.
>
> I think it would be better if the ad positions can be listed as products
> in a
> special catalog.
>
> A customer can order an ad position and assign the ad type such as
> image, flash and etc. and from date, thru date.
>
> In the frontend, just insert some javascript code as Google did.
>
> Is this possible?
>
> Shi Yusen/Beijing Langhua Ltd.
>
>
> 在 2006-12-30六的 10:56 -0700，Al Byers写道：
> > Has there been any work done on an ad rotator service?
> >
> > If not, I think I would like to build off of the subscription model.
> > I would create virtual products with different variants for impression
> > counts (eg. 1k, 5k, etc) per month (or time period).
> > I would not link Product to SubscriptionResource via
> > ProductSubscriptionResource because I want to reuse the same product for
> > different customers and I can't have static content (ie. ad images) tied
> to
> > a product.
> >
> > I want to use Subscriptions so that I have a persistent object to tie
> > Content entities to. I would use the ShoppingList to handle recurring
> > billing - which generates a new order on each cycle. I want to use the
> > subscription model because there will be functionality to handle
> commissions
> > and billing - but those things are not really tied to Subscription, but
> it
> > seems that there would be some common elements.
> >
> > So I think I will need a new entity, AdContentHit, that would provide a
> sort
> > of de-normalized record for both capturing the ads tied to a user and
> > managing their delivery.
> >
> > AdContentHit
> >  - subscriptionId
> >  - subscriptionSeqId
> >  - contentId
> >  - imageUrl - a quick way to deliver the image, rather than going thru
> the
> > contentId. Would need to get modified if the content location changed
> >  - currentQuota - number of impressions scheduled for the month (or time
> > period)
> >  - currentHits - number of impressions delivered within month or time
> period
> >  - deliveryRate - i am thinking about indexing this field and using it
> to
> > find the next image to deliver. It would be the currentQuota /
> currentHits
> > if currentHits is > 0
> >                                 or just equal to currentQuota if
> currentHits
> > == 0. This formula seems like it would work even if you go over your
> quota -
> > which will certainly happen.
> >                         Okay, I see where this will not work unless all
> > currentHits get zeroed out each night and currentQuota is for a 24 hour
> > period - so that all ads are on the same point
> >                          of reference. There is probably a better way to
> do
> > this. Have not looked at it much. Hoping for some suggestions.
> >  - fromDate
> >  - thruDate
> >  - totalHits
> >  - imageSize (medallion, banner, etc)
> >
> > These are just some initial thoughts. Anyone out there have some
> knowledge
> > to share?
> >
> > Thanks,
> >
> > Al
>
>

[David E Jones-2]

Al,

Could you describe more background or requirements for what you're  
trying to do? It sounds like your emphasis is on providing an  
ecommerce like application for "purchasing" ad impressions or click-
throughs.

On the ad management and commission charging it's kind of the reverse  
of an affiliate or commission model as the advertisers pay a  
commission for outgoing links rather than the store operator paying a  
commission for incoming links. Still, the MarketingCampaign and  
TrackingCode and ServerHit and related entities should be very  
applicable in either direction.

-David


On Jan 1, 2007, at 9:46 AM, Al Byers wrote:

> Shi,
>
> Thanks for the feedback. So in your case the products would be ad  
> positions,
> whereas, I was thinking they would be count packages (eg. 1K, 2K,  
> etc). In
> your case, you would just make the impression count the order quantity
> listed for that package in the OrderItem record? That sounds like  
> it would
> work. We could use promotions to put together special packages.  
> Thanks for
> bringing up the point that people want to buy ad positions - I had not
> thought of that. I don't have much experience with this. I guess  
> there are
> other conditions buyers will want to specify - what would they be? Of
> course, we want to be able to tie ads to the user profile if they  
> are logged
> in - we should be talking about how those facts will be stored.
>
> Your comments don't deal with how the ad images are tied in, do  
> they? Any
> thoughts there?
>
> I will want the ad content to be rendered on the front end via the  
> screen
> widget code. It may require some changes in the content management  
> package
> to go straight to content. My thought is to use the CMS to place  
> images in
> the file system where they can be accessed directly via the web  
> server or
> via the CMS.
>
> -Al
>
> On 12/30/06, Shi Yusen <[hidden email]> wrote:
>>
>> Hi Al,
>>
>> I don't know why I can't send this to the list, so I send it to you
>> directly.
>>
>> I think it would be better if the ad positions can be listed as  
>> products
>> in a
>> special catalog.
>>
>> A customer can order an ad position and assign the ad type such as
>> image, flash and etc. and from date, thru date.
>>
>> In the frontend, just insert some javascript code as Google did.
>>
>> Is this possible?
>>
>> Shi Yusen/Beijing Langhua Ltd.
>>
>>
>> 在 2006-12-30六的 10:56 -0700，Al Byers写道：
>> > Has there been any work done on an ad rotator service?
>> >
>> > If not, I think I would like to build off of the subscription  
>> model.
>> > I would create virtual products with different variants for  
>> impression
>> > counts (eg. 1k, 5k, etc) per month (or time period).
>> > I would not link Product to SubscriptionResource via
>> > ProductSubscriptionResource because I want to reuse the same  
>> product for
>> > different customers and I can't have static content (ie. ad  
>> images) tied
>> to
>> > a product.
>> >
>> > I want to use Subscriptions so that I have a persistent object  
>> to tie
>> > Content entities to. I would use the ShoppingList to handle  
>> recurring
>> > billing - which generates a new order on each cycle. I want to  
>> use the
>> > subscription model because there will be functionality to handle
>> commissions
>> > and billing - but those things are not really tied to  
>> Subscription, but
>> it
>> > seems that there would be some common elements.
>> >
>> > So I think I will need a new entity, AdContentHit, that would  
>> provide a
>> sort
>> > of de-normalized record for both capturing the ads tied to a  
>> user and
>> > managing their delivery.
>> >
>> > AdContentHit
>> >  - subscriptionId
>> >  - subscriptionSeqId
>> >  - contentId
>> >  - imageUrl - a quick way to deliver the image, rather than  
>> going thru
>> the
>> > contentId. Would need to get modified if the content location  
>> changed
>> >  - currentQuota - number of impressions scheduled for the month  
>> (or time
>> > period)
>> >  - currentHits - number of impressions delivered within month or  
>> time
>> period
>> >  - deliveryRate - i am thinking about indexing this field and  
>> using it
>> to
>> > find the next image to deliver. It would be the currentQuota /
>> currentHits
>> > if currentHits is > 0
>> >                                 or just equal to currentQuota if
>> currentHits
>> > == 0. This formula seems like it would work even if you go over  
>> your
>> quota -
>> > which will certainly happen.
>> >                         Okay, I see where this will not work  
>> unless all
>> > currentHits get zeroed out each night and currentQuota is for a  
>> 24 hour
>> > period - so that all ads are on the same point
>> >                          of reference. There is probably a  
>> better way to
>> do
>> > this. Have not looked at it much. Hoping for some suggestions.
>> >  - fromDate
>> >  - thruDate
>> >  - totalHits
>> >  - imageSize (medallion, banner, etc)
>> >
>> > These are just some initial thoughts. Anyone out there have some
>> knowledge
>> > to share?
>> >
>> > Thanks,
>> >
>> > Al
>>
>>

[byersa]

David,

Thanks for the advice. This is all in support of an advertising-based
revenue model for a website that draws a high amount of traffic. I figured
there were two parts to managing and delivering ads. You must have a
mechanism for delivering the ad link and the ad image and the image, and you
must provide a way to manage the sales and order process and have the orders
get into the ad delivery system. I guess I was trying to model it as a
somewhat standard product sell and was not thinking of the approach that you
mention.

On the front end, you are going to have sales people selling ad packages
like any other product. Only in this case, the actual content of the product
(ie. ad image and link url) will change for each client. The packages will
roll over each month until they are cancelled, so there must be recurring
billing using the ShoppingList. The salespeople will get a commission based
on the value of the package.

So the requirement is to have a way to package the product so that custom
content can be attached to it and my current solution is to have every ad be
specified as an OrderItem and have each order line item have an impression
quantity as its order quantity and be tied to a Subscription record, which
would be tied to a SubscriptionResource - which would identitify the image
content resource. One reason I chose the subscription model is that I have
done some work tying commissions to subscription sales. I was thinking I
would use ItemIssuance to track the number of ads served up.

On the delivery side, there is not now, but I would expect that there will
be a click-thru tracking requirement down the road. The initial requirement
would be to just deliver the right url link and image link upon request and
then, possibly, serve up the image when requested.

This is how I see it, but what I really want is a standard ad rotator
service that will fit the needs of most users - my client could probably
live with that. I am trying to determine what that would be. I want an
approach that will grow with OFBiz.

I see now that the MarketingCampaign, TrackingCodes, TrackingCodeVisit and
Visit entities would be necessary in the click-thru tracking. For those of
you, who like me, like to see things spelled out, it looks like a
MarketingCampaign would be set up to support a client and a TrackingCode
would be generated for each ad (its redirectUrl value would define the
client't target url) and tied to the campaign record via the
marketingCampaignId. Each Visit would be tied to the campaign via the
TrackingCodeVisit entity. That would let you count the number of clicks a
client received and from what ads and when and from where (sort of).

I see the necessity of this if a click-thru requirement is present (is it
ignorance on my part to think that some users would not need click-thru?). I
don't think my current client wants to pay for all that functionality -
initially. Could this be split into a phase one and phase two effort where
phase one is just managing the sales of direct ads and phase two would be
the inclusion of click-thru tracking? On the monthly recurring billing, a
calculation of click-thru revenues would have to be made and added to the
previous order's invoice before a new order is generated.

None of this really talks about how the ads are "rotated". I was thinking
that there would be custom records to support this. I was thinking of an
application attribute that kept a list of ads to be delivered, their quota
and currentHits and would order them based on which was most in need of a
hit.

-Al

On 1/1/07, David E Jones <[hidden email]> wrote:

>
>
> Al,
>
> Could you describe more background or requirements for what you're
> trying to do? It sounds like your emphasis is on providing an
> ecommerce like application for "purchasing" ad impressions or click-
> throughs.
>
> On the ad management and commission charging it's kind of the reverse
> of an affiliate or commission model as the advertisers pay a
> commission for outgoing links rather than the store operator paying a
> commission for incoming links. Still, the MarketingCampaign and
> TrackingCode and ServerHit and related entities should be very
> applicable in either direction.
>
> -David
>
>
> On Jan 1, 2007, at 9:46 AM, Al Byers wrote:
>
> > Shi,
> >
> > Thanks for the feedback. So in your case the products would be ad
> > positions,
> > whereas, I was thinking they would be count packages (eg. 1K, 2K,
> > etc). In
> > your case, you would just make the impression count the order quantity
> > listed for that package in the OrderItem record? That sounds like
> > it would
> > work. We could use promotions to put together special packages.
> > Thanks for
> > bringing up the point that people want to buy ad positions - I had not
> > thought of that. I don't have much experience with this. I guess
> > there are
> > other conditions buyers will want to specify - what would they be? Of
> > course, we want to be able to tie ads to the user profile if they
> > are logged
> > in - we should be talking about how those facts will be stored.
> >
> > Your comments don't deal with how the ad images are tied in, do
> > they? Any
> > thoughts there?
> >
> > I will want the ad content to be rendered on the front end via the
> > screen
> > widget code. It may require some changes in the content management
> > package
> > to go straight to content. My thought is to use the CMS to place
> > images in
> > the file system where they can be accessed directly via the web
> > server or
> > via the CMS.
> >
> > -Al
> >
> > On 12/30/06, Shi Yusen <[hidden email]> wrote:
> >>
> >> Hi Al,
> >>
> >> I don't know why I can't send this to the list, so I send it to you
> >> directly.
> >>
> >> I think it would be better if the ad positions can be listed as
> >> products
> >> in a
> >> special catalog.
> >>
> >> A customer can order an ad position and assign the ad type such as
> >> image, flash and etc. and from date, thru date.
> >>
> >> In the frontend, just insert some javascript code as Google did.
> >>
> >> Is this possible?
> >>
> >> Shi Yusen/Beijing Langhua Ltd.
> >>
> >>
> >> 在 2006-12-30六的 10:56 -0700，Al Byers写道：
> >> > Has there been any work done on an ad rotator service?
> >> >
> >> > If not, I think I would like to build off of the subscription
> >> model.
> >> > I would create virtual products with different variants for
> >> impression
> >> > counts (eg. 1k, 5k, etc) per month (or time period).
> >> > I would not link Product to SubscriptionResource via
> >> > ProductSubscriptionResource because I want to reuse the same
> >> product for
> >> > different customers and I can't have static content (ie. ad
> >> images) tied
> >> to
> >> > a product.
> >> >
> >> > I want to use Subscriptions so that I have a persistent object
> >> to tie
> >> > Content entities to. I would use the ShoppingList to handle
> >> recurring
> >> > billing - which generates a new order on each cycle. I want to
> >> use the
> >> > subscription model because there will be functionality to handle
> >> commissions
> >> > and billing - but those things are not really tied to
> >> Subscription, but
> >> it
> >> > seems that there would be some common elements.
> >> >
> >> > So I think I will need a new entity, AdContentHit, that would
> >> provide a
> >> sort
> >> > of de-normalized record for both capturing the ads tied to a
> >> user and
> >> > managing their delivery.
> >> >
> >> > AdContentHit
> >> >  - subscriptionId
> >> >  - subscriptionSeqId
> >> >  - contentId
> >> >  - imageUrl - a quick way to deliver the image, rather than
> >> going thru
> >> the
> >> > contentId. Would need to get modified if the content location
> >> changed
> >> >  - currentQuota - number of impressions scheduled for the month
> >> (or time
> >> > period)
> >> >  - currentHits - number of impressions delivered within month or
> >> time
> >> period
> >> >  - deliveryRate - i am thinking about indexing this field and
> >> using it
> >> to
> >> > find the next image to deliver. It would be the currentQuota /
> >> currentHits
> >> > if currentHits is > 0
> >> >                                 or just equal to currentQuota if
> >> currentHits
> >> > == 0. This formula seems like it would work even if you go over
> >> your
> >> quota -
> >> > which will certainly happen.
> >> >                         Okay, I see where this will not work
> >> unless all
> >> > currentHits get zeroed out each night and currentQuota is for a
> >> 24 hour
> >> > period - so that all ads are on the same point
> >> >                          of reference. There is probably a
> >> better way to
> >> do
> >> > this. Have not looked at it much. Hoping for some suggestions.
> >> >  - fromDate
> >> >  - thruDate
> >> >  - totalHits
> >> >  - imageSize (medallion, banner, etc)
> >> >
> >> > These are just some initial thoughts. Anyone out there have some
> >> knowledge
> >> > to share?
> >> >
> >> > Thanks,
> >> >
> >> > Al
> >>
> >>
>
>

[Ean Schuessler]

On Tuesday 02 January 2007 00:13, Al Byers wrote:
> Thanks for the advice. This is all in support of an advertising-based
> revenue model for a website that draws a high amount of traffic. I figured
> there were two parts to managing and delivering ads. You must have a
> mechanism for delivering the ad link and the ad image and the image, and
> you must provide a way to manage the sales and order process and have the
> orders get into the ad delivery system. I guess I was trying to model it as
> a somewhat standard product sell and was not thinking of the approach that
> you mention.

You may want to consider having the sale of an ad package trigger WorkEfforts
that collect the banners from the customer and run them through someone for
approval. The rotation could be handled as some kind of content group?

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[David E Jones-2]

On Jan 3, 2007, at 3:01 PM, Ean Schuessler wrote:

> On Tuesday 02 January 2007 00:13, Al Byers wrote:
>> Thanks for the advice. This is all in support of an advertising-based
>> revenue model for a website that draws a high amount of traffic. I  
>> figured
>> there were two parts to managing and delivering ads. You must have a
>> mechanism for delivering the ad link and the ad image and the  
>> image, and
>> you must provide a way to manage the sales and order process and  
>> have the
>> orders get into the ad delivery system. I guess I was trying to  
>> model it as
>> a somewhat standard product sell and was not thinking of the  
>> approach that
>> you mention.
>
> You may want to consider having the sale of an ad package trigger  
> WorkEfforts
> that collect the banners from the customer and run them through  
> someone for
> approval. The rotation could be handled as some kind of content group?

Yeah, the content group is a good idea and there is already some  
precedent (and an example!) for that. Something like the factoid  
thing in one of the screenlets on the home page of the ecommerce app  
might be helpful.

-David