alexfear Posted March 27, 2014 Report Share Posted March 27, 2014 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? tman 1 Quote Link to comment Share on other sites More sharing options...
alexfear Posted March 31, 2014 Author Report Share Posted March 31, 2014 The issue was in cookies: openx server didn't set capping cookies when player requested script fc.php. Issue is resolved. Quote Link to comment Share on other sites More sharing options...
tman Posted September 4, 2014 Report Share Posted September 4, 2014 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] Quote Link to comment Share on other sites More sharing options...
Matteo Beccati Posted September 4, 2014 Report Share Posted September 4, 2014 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 1 Quote Link to comment Share on other sites More sharing options...
tman Posted September 4, 2014 Report Share Posted September 4, 2014 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? Quote Link to comment Share on other sites More sharing options...
Matteo Beccati Posted September 4, 2014 Report Share Posted September 4, 2014 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: OACAPOASCAPOABLOCKOACCAPOACBLOCKOAZCAPOAZBLOCK 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 lineif(@$_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. Quote Link to comment Share on other sites More sharing options...
tman Posted September 5, 2014 Report Share Posted September 5, 2014 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? Quote Link to comment Share on other sites More sharing options...
Matteo Beccati Posted November 20, 2014 Report Share Posted November 20, 2014 "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. Quote Link to comment Share on other sites More sharing options...
tman Posted November 21, 2014 Report Share Posted November 21, 2014 "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. Quote Link to comment Share on other sites More sharing options...
Matteo Beccati Posted November 21, 2014 Report Share Posted November 21, 2014 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 tman 1 Quote Link to comment Share on other sites More sharing options...
Matteo Beccati Posted April 3, 2015 Report Share Posted April 3, 2015 For reference, this has been fixed in 3.1.0. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.