Delivery Cap per Visitor (Ad server plugin?)

Hi Luc,

To be honest, I really don't know. I think I'll have to play with it and see.

It's definitely an OpenX server side thing. The OVA client doesn't know anything about delivery capping. The OpenX server should take care of that completely, but saying that, clearly OVA needs to pass something to OpenX with the ad call to allow OpenX to identify each visitor uniquely. I think in the case of OpenX, it's some form of OpenX cookie.

If that happens, I then imagine that OpenX would do the delivery capping on the basis of the impression tracking event rather than the ad complete event. I'd be almost certain on that.

I vaguely remember that there was some type of issue where the required OpenX cookies etc. are not being passed from OVA to OpenX with the ad tag which may prevent this all from working - but I'm guessing.

Here's some info I found on the OpenX site which may help:

http://www.openx.org/docs/2.8/userguide/banner+delivery+options

Perhaps it would be a good idea to post something to the OpenX forums? If someone can explain how this works on the OpenX side, I could look to see if there's anything OVA needs to do to support it.

I think it will all boil down to supporting OpenX cookies from OVA - and honestly, I really just don't know how to do that via an AS3 call, but if you can manage to work it out, we could try adding support in...

Paul.

Thanks for the detailed into Paul.
I'll look into it a bit then.

Thanks,
Luc.

Hi,

I'm testing the openXVideoAds plugin (v1.1) in OpenX using jw-player (v5.5), and no matter what level I add the visitor capping (zone, campaign, and banner levels, each independently), the visitor capping doesn't work at all, regardless of browser.

Is this a known bug? Is there a known fix/workaround?

Regards,

Redbo

I suppose I should have mentioned that the capping I'm trying to do are for a zone/campaign that contains *just* in-line pre-roll video ads.

Redbo

Hi Redbo... probably a question best directed to the OpenX folks on their forum/site, but my feeling is that "delivery capping" probably isn't enabled for their video plugin. I assume it's dependant upon cookies of some type being passed through with the ad request?

It's honestly not something I know much about, but if you know how it should work in OpenX and are sure that the video ad plugin will work if OVA passes the right info, we can look further into making sure that info is passed?

Paul

hi

i see the same problem with openx 2.8.5 and openXVideoAds 1.1
using ova fo as3

any help ?

Problem remains.
Openx 2.8.8, any jwplayer, ova.

I tracked all the way from openx to the player and this is what I found out: player gets delivery/lg.php script and sets capping cookies, but they (cookies) expires after 5 seconds.

If I call delivery/lg.php link (with all the same parameters) directly, then it sets cookies for real capping parameters (those I set in Openx).

I am php/js developer and have no clue, how in this specific situation flash works, but I've worked on this problem for a two days now and have no clue how to fix.

I've been looking more into this today. I may have a lead on the problem.

I suspect it has something to do with the fact that the flash player/page is on a different domain to the actual OpenX instance - in that case, the cookies aren't passed through with the HTTP request. That's my current line of thinking.

Do you have a good ad tag that I can use to see the full set of cookies being set in a browser (if I just put it into Chrome or Firefox) and do you know precisely which cookies are required to support the delivery cap? I'll use that for testing...

Paul

Hi!

lg.php (impressions link) sets those cookies: http://www.zimagez.com/zimage/screenshot-11222011-062036pm.php
After refresh there must be others, which are checked by fc.php: http://www.zimagez.com/zimage/screenshot-11222011-062156pm.php

To track all of this I used this video: http://sportacentrs.com/sportacentrs_tv/video/21112011-egleskalns_mans_merkis_spelet_krievija_va

For best tracking used firefox with firebug and firecookie extensions.
Requested openx files can see in firebugs Net console (appears when play button is pressed).

