All Activity

Hi, I'm having a strange problem - the min.php is not loading any of the CSS or JS files for the UI. Only the widgets styles are loaded correctly. Everything else works; ads are being served correctly, but the UI styling is missing. When I open the link for the stylesheet/js it is simply empty. What I did so far: - I checked the server for errors - no PHP errors were reported for that issue/page. - I went in the directory (assets) and upped the permissions in the folder. - I checked "Force SSL" in the UI Preferences. That solved the "not secure" issue but not the styling one. I also tried it from the server itself. - I can see no relevant errors in the console. I'm a bit of a loss what else can I do/check. It's probably a permission / path issue, but I'm not sure where to look for it. Any ideas?

We just released Revive Adserver v5.5.2 This version ensures that MaxMind GeoLite2 City file downloads continue to work automatically after May 1st, 2024. It also contains some bug fixes and performance improvements. Changes in v5.5.2 of the Revive Adserver software: We updated the MaxMind GeoIP2 plugin to support the upcoming changes in the procedures required to download database updates from MaxMind. In order for the automatic updates to continue working, the MaxMind account ID needs to be added in the plugin configuration screen. We’ve updated the page that explains How to Configure MaxMind’s license key to download GeoIP2 files, please review and add your MaxMind account ID to the plugin’s settings before May 1st, 2024. We fixed the “Geo/Organisation” delivery rule that was not working as expected. We fixed and issue with the password recovery process showing an empty recovery screen at the end of a successful process, under some circumstances. We fixed an issue with midnight maintenance potentially becoming very slow during pruning of the data_summary_ad_zone_assoc table on big instances. We fixed the unexpected 500 errors when using an invalid configuration file. We fixed an issue with zone chaining being presented as a viable option for Email/Newsletter zones while it cannot actually work due to the limitations of such zone type (the click URL is hardcoded to the original zone ID). We fixed an issue with search settings being reset when typing a new search keyword. Compact view is also the new default in order to keep resource usage low. We fixed an issue with manager user delete permission not being properly checked when third party products were using the “DLL” data access layer. This issue was reported by the developers of the Revive Adserver REST API. Full release notes for v5.5.2 can be found on our Github page. Download, install and update Revive Adserver v5.5.2 is available for download now. Once downloaded, please refer to the instructions for Installations of Revive Adserver or for Updating Revive Adserver. Make sure that the server(s) being used meet(s) the minimum technical requirements. Community contributions The continued development of Revive Adserver is being sponsored by community members, either financially or in the form of code contributions, or by reporting issues they discovered while using the software. We’re very grateful for the support we’ve received. If you would like to contribute to our project, please consider becoming a patron on Patreon.com. Another way to contribute to our project, is by using the Revive Adserver Hosted edition. The post Revive Adserver v5.5.2 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

