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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >> >>
