andrewatfornax

Hi @Xabi, I don't think Revive Adserver can count clicks if you do this. Your banner is HTML code that doesn't contain the URL that users will click on, as the banner content is loaded dynamically, inside an iframe. As a result, Revive Adserver won't have access to that content, and will not be able to modify the click URL to ensure that clicks are sent to Revive Adserver first (so that the click can be recorded) and then the user redirected to the destination.

Hi @Tomas Kapler, There are a couple of different approaches. Possibly the easiest thing for something like "different ads to registered users vs. not registered users" would be to separate those ads into different zones in Revive Adserver, and then, depending on if the user is "registered" or not in your CMS, dynamically insert the appropriate zones, so that you get the ads that you want. You could use the same approach for other categories as well, if you wanted. The other approach is to pass variable(s) into Revive Adserver in the invocation code, and then use Delivery Rules to deliver/not deliver banners, based on the value of the variable(s) that you pass in. HTH.

Glad you got it fixed, but for clarity, no, Revive Adserver doesn't automatically generate Apache configuration files - it's up to the admin to configure Apache (or other web server) they way they want it to be configured, and to ensure that the path to Revive Adserver works - be that by setting the root of the website to the root of Revive Adserver, or by having Revive Adserver as a sub-directory of the root website. Revive Adserver doesn't care which way - it's up to you how you want it.

Hi @lena11d, It might, although it quite easily might not. However, that won't have anything to do with either putting a banner in one campaign and then linking it to two zones, vs. putting the banner in twice (in two separate campaigns) and linking one campaign to each zone. Rather, the details of how many impressions the banner will get in each zone will depend on: * The total overall impression needs of the campaign; and * The relative priorities of all the banners that are linked in each zone. So, if you had one campaign, and it was totally unlimited in terms of total impressions, and you had it linked to one zone that was getting 100 views, and another zone that was getting 200 views, and there were no other banners competing for these views, then yes, I would expect the banner to then take all 300 impressions. But that's a very simplistic view, naturally - as soon as you add in overall campaign targets, and competing campaigns/banners in zones, then things get more complex!

No, you don't need to copy your Apache configuration over - that's not relevant. You do need to copy your Revive Adserver configuration files over, however, and make sure they are in the right place, and able to be read by the web server, so that the upgrade process will detect that it's an upgrade, not a clean install. The upgrade process will clearly tell you if it's an upgrade vs. an install. Re: multiple configuration files: https://documentation.revive-adserver.com/display/DOCS/Managing+Configuration+Files

Support for Apache configuration is well beyond the scope of what I can help with here, but this may be of help/interest: https://documentation.revive-adserver.com/display/DOCS/Managing+Configuration+Files

Hi @Cavi, Yes, but maybe not how you want. Given your above scenario, you can, of course, configure Campaign A (which a higher yield) to always display if possible, and to only display Campaign B if (for whatever reason) Campaign A isn't suitable. So, in that sense, yes, Revive Adserver can do its best to deliver the higher priced campaign first. But that all depends on you manually setting the types of campaigns and/or weights, according to how you want it. Normally, when you say "prioritise based on on price" (or better, based on revenue, or profit), what you really mean is that you want to dynamically compare CPM, CPC and CPA campaigns, and dynamically adjust the rate of delivery over time, to address changes in performance which affect revenue (or profit), so that you're maximising for revenue (profit). There is an option in Revive Adserver that was written a long time ago, back in the OpenX Source days, for this - but I have not had a chance to look at it since we took over, and so I really don't know how effective it is. HTH.

Hi @DonRickler, No, as far as I know, Revive Adserver doesn't support dynamic variable names. That said, you can essentially pass in any variable name/value pair combination to Revive Adserver that you want, via the invocation tags - Revive Adserver will let you do that, so, you can dynamically generate both the name and the value of a variable pair, if you want to. It's just that when that variable information arrives in to the ad serving code, you can only make decisions about things like what banner to deliver based on what's set up. So, you will have set up expectations around one or more variable names - and those names can't change dynamically based on the context of the banner. Does that help?

I think this is a duplicate post, and it's been answered on the other post, yes?

With that little information? Probably no one :-) Maybe try upgrading to Revive Adserver, if you are using the old OpenX Source, and then we might be able to help.

Hi, I think I have answered this several times on the forums. Currently, there is no support, other than the options that exist when creating a new account, for limiting access.

What type of banner are you trying to put the .mp4 file into?

Hi @bdamage, Thanks I think I noticed something the other day too, but assumed it was me breaking my dev install, like I usually do. Can you please raise a ticket in GitHub, if you haven't already?

Hi @especht, Yes, the asynchronous tag is for exactly that - loading the banners independently of the page content. It's been a core part of Revive Adserver since... oh, I can't remember. Upgrade to the latest version if you haven't, and you should have it.

Yeah, that shouldn't be an issue. If you can guarantee you don't need the historical data any more, take a backup, and delete, by all means!

PRs always welcome!

Most likely reasons: 1. Adblocker installed. 2. Missing or incorrectly installed/upgraded plugins. Both are covered in the troubleshooting section of our docs - see link in footer.

Hi @albertalbert, If you're getting a constant re-direction issue, it's often a permissions issue, or something to do with the server setup / tech requirements. 1. Check the technical requirements of the version you want to install carefully. Do you meet the requirements? 2. Check your web servers logs.

HI @sonic, The most likely explanation is that during the install process, your new 4.1.3 code base did not detect your previous configuration file. Make sure you copy your old OpenX configuration file(s) into the new code base; make sure the files can be read by the webserver user; and make sure that you run the upgrade process using the same domain name in the URL as your previous installation.

Hi @Tim, Check that the banner and the zone are linked.

Hi @Jean, I think I answered this just the other week in another post? No, at this stage, we don't have a database schema diagram or explanation up. You can see what we do have in our documentation site, though - link in my footer.

Hi @melamoccicata, It's hard to know for sure, because I don't know exactly what the plugin you are talking about is asking for when it asks for "ADSERVER ID". However, it might be the platform_hash value from the rv_application_variable table?

Hi @Krishna Modi, Well, that sounds like a bug in that case. Would you like to open one for us in GitHub please?

Hi @Nicode, Please see: https://documentation.revive-adserver.com/display/DOCS/Missing+Features

Hi @Zsolt, As a general rule, this should not be necessary, unless you are running into significant performance/space issues. 9 million rows is not something that should be an issue for MySQL, though - it's a pretty small number of rows. The code base generally does already delete data that is not needed, so manually cleaning up tables can result in some historical stats etc. no longer working. It depends how important that is to you!