That`s great, hope you can figure it out. Take a look here if not already. https://revive-adserver.atlassian.net/wiki/spaces/DOCS/pages/721303/Tag+Settings

Hi isabella, thanks for the reply. The link to the page is https://www.vancouverislandcamping.net/male-and-female-clothing-size-conversion-charts/ but I believe I may have figured it out. It seems I was misunderstanding how the campaigns worked while reading through the docs. Went back and read them again. I also had to delete all my cached files in the "adserver/var/cache" folder as well as the browser cache in order to see it in action. Now I will continue to read the docs to see if there is a way to show different banners in the different zones on one page for each campaign instead of showing the same banner in all three zones every time the page refreshes. Appreciate your replies much appreciated.

Yes.

Found this error in my log does it have something to do with my issues? [11-Apr-2024 20:03:36 UTC] PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /home/myusername/public_html/adserver/lib/minify/JSMin.php on line 170

While my Revive VAST tags tested successfully using a VAST inspector, I can't get it to work on my Roku Apps? Is it incompatible or am I missing a setting? Anyone have any experience with this or have suggestions? Thank you. Test Inspector used: https://adplayer.pro/developer/vast_inspector

Sorry, what do you mean about sharing the link in private with the web page? Not exactly sure what you are telling me to do. I can provide a link to the live page in question if that is what you mean?

Can you share the link in private with the web page?

Well I tried adding the shortcode for the zone page1Top to the bottom and middle of the page and it shows my banners properly so I must be missing something with setting up zones or how to use multiple zones on one page. But for the life of me I cannot seem to figure out what I am doing wrong. Checked every log I can think of and there doesn't seem to be any security issues or errors. I'll keep looking for a solution until I find it or someone here is able to point me in the right direction.

I have the latest version of Revive Adserver installed on my dedicated server after upgrading from previous version everything went fine with the upgrade. I decided to try having more than one zone per page as more clients seem interested in my site. I created the zones and named them per page: example: page1Bottom, page2Bottom, page1Middle, page2Middle etc. I then added the zone generated invocation code into the appropriate wp custom code block like I did previously for my original zone (page1Top) that has worked for over 2 years just fine. I also placed the shortcode in the appropriate place on the page to call the invocation code. I created the client banners and client accounts than linked them to the new zone but even after 2 days the new zone isn't displaying the ads. My original zone is displaying them just fine. Walked through the troubleshooting docs provided from the Revive Adserver home page links but still not able to figure this out. Anyone else got multiple zones per page to work with wordpress? Also on a side note: I looked at your plugin for wordpress but it hasn't been updated in over 2 years so not sure it is the right choice either. https://www.adserverplugins.com/revive-adserver-in-your-cms/ I know I could use the existing widgets but then I cannot have different zones for individual pages. Thanks for your time.

Why are some people concerned about 3rd party cookies? Introduction In the first 2 articles in this series, we looked at what cookies are, and what the differences are between 1st party and 3rd party cookies, and we looked at how the Revive Adserver software uses both 1st party and 3rd party cookies. In this article, we’ll take a look at the reasons some people give for being concerned about 3rd party cookies. Quick recap of 3rd party cookies As a quick reminder, a third party cookie is created by a system or service on domain B, while it is being used within the context of a website on domain A. The website visitor on domain A sees the content of that site, but also some ‘embedded’ content of the service on domain B. That service could be anything, for example a weather report and forecast, stock market tickers, news headlines, and also advertising. Retargeting in advertising In particular around advertising, people have noticed that things can become a little bit spooky. Let’s assume for a moment that you’re looking to buy a new car. At some point, you visit the website of a car brand to view their lineup. An hour later, on a totally different site, doing something entirely different, you suddenly see ads for that specific car brand, and even the model you looked at. The next day, while visiting yet another site, again, you see these ads for the car brand once again. This could go on for days or even weeks. It almost feels like you’re being followed around the internet, and you can’t shake them off. What is actually happening is a marketing approach called retargeting, although Google (being Google) call it ‘remarketing’. Here’s how that works: The very moment you landed on the car brand website, an advertising system running in an external domain created a 3rd party cookie on your computer or phone, which records the assumed fact that you are interested in buying a new car. Later in the day, when you’re simply reading up on today’s events, the news website happens to be using that very same advertising system for their ads. As a result, the cookie about your car interest is sent along with the ad call. The advertising system has a campaign for the car brand available, and because of the presence of the cookie, some ads for these cars will be displayed on the news pages, instead of just a randomly selected ad for just about anything. The next day, you’re going over the sports news of the night before, and the sports website also uses that very same advertising system. The cookie is still present, and therefore you once again see ads for the car brand. Retargeting is big business Over the years, ad companies have become bigger and bigger, and a few of them dominate the entire advertising landscape. Their ads are literally everywhere. Every time your computer connects with a site or service that shows these ads, you’re likely to see these retargeted ads. If you don’t know about cookies, specifically 3rd party cookies, retargeting can quickly start to feel creepy, as if “they know how you are”. That is – of course – not true, all that’s happening is that the ad system is simply reacting to the presence of a cookie. They have no idea who you are, and for the most part they don’t even care. You once looked at a car website, and that’s interpreted as a signal that you are more likely to be in the market for a new car than somebody else who didn’t look at those cars. Blaming the cookie Over the years, a number of big ad tech companies went completely overboard with their retargeting activities. So much so, that it became a general annoyance to many people. At some point, the developers of Google Chrome – among others – decided that third party cookies were the cause of all these concerns. This is somewhat ironic, because Google has been making huge amounts of money with their retargeting practices all this time. But the scene was set. The third party cookie had to go. The problem is that there are many legitimate and harmless use cases for third party cookies that will be broken in the process (as outlined in the earlier articles in this series). In the meantime, Google (in particular) have been working hard to create their own systems and processes to replace the use of the third party cookie. Their ‘privacy sandbox’ initiative is one of them. And anyone who uses the web while logged in with a Google account is also still being tracked, even without third party cookies enabled. Just think about that time when you searched for something on your phone, and then suddenly saw an ad for that same product or service on your laptop, your tablet, and your desktop computer the next couple of days and weeks. No cookies were involved there, since after all cookies that are created on one device will never be present on any other device. So even after they’ve removed third party cookies completely, Google will still be able to track and retarget anyone with a Google account. What’s next in this series? In the next article in this series, we will be presenting an overview of the features of the Revive Adserver software that will be affected when the corresponding third party cookies are no longer available. Articles in this Series: What are Third Party Cookies? This article explains what a cookie is, and what the difference is between a first-party cookie and a third-party cookie. Read More How does Revive Adserver use Cookies? This article describes how first party and third party cookies are being used by the Revive Adserver software. Read More Why are some people concerned about 3rd party cookies? We discuss the extensive use of cookies for retargeting, causing them to be labeled harmful by some people. Read More The post Why are some people concerned about 3rd party cookies? appeared first on Revive Adserver. [url={url}]View the full article[/url]

Hi Team, I created an in-line ad in revive, is it possible to preroll it in an HTML5 audio tag?

Dear Friends I recently installed and configured Revive for the first time, the version is 5.5.1 But i am not able to see in-line video ad in the banner category. What should i do Naeem

Looking for someone that can do development/support on our instance of the ADS. Willing to pay a contractor. Please reach out and we can discuss.

With nginx it can be done by adding these location blocks: location = /delivery/asyncspc.php {fastcgi_hide_header Set-Cookie;} location = /delivery/lg.php {fastcgi_hide_header Set-Cookie;} Most likely you'd have to also repeat the php configuration (fastgi_pass etc.) inside each block. Also make sure that locations actually match your specific setup.

Is there anything new on the "NEVER deliver from the campaign"? I need this also.

I want to connenct with your DSP. actually i want to show advertise in my web so how could i do this.

How does Revive Adserver use third party cookies? Introduction In the first article in our series on cookies, we explained what a cookie is, followed by an explanation of the difference between first party cookies and third party cookies. This article follows up with a more detailed look at how the Revive Adserver software uses both types of cookies. Revive Adserver uses cookies in 2 areas The Revive Adserver software has 2 major components: The ad management user interface (also often referred to as the admin UI) The ad delivery scripts Each of them uses cookies, but each in a different way. In some cases, the cookies are by definition first party, and in other cases, depending on how the ad server is implemented on a website, the cookies are third party. First party cookies in the Revive Adserver admin UI There is literally just a single cookie involved in the admin UI. This cookie is used to record a session ID, and therefore it’s aptly named “sessionID”. It ensures that once a user logs in, and continues to work in the UI, they won’t have to provide their username and password every time they navigate to the next page. The session ID in itself is just a random value, completely meaningless, unique, and different for every new session. The same user can be logged in on multiple devices, and they’ll have a different session ID on each of the devices. The value of the session ID refers to a row in a table in the Revive Adserver database, and the details of the user’s session (like the timestamp of their last activity) are stored there. When the user logs out, the session ID is discarded, and the corresponding row in the database for the “old” session ID is also deleted. Then a new session ID is generated and stored in the same cookie, but since there is no corresponding database row (because the user is not logged in), it won’t let them access the user interface beyond the login form. In addition, this sessionID is stored in a “session cookie” which means it expires and gets deleted at the end of the user’s session, for example when they close their browser or shut down their computer. When a user logs in and then doesn’t interact with Revive Adserver for a prolonged period of time, the session becomes inactive and the user will have to log in again (resulting in a new session ID as well). And finally, it’s a first-party cookie, so it is not affected by the demise of 3rd party cookies. This particular cookie illustrates an extremely valuable use case for cookies: storing a value (in this case the session ID) so that it is available in the next interaction with the system. This is actually precisely what cookies were designed to do in the first place. How does Revive Adserver use third party cookies? Let’s set the stage for our explanation: Let’s assume that the Revive Adserver software was installed at this URL: “www.adserver.com”. Let’s also assume that the Revive Adserver system is being used to display ads on a website with a different domain, for example “www.website.com”. In this scenario, when you visit the website, and the website contains ads from the ad server, your web browser is dealing with two related but technically separate systems, the website and the ad server. Here is what happens while the ads are being retrieved and displayed: When people visit the site, their browser receives the content from www.website.com. That’s the primary system their browser interacts with. As part of the content of the site, their web browser will also receive one or more javascript code snippets for the actual ads, and these code snippets reference the ad server URL at www.adserver.com. So that’s a secondary system their browser is also interacting with. From the perspective of the browser, and the site it is interacting with, the ads are coming from an external source, so that’s why it’s called a third party. If the ad server tries to create a cookie, that cookie is technically associated with that external third party source, and therefore the cookie is also referred to as a third party cookie. A practical example of the benefits of a third party cookie We’d like to give a practical example of how the Revive Adserver software makes very good use of third party cookies. The software has a feature called geotargeting. It can be used by the ad server to determine if an ad should or should not be displayed for a site visitor, on the basis of their geographic location Let’s imagine that the aforementioned website is operating in North America, so the United States and Canada. One of their advertisers is a supermarket chain operating in Canada, which doesn’t have many reasons to display its ads to site viewers from the US. Geotargeting involves looking up the estimated geographical location of the site viewer in a large lookup table where the location assigned to groups of IP addresses is available. The outcome is a country code, and only if the country code is CA the ad will be displayed. While this is an extremely quick process, it does take a little time and some resources to do so. And this adds up if the ad server is serving many ads to many visitors simultaneously. In order to reduce the computing overhead of such lookups, the ad server can store the country code it found, in a cookie on the user’s device. In the setup we described earlier, where the website is on one domain, and the ad server is on another domain, that cookie containing the country code is technically a third party cookie. If geotargeting is used again later, perhaps for another advertiser, the visitor’s country code is already available in that cookie, so it won’t have to be looked up again. This saves the ad server some valuable time, which in turn improves the overall experience for the site viewer as well. Everybody wins! Why is third-party cookie blocking a problem? Once browsers start blocking the creation of these third party cookies, Revive Adserver won’t be able to store the country code it found for a particular visitor, and so it will need to perform the very same lookup of the IP address for every single interaction of that IP address with the ad server. The outcome is still the same, the ads can and will be targeted to people from the intended geographical locations. It’s just a less efficient process, increasing the costs of operating the ad server, and reducing the speed of rendering the ads on the site. Nobody wins anything, and in fact everybody loses something. Final thoughts This is just one example of how Revive Adserver uses third party cookies in a way that’s both entirely harmless and perfectly useful. There are other, similar use cases where bits of information are stored in cookies in order to make the ad server work more efficiently and faster for the site visitor. In the next article in this series, we’ll dive into the question of why some people are concerned about third party cookies, sparking the movement to get rid of them. We’ll also highlight how some companies are making good use of these concerns for their own benefit. The post How does Revive Adserver use third party cookies? appeared first on Revive Adserver. [url={url}]View the full article[/url]

hi Steve, When you test performance of asynchronous make sure to have ALL your zones using the asynchronous method. The reason is: The asynchronous method sends the actual zone invocation request on DOMContentLoaded. However the synchronous version delays this DOMContentLoaded event. This is also true when the async zone is before any sync zone (like seen in your screenshot) For example if on your PRD site you would add a single zone using asynchronous it would for synchronous zones to load which delay the yellow line (=DOMContentLoaded)

My hosted revive doesn't have a checkbox or a delete box and I can't find a means of deleting a banner from a campaign, am I missing something?

Bonjour, nous avons plusieurs sites wordpress sur lesquelles nous avons configuré des bannières publicitaires REVIVE ADSERVER. Depuis l'installation des bannière les sites sont devenus instables, nous observons des erreurs 500 pendant quelques minutes puis les sites se remettent en marche après, c est vraiment fréquent sur tous les sites qui contiennent des bannières revive ad server. je ne sais pas comment resoudre cela. Merci d'avance pour vos suggestion. Cordialement !

What Are Third Party Cookies? Introduction Much has been said already about the efforts by Google (and other manufacturers and software companies) to get rid of third-party cookies. However, not everyone actually knows what cookies are, and why there’s so much emphasis on their presumed “negative” effects. In a future article, we will describe in more detail how the Revive Adserver software uses cookies. We’ll also explain what the technical consequences are for users of Revive Adserver when third-party cookies get blocked. But in this article we will start by explaining what cookies are, and what the difference is between a first-party cookie and a third-party cookie. What is a cookie? Cookies are small pieces of data stored on a user’s device by websites. They help websites remember information about a user’s visit, such as their preference for light or dark mode, or their location to be used for the weather forecast. A cookie is not a program, it doesn’t do anything by itself. It is just a bit of data, and it just sits on your device, waiting to be read in the future. Frequently, cookies also have an expiration date, meaning that after the expiration date they will automatically be removed. Some cookies are even “session based”, meaning that as soon as you close your web browser or shut down your computer, they automatically disappear. What is a first-party cookie? Imagine placing an order at your favorite coffee place. After completing your order, the barista hands you a button to be worn on your clothing. It mentions your favorite coffee flavor, to save you the trouble of mentioning it again next time you go for coffee. Next time you come in, the barista can just take a quick look at the button, so they already know what your preferences are, and prepare your favorite coffee before you even get to a seat. For this imaginary button, it is important to mention that only the barista in that one coffee place can see and read the button. In any other store or shop, it is simply invisible, for all intents and purposes it does not exist. That’s similar to a first-party cookie. It’s a piece of information stored on your own device by a website you’re visiting. This cookie helps the website remember things like your preferred language settings, dark of light mode, and so on. It’s specific to that website and doesn’t share information with anyone else. It is stored on your own device, it doesn’t actually leave any trace on the site’s server at all. So, the next time you visit, the website already recognizes you because your device shows up with the cookie and the data in it, and then personalizes your experience based on your known preferences, just like remembering your favorite flavor in your coffee place. What is a third-party cookie? Now, imagine that another business, like a dry cleaning service, has an employee stationed at the coffee place. You can drop off your dry cleaning with them, and you can pick it up again once it’s ready. The dry cleaning employee can also hand you a button, this time with a discount code on it for future cleaning services. If you come back to the coffee place in the future, with a new item to be dry cleaned, the staffer can glance at the button and know that you qualify for the discount. And on top of that, if you ever enter any other store where the same dry cleaning service is also present, those staffers can also see your button and give you the discount. The button can only be seen and read by dry cleaning staff, nobody else will even see it, not the coffee store and none of the other customers there. Most likely, the dry cleaner won’t even know where you first received your button. This is similar to a third-party cookie. It’s created by a site or service that’s different from the website that you’re actually visiting. For example, while browsing a news website, an external weather service might set a cookie to store the geographic location you’ve specified. This allows them to display the weather information for your town when you visit the news site again in the future. Unlike a first-party cookie, this third-party cookie is not specific to the news website. If the same weather service is used on other sites, your location is already noted and you will see weather information for your location automatically on those other sites as well. Final notes These are not perfect analogies, by the way, because a cookie is only available on that one specific device where it was first created. Imagine you have a laptop and a tablet. A cookie that gets created on your laptop does not exist on your tablet, nor the other way around. That’s true for both first-party and third-party cookies. In the next article in this series, we will give you some examples of how the Revive Adserver software uses first-party cookies, and how it uses third-party cookies. The post What Are Third Party Cookies? appeared first on Revive Adserver. [url={url}]View the full article[/url]

Hello everyone, I am a beginner user. Currently, I want to use revive adserver to create landing pages for my website, but I don't know how to create them. Please help me.

Hi you all, i've been observing a difference data between global statistics and the total of my campaigns, in february in global i have 10.791.575 impressions but in campaigns, the total is 7.286.117 impressions, the clics are the same. I don't know why. Can you help me? Thx a lot.