Video Ads Delivery Capping

[alexfear]

Hi everybody!

I have an issue with delivery capping for video ads. I use Revive Adserver 3.0.2 and IAB VAST plugin v1.9.1 and try to limit video ad impressions per user's session (lets say 3 impression per user per day). This limitation doesn't work. Video ad is shown every time ignoring capping (I tried to limit impressions at both banner and campaign levels).

I already saw similar thread at www.longtailvideo.com and someone even provided solution to fix this bug. But it doesn't work for me.

 

Did anyone face this problem?

[alexfear]

The issue was in cookies: openx server didn't set capping cookies when player requested script fc.php.

Issue is resolved.

[tman]

Could you post how did you add these cookies? This would very beneficial for other too.

 

Did you add something to this below:

 

[YOUR-ADSERVER-DOMAIN-HERE]/www/delivery/fc.php?script=bannerTypeHtml:vastInlineBannerTypeHtml:vastInlineHtml&format=vast&nz=1&zones=pre-roll%3D[YOUR-ZONE-ID-HERE]

[Matteo Beccati]

The cookies are sent when the impression beacon is loaded, but my experience was that the Flash video player in use didn't actually set them.

[tman]

The cookies are sent when the impression beacon is loaded, but my experience was that the Flash video player in use didn't actually set them.

You are correct in that the cookies related to delivery cappin are not set properly. I'm not sure how the Flash video player is involved in the process. I'm using JW Player 6.10 with ads.

 

(A) When I observed cookies in Firefox/Firebug it loads these:

_OACAP[1]

_OASCAP[1]

_OABLOCK[1]

_OACCAP[1]

_OACBLOCK[1]

_OAZCAP[1]

 

( After first quartile those cookies just disappear without a trace to these cookies:

 

OACAP

OASCAP

OABLOCK

OACCAP

OACBLOCK

OAZCAP

OAZBLOCK

 

Is this the intended behaviour? (Rhetoric question)

 

When I added this line

if(@$_REQUEST["vast_event"])MAX_cookieFlush();//quick'n'dirty bug fix for frequency capping with video ad delivery 

 

to www/delivery/fc.php after line 31 it happens so that cookie set (A) starts to "interact" with cookie set (.

 

Any insight on this?

[Matteo Beccati]

You are correct in that the cookies related to delivery cappin are not set properly. I'm not sure how the Flash video player is involved in the process. I'm using JW Player 6.10 with ads.

 

(A) When I observed cookies in Firefox/Firebug it loads these:

_OACAP[1]

_OASCAP[1]

_OABLOCK[1]

_OACCAP[1]

_OACBLOCK[1]

_OAZCAP[1]

 

( After first quartile those cookies just disappear without a trace to these cookies:

 

OACAP

OASCAP

OABLOCK

OACCAP

OACBLOCK

OAZCAP

OAZBLOCK

 

Is this the intended behaviour? (Rhetoric question)

Yes, in theory. Cookies beginning with an underscore are "temporary" cookies that get merged to the permanent ones.

When I added this line

if(@$_REQUEST["vast_event])MAX_cookieFlush();//quick'n'dirty bug fix for frequency capping with video ad delivery 

 

to www/delivery/fc.php after line 31 it happens so that cookie set (A) starts to "interact" with cookie set ( .

 

Any insight on this?

Capping should be set when the impression is recorded, not when the request is made, so it is techincally wrong.

[tman]

Thank you for your time and effort Matteo.

 

Capping should be set when the impression is recorded, not when the request is made, so it is techincally wrong.

 

If my eyes are enough fresh after my morning cafe, it sets the permanent cookies after first quartile has been reached. Even though you pointed that the code added should be tecnically wrong, it seems the permanent cookies are set after the impression has happened. But how is impression deifned?

[Matteo Beccati]

"Temporary vs permanent" is only a trick that Revive uses to "pack" cookies in order to avoid hitting the limits on cookie number per domain. I.e. the content of a temporary cookie is appended to the permanent one on the next request.

[tman]

"Temporary vs permanent" is only a trick that Revive uses to "pack" cookies in order to avoid hitting the limits on cookie number per domain. I.e. the content of a temporary cookie is appended to the permanent one on the next request.

 

Ok, thanks for clarification. I still have to find the code where the concept of impression is executed, so that I can correct the technically incorrect solution.

[Matteo Beccati]

A few years after my initial investigations I've been finally able to understand what was wrong. I'll commit a fix shortly. Thanks for the persistence

[Matteo Beccati]

For reference, this has been fixed in 3.1.0.