P.S. It's production page and I don't know when video add will be removed (in case, if add doesn't show anymore).

just thought I'd chime in and say I'm having the same problem, unfortunately I do not have any input yet.

Looks like after 5 seconds of an ad playing somehow the cookies are deleted/reset.

http://forum.openx.org/index.php?showtopic=503505822

Hi,

I must admit, this has me a little stumped, but I'm keen to track this down if it's an OVA originated issue.

What I'm currently wondering is - do those cookies have a 5 second expiry set on them when OpenX creates them in the first instance? I assume they are being deleted after an ad plays for 5 seconds because of a very short expiry time?

Do you know if that's true?

Paul

I do not believe that is the case. Here is my scenario. I am doing something pretty basic. I'm doing a pre-roll via OVA and JW Player. I have delivery capping set to 1 view total for 10 minutes. (My ad is 15 seconds long).

If I let the ad complete (over 5 seconds) and then let my video play. When I refresh the page or go to any other video using this ad the ad will play again.

Second scenario. I hit play and after the ad starts playing I either direct my browser somewhere else or hit refresh (before 5 seconds). I will not see my ad again. It will re-appear after my view capping of 10 minutes.

I also found this deep in the openx code logs.. Maybe some continuous script is being called to set that cookie and then crashes out (search the page for "5 seconds") http://code.google.com/p/openx-iab-vast/wiki/ChangeLog

Hiya,

No... that ChangeLog is actually my (very very old, original OVA) page...

The "5 seconds" in there has nothing to do with cookies. The "safety mechanism to stop events re-firing after 5 seconds" is code in the OVA plugin that ensures that tracking calls do not fire multiple times - completely un-related to cookies at all.

I'll have more of a think and try some testing myself. It may well be related to the way Flash/AS3 handles cookies, particularly given the fact that the cookies are not on the same domain as the ad call domain.

Paul

PS: I really should delete those old Google Code pages...

I figured it was worth a shot. haha, sorry about digging up your favorite logs.

And idk about the same domain/diff domain thing. Everything works if you redirect your browser before the 5 seconds.

I might have to try a 3 or 4 second ad and let everything play through. Just to see if it works. That may help prove it has something to do with the magical 5 second mark.

Hi,

I think I've finally found the problem!!!!! It took hours of tracing and I'm still not 100% positive, but this seems to fit.

The bottom line is that OpenX seems to be instructing the client (OVA in this case) to delete the cookies when the "firstQuartile" event is fired. That would explain why you seem to see it delete the cookies after 5 seconds.

In a normal linear OpenX Video Ad, the following HTTP calls are made (in the order presented):

1. Ad call to get the VAST response
2. Impression when the video started
3. "Video Ad started" event when the video ad starts
4. "Video ad at first quartile" event when the video ad gets to 1/4 way through
5. "VIdeo ad midpoint" at the half way point
6. "Video ad thirdQuartile" at the 3/4 point
7. "Video Ad complete" when it's done

The step 4 HTTP call (firstQuartile) is returning this:

See the "Set-Cookie" instructions in the response header? It's telling the browser to delete the cookies!

Just for completeness, here are the set-cookie instructions sent by OpenX on the original ad call:

To me, it seems the bug exists because of a date problem with the cookies. Look at the expiry date on the "delete" instruction above:

Unless I just time-travelled, the correct expiry date should be:

I'm not sure I can really look at the OpenX PHP code to find this happening, but I'm now convinced that it's a bug in the OpenX Video Ad server side plugin that's resulting in these delete instructions being sent...

Paul

wow, that's some impressive digging. It certainly looks like 100% findings to me. I started digging into the PHP friday but didn't make it to far. With this information I may be able to dig a little easier. I'll jump back over to openx's support forum today and see what's shaking. This information I imagine will be extremely helpful, thank you so much Paul.

Hey, glad I could help a little... Very keen to know how you go on the OpenX side with this so definitely keep us posted on it ..

Paul

Paul, thanks for the info. I've been trying to track down the root cause of the cookie deletion in the openx response, but openx isn't the easiest thing in the world to hack on :-/

In the meantime, is there a simple way of disabling quartile tracking as a workaround (I don't really need it right now)?

Hi Mark... to be honest, I don't think there is an option on the OpenX side to stop the tracking URLs from being placed into the VAST response and OVA doesn't have an option to stop "quartile tracking" unfortunately - if the VAST response has the data, it gets fired.

Contact me on enquiries@openvideoads.org if this is a critical requirement and we can discuss it further/see if I can do something, but as it is right now, there is no way to independently disable the quartile tracking...

Paul

Actually, I think I might have found a fix for OpenX.

the _OA*BLOCK and _OA*CAP cookies are temporary cookies, which get unpacked and are supposed to get converted into the 'permanent' cookies OA*BLOCK and OA*CAP on the next interaction with OpenX. But for some reason with the vast delivery plugin conversions don't occur properly.

So far, dropping this in at the end of init-delivery.php (in OpenX root) has helped:

MAX_cookieFlush();

But I've yet to determine whether or not this affects anything else, such as capping for normal banners. OpenX is an untraceable mess :-)