Jump to content

tman

Approved members
  • Posts

    7
  • Joined

  • Last visited

Posts posted by tman

  1. I wanted to make one note on data provided by Gabrielt. I noticed that there was huge increase in the CTR. I think that is a very good point to look into. I'm trying some prioritizing the way Matteo suggested. I try loading banners with Ajax when people, according to statistics, use more time on the pages.

  2. "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.

  3. 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?

  4. 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]

     

    (B) 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 (B).

     

    Any insight on this?

  5. It seems to me that this is an old problem dicussed in JW Player forum. I'm not sure that is the problem now thoroughly solved, but now the delivery capping seems to work.

     

    I edited the file revive\www\\delivery\fc.php to the following: (Note the addition after line 31)

    <?php
    
    /*
    +---------------------------------------------------------------------------+
    | Revive Adserver                                                           |
    | http://www.revive-adserver.com                                            |
    |                                                                           |
    | Copyright: See the COPYRIGHT.txt file.                                    |
    | License: GPLv2 or later, see the LICENSE.txt file.                        |
    +---------------------------------------------------------------------------+
    */
    
    /**
     * This is autogenerated file which contains all files from the "delivery_dev"
     * folder of Revive Adserver merged into a single output file. On systems
     * without a PHP opcode cache that is configured to not regularly check for
     * file updates, this autogenerated file can dramatically improve the
     * performance of Revive Adserver's delivery engine.
     *
     * !!!Warning!!!
     *
     * Do not edit this file. If you need to do any changes to any delivery file,
     * check out the source code from GitHub; make the necessary changes to the
     * file(s) in the "delivery_dev" folder; and regenerate the delivery files
     * using the script located in the "scripts/delivery" directory.
     */
    
    if (empty($_GET['script'])) {
    exit(1);
    }
    include_once '../../init-delivery.php';
    
    if(@$_REQUEST["vast_event"])MAX_cookieFlush();//quick'n'dirty bug fix for frequency capping with video ad delivery
    
    $script = str_replace("\0", '', $_GET['script']);
    $aPluginId = explode(':', $script);
    $scriptFileName = MAX_PATH . rtrim($conf['pluginPaths']['plugins'], '/') . '/' . implode('/', $aPluginId) . '.delivery.php';
    if (stristr($scriptFileName, '../') || stristr($scriptFileName, '..\\') || !is_readable($scriptFileName) || !is_file($scriptFileName)) {
    if (empty($conf['debug']['production'])) {
    echo "Unable to find delivery script ({$scriptFileName}) for specified plugin-component-identifier: {$script}";
    }
    exit(1);
    }
    include $scriptFileName;
    
  6. 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]

  7. My localhost testing system:

    • Apache 2.4.9
    • PHP 5.5.12
    • MySQL 5.6.17
    • Revive Ad Server 3.0.5
    • JW Player with Ads 6.10 (in Flash mode)

     

    I'm now trying to test with JW Player 6.10 Ads. I get the ads playing, but my delivery capping is not working.

     

    This the way I test:

     

    1. I reload page

    2. Play the video

    3. Reload

    4. Play the video

     

    To me it seems that restrictions and capping have no effect. Is there possibly a cache preventing me from succeeding? Why could it be that the delivery capping is not working?

     

    I see a lot of cookies from Revive with firebug, but I'm not aware what I can tell from them. It seems that some cookies appear when video starts and then dissappear without leaving a mark to permanent cookies.

     

    Here is a copy of Revive cookies I see in my testing environment:

    revive.multisite.com FALSE / FALSE 1412346954 OABLOCK 1.1409754948
    revive.multisite.com FALSE / FALSE 1441290954 OACAP 1.1
    revive.multisite.com FALSE / FALSE 1412346954 OACBLOCK 1.1409754948
    revive.multisite.com FALSE / FALSE 1441290954 OACCAP 1.1
    revive.multisite.com FALSE / FALSE 1441290964 OAID 047116035544af289be538eb63fc822e
    revive.multisite.com FALSE / FALSE OASCAP 1.1
    revive.multisite.com FALSE / FALSE 1412345627 OAZBLOCK 1.1409753615
    revive.multisite.com FALSE / FALSE 1441290954 OAZCAP 1.2
    revive.multisite.com FALSE / FALSE sessionID 2b5187b748f4295016577acf7f2ecb71
×
×
  • Create New...