Jump to content

gabrielt

Approved members
  • Content Count

    64
  • Joined

  • Last visited

Posts posted by gabrielt


  1. Update: I think I found the culprit: It was a zone linking issue. I had the campaigns linked to certain zones but the banners linked to different zones... It seems this mismatch caused the issue when Revive tried to obey both configurations. I will have a definitive answer after lettting it run for a couple of days, but I am pretty confident that this was the issue indeed.


  2. Hi,

    Everything was working fine in the previous months, but today when collecting data and generating our monthly reports to our advertisers, a noticed a big mismatch in numbers, which I started to investigate because the numbers where much lower than those from previous numbers.

    Here is what I found.

    A campaign configured as "Override", i.e. to be displayed 100% of the time in two zones. The number of views reported by the campaign stats page is completely different from the number of views reported by the zone stats page. See below. Interesting enough, the number of views reported for the campaigns is around half of the number of views reported for the zone.

    cdh-homepage-banners.png

    cdh-homepage-zone.png

    This campaign has a total of six banners, three of which configured to show if the OS is either Windows, OS X or Linux, and the other three is the OS is Android, Blackberry, iOS or Windows Phone. Maybe the problem is with this configuration? I wanted a way to select three banners for desktop and three for mobile, and this was the only workaround I could think of. There were also a bunch of old disabled banners that I deleted today to see if it helps (I will have to check if that worked after a few days).

    Another weird behavior was for a ROS (Run of Site) campaign, which was underdelivered according to the campaign stats. We configured it to be displayed 500,000 times, and we have plenty of impressions in the selected zones to fulfill this order. But see how Revive was delivering too few impressions at the beginning of the month and then tried to speed up. It ended up being delivered only around 420,000 times.

    cdh-ros.png

    I have no idea as how to start debbuging this. Please advise!

    Thank you in advance,

    Gabriel.


  3. @Matteo Beccati Just to confirm that the new 4.1.1 version solved the issue. Many thanks for fixing this promptly. PS: on the downloads page, the link to the 4.1.1 tar.gz version is pointing to the 4.1.0 version.

    I am not facing the issue mentioned by @Richard Cook above. For me opening /www/admin/updates-product.php shows:

    You are currently using Revive Adserver v4.1.1 running on nginx 1.12.1, PHP 7.1.11 and MySQL 5.6.37-82.2-log.

    Cheers.


  4. Hi there,

    I am getting this error while trying to upgrade:

    Errors were found when detecting previous installations of Revive Adserver
    We have detected integrity issues with your database. This means that the layout of your database differs from what we expect it to be. This could be due to customization of your database.

    The install.log shows that there are 107 errors. See below.

    I haven't customized anything, and I don't know how to fix these issues.

    Please advise.

    Gabriel.

    ----

    =========================================================================
    Attempting to detect an existing Openads (aka. phpAdsNew) installation...
    PAN not detected
    Attempting to detect an existing Openads (aka. Max Media Manager 0.1) installation...
    MMM v0.1 not detected
    Attempting to detect an existing Openads (aka. Max Media Manager 0.3) installation...
    MMM v0.3 not detected
    Attempting to detect an existing Revive Adserver installation...
    schema file found: [redacted]/etc/changes/schema_tables_core_621.xml
    schema definition from cache TRUE
    successfully parsed the schema
    schema name: openads
    schema version: 621
    schema status: final
    running integrity check
    comparing database [redacted] with schema [redacted]/etc/changes/schema_tables_core_621.xml
    column definition does not match: account_preference_assoc.account_id
    column definition does not match: account_user_assoc.account_id
    column definition does not match: account_user_permission_assoc.account_id
    column definition does not match: ad_category_assoc.category_id
    column definition does not match: affiliates.updated
    column definition does not match: affiliates_extra.affiliateid
    column definition does not match: agency.updated
    column definition does not match: audit.actionid
    column definition does not match: banners.acl_plugins
    column definition does not match: campaigns.updated
    [... snip ...]
    checking field: phpads_zones updated
    found field updated
    #! database integrity check detected problems with the database
    #! 107 fields to change
     


  5. Fixed sizes have to do the way the web traditionally works. You have to keep in mind that "responsive" is a somewhat new concept. The web is about 20 years old and we've only seen responsive layouts in the past 2-3 years.

    That said, it would be great to have a built-in mechanism to detect the maximum width supported and display a banner that fits that space.

    For example, today we can setup a campaign with, say, two banner sizes, 728x90 and 300x250, at the same time. Revive will display the 728x90 banner when this campaign is assigned to a 728x90 zone, and will display the 300x250 banner when this campaign is assigned to a 300x250 zone.

    One step further would be the Revive tag to detect the width, and this particular zone would display (for example) the 728x90 banner when the resolution is high enough and the 300x250 banner at lower resolutions.

    Currently, there are a few known workarounds to that. You can define zones without a width and height (it is possible, just enter * x *), in this case, both banners (728x90 and 300x250) will be displayed at the zone. Then you can set up banner limitation to display the 300x250 for mobile browsers and the 728x90 banner for non-mobile browsers.

    I hope I have helped.


  6. Hi,

     

    Moved my Revive Adserver installation to a new server, and we are seeing the following errors:

     

    MESSAGE: Redefining already defined constructor for class XML_Parser
    TYPE: Strict
    FILE: /www/hsads/lib/pear/XML/Parser.php
    LINE: 204
    DEBUG INFO:
     
    199 * @param string $mode how this parser object should work, "event" for 
    200 * startelement/endelement-type events, "func" 
    201 * to have it call functions named after elements 
    202 * @param string $tgenc a valid target encoding 
    203 */ 
    204 function __construct($srcenc = null, $mode = 'event', $tgtenc = null)
     
    205 { 
    206 parent::__construct('XML_Parser_Error'); 
    207 
    208 $this->mode = $mode; 
    209 $this->srcenc = $srcenc;
    MESSAGE: Non-static method Date_TimeZone::isValidID() should not be called statically
    TYPE: Strict
    FILE: /www/hsads/lib/pear/Date/TimeZone.php
    LINE: 3642
    DEBUG INFO:
     
    3637 Date_TimeZone::setDefault($_DATE_TIMEZONE_DEFAULT); 
    3638 } elseif (getenv('PHP_TZ') && Date_TimeZone::isValidID(getenv('PHP_TZ'))) { 
    3639 Date_TimeZone::setDefault(getenv('PHP_TZ')); 
    3640 } elseif (getenv('TZ') && Date_TimeZone::isValidID(getenv('TZ'))) { 
    3641 Date_TimeZone::setDefault(getenv('TZ')); 
    3642 } elseif (Date_TimeZone::isValidID(date('T'))) {
     
    3643 Date_TimeZone::setDefault(date('T')); 
    3644 } else { 
    3645 Date_TimeZone::setDefault('UTC'); 
    3646 } 
    3647 //
    MESSAGE: Non-static method Date_TimeZone::setDefault() should not be called statically
    TYPE: Strict
    FILE: /www/hsads/lib/pear/Date/TimeZone.php
    LINE: 3645
    DEBUG INFO:
     
    3640 } elseif (getenv('TZ') && Date_TimeZone::isValidID(getenv('TZ'))) { 
    3641 Date_TimeZone::setDefault(getenv('TZ')); 
    3642 } elseif (Date_TimeZone::isValidID(date('T'))) { 
    3643 Date_TimeZone::setDefault(date('T')); 
    3644 } else { 
    3645 Date_TimeZone::setDefault('UTC');
     
    3646 } 
    3647 // 
    3648 // END 
    3649 ?> 
    3650
    MESSAGE: Non-static method Date_TimeZone::isValidID() should not be called statically
    TYPE: Strict
    FILE: /www/hsads/lib/pear/Date/TimeZone.php
    LINE: 153
    DEBUG INFO:
     
    148 * @param string $id the time zone id to use 
    149 */ 
    150 function setDefault($id) 
    151 { 
    152 global $_DATE_TIMEZONE_DEFAULT; 
    153 if(Date_TimeZone::isValidID($id)) {
     
    154 $_DATE_TIMEZONE_DEFAULT = $id; 
    155 } 
    156 } 
    157 
    158 /**
    MESSAGE: Non-static method Language_Loader::load() should not be called statically
    TYPE: Strict
    FILE: /www/hsads/lib/OX/Extension/authentication/authentication.php
    LINE: 18
    DEBUG INFO:
     
    13 require_once MAX_PATH . '/lib/max/Plugin/Translation.php'; 
    14 require_once LIB_PATH . '/Plugin/Component.php'; 
    15 require_once 'Date.php'; 
    16 require_once MAX_PATH . '/lib/max/language/Loader.php'; 
    17 
    18 Language_Loader::load('settings');
     
    19 
    20 /** 
    21 * Plugins_Authentication is an parent class for Authentication plugins 
    22 * 
    23 * @package OpenXPlugin
    MESSAGE: Undefined index: action
    TYPE: Notice
    FILE: /www/hsads/lib/OX/Admin/UI/Install/InstallController.php
    LINE: 80
    DEBUG INFO:
     
    75 * Called before any action gets executed 
    76 */ 
    77 protected function init() 
    78 { 
    79 // No upgrade file? No installer! Unless the user is in the last step 
    80 if (!file_exists(MAX_PATH . '/var/UPGRADE') && 'finish' != $_REQUEST['action']) {
     
    81 header("Location: index.php"); 
    82 exit(); 
    83 } 
    84 @set_time_limit(0); 
    85
    MESSAGE: Cannot modify header information - headers already sent by (output started at /www/hsads/lib/max/ErrorHandler.php:130)
    TYPE: Warning
    FILE: /www/hsads/lib/OX/Admin/UI/Install/InstallController.php
    LINE: 81
    DEBUG INFO:
     
    76 */ 
    77 protected function init() 
    78 { 
    79 // No upgrade file? No installer! Unless the user is in the last step 
    80 if (!file_exists(MAX_PATH . '/var/UPGRADE') && 'finish' != $_REQUEST['action']) { 
    81 header("Location: index.php");
     
    82 exit(); 
    83 } 
    84 @set_time_limit(0); 
    85 
    86 // load translations for installer

  7. andrewatfornax, your line of thought is correct. As the page is available must faster, the user will move to a different page or leave the website before all banners have loaded, hence the drop in adviews. If all banners were stored locally, I doubt that we would see any drop at all, as they would be loaded super-fast. The issue here is with the latency of RTB networks, which can't do much about it. As you probably know, with RTB networks we have a cascading stream of networks that check if the network has a banner to serve to that user, otherwise the network moves on to the next network in the pipeline, and so on. Something like this:

     

    Revive -> Network #1 -> Network #2 -> Network #3 -> Google AdSense

     

    These networks pay way more than Google AdSense, so removing them is not an option.

     

    So, for the time being, I reverted back to the single-page call method. Unfortunately, most our inventory goes unsold and we have to use such networks...


  8. After one week of using the new async code, I am having mixed feelings.

     

    At one hand, pagespeed improved considerably.

     

    On the other hand, we are serving much less ads. In fact, we are serving about 25% of what we used to.

     

    Note that our banners are basically RTB networks.

     

    Please see attached screenshots.

     

    async-spc-hs.png

     

    async-spc-cdh.png

     

    async-hs-pagespeed.png


  9. Wondering on how to work that out with the new async invocation code...

     

    I played with height: 0px and display: hidden. These tricks work but I am afraid of using them as I am using banners from networks such as Google AdSense, and they might complain that we are rendering banners in a hidden <div>.

     

    I saw somewhere that we might add a data-field that would "activate" the correct code depending on the resolution, so the banner that won't be displayed won't be rendered/loaded. Still researching:

     

    http://christianheilmann.com/2012/12/19/conditional-loading-of-resources-with-mediaqueries/

     

    Please take a look under "Matchmedia to the rescue". I played with it but couldn't get it to work. I don't know where and how to "trigger" the JavaScript code. I'd appreciate any help.


  10. My question is whether the hash data-revive-id is fixed or varies according to the zoneid, and if it varies, how to calculate it? Because our CMS generate the tags inserting the zoneid according to the location the user is loading from our website.

     

    Thank you!


  11. I see that the async loading code uses the following format:

    <!--/*
      *
      * Revive Adserver Asynchronous JS Tag
      * - Generated with Revive Adserver v3.2.0
      *
      */-->
     
    <ins data-revive-zoneid="1" data-revive-id="7813b56809490348166b3701f410dbbc"></ins>
    <script async src="//xxxxxxxxx.com/www/delivery/asyncjs.php"></script>
×
×
  • Create New...