Revive Adserver Forum

Your Language Matters: Help Revive Adserver Go Multilingual! Summary: Revive Adserver expands language support! Dutch, German, and Italian are complete, with others nearing completion. Community contributions drive this multilingual growth. We need your language skills! Join as a translator or proofreader at our platform. Help make Revive Adserver globally accessible. Go to Translations website... Your Language Matters: Help Revive Adserver Go Multilingual! We want to highlight one of the key strengths of Revive Adserver: its robust multilingual capabilities. As an open-source platform, Revive Adserver thrives on community contributions, and language support is a shining example of this collaborative spirit. We fully realize that a user-friendly interface in everyone’s native language can significantly enhance their experience. That’s why the Revive Adserver software has always had the built-in capability to be translated into any language. Today, we’re delighted to announce that Dutch, German, and Italian translations are already fully completed and available! But we’re not stopping there. Our user community is also making great strides in translating Revive Adserver into several other languages. We’re excited to report that Indonesian, Persian, French, and Spanish translations are nearing completion. This means that even more users worldwide will soon be able to leverage the power of Revive Adserver in their preferred language. There are also numerous other languages that are partially translated, and waiting for community members to add their local knowledge and language skills. Join the Translation Effort! We believe that everyone should have the opportunity to benefit from Revive Adserver. That’s why we’re calling on community members to help us expand our language support even further. Do you speak a language that’s not yet fully translated? This is a fantastic opportunity to contribute to the open-source community, even if you don’t have programming skills. Your language expertise can make a real difference! We’re looking for: Initial Translators: Help us get started by providing the first translations for your language. Proofreaders: Help us ensure the accuracy and fluency of existing translations. The translation system we use, called Crowdin, offers advanced functionality including the ability to make use of automated, machine translations. So in many cases, it might be sufficient to simply review a proposed translation and make minor modifications. Ready to get involved? Visit our translation platform at https://translations.revive-adserver.com/ to see which languages still need your help. You can easily contribute your translations and become a valuable part of the Revive Adserver community. By working together, we can make Revive Adserver a truly global platform, accessible to everyone, regardless of their language. Let’s break down language barriers and empower digital advertising worldwide! Go to Translations website... The post Your Language Matters: Help Revive Adserver Go Multilingual! appeared first on Revive Adserver. [url={url}]View the full article[/url]

How Revive Adserver is affected by blocking of third party cookies Introduction In the previous articles in this series, we started by explaining what third-party cookies are, next we discussed at a high level how the Revive Adserver software uses third-party cookies, and then we discussed why some people are concerned about third-party cookies. This article explains what the effect on the Revive Adserver software is, when browsers no longer allow the creation of third party cookies. The developers of Google Chrome have announced that they’re phasing out support for third-party cookies in their browser, although the deadline for the complete phase-out has been shifted several times. In this article, we’ll have a closer look at the way the Revive Adserver software is impacted when third-party cookies no longer work in a browser. We’ll go over each of the types of cookies that exist in the context of Revive Adserver, what their purpose is, and what the effect on the end-user experience and the ad server functionality is if that cookie type gets blocked. The names of the cookies start with either OA or OX, which refers to OpenAds and OpenX respectively. These are the names that were used in the past for the software that is now known as Revive Adserver. We’re going to discuss all the cookies grouped by functionality, more specifically the cookies used for frequency capping of campaigns and banners, for frequency capping of zones, for delivery blocking, for conversion tracking, and for miscellaneous other purposes. Please note that what follows is not intended to be a detailed technical description of how every type of cookie works in the code. To keep this article understandable and relatively brief, we’ve simplified the description a bit, so that we can keep this accessible to as many readers as possible. Frequency capping for campaigns and banners In order to perform frequency capping for campaigns and banners, the Revive Adserver software uses 4 different types of cookies: OACAP: these cookies are used to store the data for frequency capping of a banner. These are permanent cookies. OACCAP: these cookies are used to store the data for frequency capping of a campaign. These are permanent cookies. OASCAP: these cookies are also used to store the data for frequency capping of a banner, but only for an individual browser session. They are deleted as soon as the browser is closed or the duration of a session expires. OASCCAP: these cookies are also used to store the data for frequency capping of a campaign, but only for an individual browser session. They are deleted as soon as the browser is closed or the duration of a session expires. The purpose of the cookies used for frequency capping is to limit how frequently a specific banner, or all the banners of a campaign, can be displayed, for example at most once per 15 minutes. Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to respect the frequency restrictions that have been defined for campaigns and/or banners. As a result, the Revive Adserver software won’t display banners that have frequency capping defined (either directly or at the campaign level). This is because it has been designed to be conservative when cookies can’t be created for whatever reason. Frequency capping for zones In order to perform frequency capping for zones, the Revive Adserver software uses 2 different types of cookies: OAZCAP: these cookies are used to store the data for frequency capping of a zone. These are permanent cookies. OASZCAP: these cookies are used to store the data for frequency capping of a zone, but only for an individual session. They are deleted as soon as the browser is closed or the duration of a session expires. The purpose of these cookies for zone frequency capping is to limit how frequently a zone can be displayed, for example at most once per 15 minutes or only on the first view in a session. This feature can be used, for example, to expose a high impact zone (like one that is very large at the top of a site’s page design) less frequently in order to improve the visitor experience. Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to respect the frequency restrictions that have been defined for zones. As a result, the Revive Adserver software won’t display any banners in zones that have frequency capping defined. This is because it has been designed to be conservative when cookies can’t be created for whatever reason. Delivery blocking In order to prevent the delivery of a banner more than once on a single page, or even the delivery of another banner from the same campaign on a single page, the Revive Adserver software uses 2 different types of cookies: OABLOCK: these cookies are used to store the data that a specific banner has been displayed on a page OACBLOCK: these cookies are used to store the data that a banner from a specific campaign has already been displayed on a page. OABLOCK and OACBLOCK are permanent cookies, but they expire automatically after 30 days. Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to respect the defined blocking rules for banners or entire campaigns on a single page, meaning that a banner could appear multiple times on a page. Visitors will be able to notice this change, banners that showed up only once on a single page can now appear multiple times on that same page. If the web developer uses the ‘asynchronous javascript’ invocation code in order to display the ads on the page(s), delivery blocking will still work even without third party cookies, because this type of invocation code performs the ad selection process for all zones in a single process, without the need for cookies. Conversion tracking In order to perform conversion tracking, the Revive Adserver software uses 2 types of cookies, for 2 types of conversion attribution respectively: OXLIA: these cookies are used to store the timestamp of the last time a particular banner was viewed. LIA stands for Last Impression Attribution. OXLCA: these cookies are used to store the timestamp of the last time a particular banner was clicked. LCA stands for Last Click Attribution. The purpose of these cookies is to determine if a “conversion” can be attributed to either the last time a banner was viewed or the last time a banner was clicked. At the time of the conversion event, the Revive Adserver software will look for the relevant cookies and the timestamp recorded in them. If the timestamp is within the duration of the conversion window that was defined, the conversion is considered to have occurred and it is marked to be attributed to the specific banner. If the campaign that the banner is part of does not make use of conversion tracking, these types cookies will not be created. But if they are created, both OXLIA and OXLCA are permanent cookies, meaning that they will not be removed when the browser is closed. However, they do expire if they’re not updated for a period of 1 year. If the campaign that the banner is part of does not make use of conversion tracking, these types cookies will not be created. But if they are created, both OXLIA and OXLCA are permanent cookies, meaning that they will not be removed when the browser is closed. However, they do expire if they’re not updated for a period of 1 year. Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to store the timestamps for the last impression and/or the last click on a banner, and as a result the ad server will be entirely unable to perform conversion tracking. Visitors will not notice any difference in their interaction with the ad server, this will only have an effect on the conversion statistics. Miscellaneous uses OAGEO This cookie stores the geographic location of the visitor’s device. The location is determined by taking the IP address of the incoming request and performing a lookup in the MaxMind GeoIP2 or GeoLite2 data files. This will return location indicators like country and city. The purpose of this is to be able to use the location that’s established during the first interaction between the ad server and the visitor in subsequent interactions. This improves the loading speed for the visitor and it reduces the burden on the ad server by preventing lookups on every single interaction. OAGEO is a session cookie, meaning it is deleted when closing the browser. Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to store the established location in the OAGEO cookie, and as such it will have to perform the lookup on every single interaction. From a functional perspective, this won’t make a difference to the end user experience, but it does come with the disadvantage of increased loading times on subsequent visits and with increased load on the ad server. It is unlikely that visitors will notice this change, but it might have a measurable impact on overall page loading speeds. OAID This cookie doesn’t have any specific purpose in the core Revive Adserver software at this time. In fact, since version 4.1.4 of May 2018, this cookie is given the value 01000111010001000101000001010010 for any and all visitors. This is the binary representation of the acronym GDPR. The cookie has been left in place in the code in order to avoid unintended consequences of completely removing it, for example for third party plugins that might still be using this cookie. From the perspective of the Revive Adserver software itself, blocking of the OAID cookie by browsers will not have any impact (negative nor positive) on the system. Visitors will not notice any difference in their interaction with the ad server. OXBLC The Revive Adserver software can be configured to ignore multiple clicks on a specific banner in a specific zone. The click will still work and the visitor will be redirected to the landing page, but it simply won’t be counted. This setting was introduced in 2008 when it was noticed that visitors had a habit of double clicking banners because that is what they were used to on their desktop operating system like Windows. This setting is disabled by default. These cookies are used to store the timestamp of the last time a particular banner in a particular zone was clicked. If the next click occurs within the timeframe for ignoring click-counting, the click will not be logged before redirecting the visitor. Once browsers start blocking third party cookies, the ad server will no longer be able to record the timestamp of a click, and therefore it won’t be able anymore to respect the setting to not count multiple clicks within the specified time. Visitors will not notice any difference in their interaction with the ad server, this will only have an effect on the statistics. Conclusion As described above, the impact of blocking third party cookies in the Revive Adserver software is significant. This affects all installations where the ad server is on a domain that’s separate from the domain of the website where the ads are being displayed, which is a very common practice for reasons of performance and scalability. It’s also a very common way of displaying ads from a single ad server system to a group of websites owned and operated by one or more companies. Looking at the functional description of the uses of cookies, we feel that it is reasonable to say that these use cases for cookies are benign and do not violate the privacy of site visitors. The Revive Adserver software is technically incapable of the practice of “following people around across the entire world wide web” that many people dislike, a practice that has been widely adopted by big companies like Google and Facebook. It is ironic that Google has now decided to start banning third party cookies for exactly this reason. Independent and harmless applications like Revive Adserver suffer from this move. What’s next in this series? In the next article in this series, we plan to discuss how we can partially address the impact of reduced functionality by the blocking of third party cookies by browser developers. 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 How is Revive Adserver affected by blocking third-party cookies? We look at the effect on the Revive Adserver software, when browsers no longer allow the creation of third party cookies. Read More The post How Revive Adserver is affected by blocking of third party cookies appeared first on Revive Adserver. [url={url}]View the full article[/url]

Display Banners Fast – A Technical Paper The Revive Adserver project team is excited to announce that community member Tim Vereecke has contributed a detailed and well researched technical paper. His paper addresses four major areas of optimizing the delivery performance of banners on a website: Time to Ads (TTA) Largest Contentful Paint (LCP) Cumulative Layout Shift (CLS) Delayed Page Content Tim is the owner of a large website about scale modelling, called Scalemates. The ads on the site are managed and delivered using Revive Adserver. Based on his extensive expertise and years of hands-on experience since December 2010, he presents his findings, recommendations, and best practices for Lightning Fast Display Banners in his technical paper. We want to express our thanks to Tim for dedicating a significant amount of time to researching and writing his paper, and we hope that our community will benefit from his contribution. Read the Tech Paper... The post Display Banners Fast – A Technical Paper appeared first on Revive Adserver. [url={url}]View the full article[/url]

Response to CVE-2023-26756 We reject the assertion of a vulnerability in Revive Adserver, as is claimed in CVE-2023-26756. We are convinced our application offers sufficiently powerful tools against brute force attacks. We’ve posted a full response in the Security section of our website. Read more... The post Response to CVE-2023-26756 appeared first on Revive Adserver. [url={url}]View the full article[/url]

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]

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]

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]

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]

We just released Revive Adserver v5.5.1 The new version 5.5.1 of the Revive Adserver software contains fixes for a number of small bugs and inconveniences that have been identified after publication of v5.5.0. Changes in v5.5.1 of the Revive Adserver software: We fixed an issue preventing username and password from being always requested during upgrades from 5.3.x and older versions. Running an upgrade with an active logged-in session on the browser could result in the admin account requiring a password reset at the next login. We fixed an issue with non-ASCII (e.g. accented) characters not being properly encoded when sending e-mails. We fixed an issue with the CLI installer not setting permissions properly. We removed legacy checks for register_argc_argv being enabled. In fact it is recommended to keep it disabled ony SAPI, other than “cli”, for security reasons. We removed references to safe_mode, which has been removed from PHP a long ago. We fixed a fatal TypeError being triggered during delivery under some circumstances. We fixed a potential out of memory error during maintenance in case of database issues. We added proper escaping when displaying custom application name and UI colour settings. Full release notes for v5.5.1 can be found on our Github page. Download, install and upgrade Revive Adserver v5.5.1 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. 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.1 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

The Future of the Revive Adserver open source project with Aqua Platform Following the announcement of Andrew Hill’s departure from the Revive Adserver open source project, and the subsequent announcement of the transfer of the Revive Adserver open source project to Aqua Platform, here are some remarks by the joint teams about the future of Revive Adserver. Addressing Community Concerns Understanding that such a transfer might raise concerns within the community, the teams involved in this process want to assure users and contributors that this move is driven entirely by a shared commitment to the project’s sustained success. The consolidation of activities into Aqua Platform is not a departure from community-driven open source principles, but rather a strategic move to ensure the project’s long-term viability. A History of Collaborative Success It’s crucial to acknowledge the longstanding collaboration between Aqua Platform and the Revive Adserver project. Aqua Platform has been a dedicated contributor to the project for many years, providing valuable insights and enhancements. Their involvement has extended to operating the entire backend of the Revive Adserver Hosted edition since its inception in 2018. Over time, an increasing overlap of activities and team composition has unfolded, triggering a discussion about the joint future, and ultimately leading to the agreement to consolidate all project activities under Aqua Platform’s purview. Continued Focus on Development and Maintenance Software development is a complex and resource-intensive endeavor. The transition to Aqua Platform ensures a prolonged stable financial foundation, mitigating the challenges associated with sustaining ongoing development efforts. This move underscores a commitment to the longevity and vibrancy of the Revive Adserver project. Aqua Platform’s Invaluable Expertise As a hosting company with hands-on experience managing enterprise-scale Revive Adserver installations since 2015, and founders that have been part of the community for 2 decades, Aqua Platform has been injecting a wealth of knowledge and expertise into the project. This firsthand understanding of the software’s intricacies positions Aqua Platform as an ideal steward for the continued growth and improvement of the Download edition. Financial Sustainability for Development Recognizing the financial demands of software development, the support from Patreon sponsors will be exclusively directed towards funding the ongoing development of the software. Aqua Platform will cover the remaining costs, in part from the revenues generated with Revive Adserver Hosted edition, and the rest coming from Aqua Platform’s own business activities. This collaborative approach ensures a sustainable future for the Revive Adserver Download edition. A Bright Outlook for Users In summary, the continuation of the Revive Adserver open source project under the umbrella of Aqua Platform heralds a new era. Users can rest assured that the software’s development and maintenance remains well-supported, thanks to the long term financial stability brought about by Aqua Platform. The synergy between Patreon sponsors and Aqua Platform creates a model where user support directly contributes to the advancement of the software. The post The Future of the Revive Adserver open source project with Aqua Platform appeared first on Revive Adserver. [url={url}]View the full article[/url]

Andrew Hill is leaving the Revive Adserver project team Farewell to Andrew Hill, Architect of Revive Adserver’s Success It is with mixed emotions that we announce Andrew Hill’s departure from the Revive Adserver project team. Andrew has played a pivotal role since 2013 when he spearheaded the acquisition of the open-source code from the previous maintainer. Under his guidance, we successfully launched Revive Adserver in September of that year, marking a new era for the project. Andrew’s commitment to the project has been unwavering, contributing tirelessly for over a decade. His expertise and dedication have been instrumental in the project’s growth and success. In 2015, he demonstrated his entrepreneurial spirit by creating a successful Patreon program, securing crucial support for the project’s ongoing development. In addition to his technical contributions, Andrew invested countless hours in enhancing the documentation website, ensuring that users could navigate and implement the software seamlessly. His active involvement in the community forums reflected his commitment to fostering a supportive and collaborative environment. All the time, energy, and inspiration he invested in the project has brought it to where it stands today, and we couldn’t have achieved this without him. However, in recent years, Andrew has been increasingly prioritizing family, personal pursuits, and other professional endeavors. After careful consideration, he has made the difficult decision to step away from the project. We express our deepest gratitude for Andrew’s invaluable contributions to the documentation website, community forums, and overall project development. We commend his warm and positive style of team play, and his impact on the project and the team will be lasting. We wish him the very best in all his future personal and professional endeavors. The post Andrew Hill is leaving the Revive Adserver project team appeared first on Revive Adserver. [url={url}]View the full article[/url]

Celebrating the 10th Anniversary of Revive Adserver A Decade of Collaboration and Dedication: Celebrating the 10th Anniversary of Revive Adserver It’s with great joy and pride that we celebrate the 10th anniversary of the Revive Adserver open source project. In an era of dominance by big tech, Revive Adserver has stood the test of time, emerging as an independent, powerful and versatile tool that empowers countless publishers, advertisers, and developers. Let’s take a moment to reflect on this remarkable journey and the impact it has had on the world of online advertising, and to look forward to the future. The Genesis In 2013, our project was born out of the realization that there was a continuing need for a reliable, flexible, and cost-effective ad serving solution that does not rely on huge corporations. Building upon the legacy of OpenX Source and phpAdsNew, our passionate developers set out to maintain and continue developing the free and open-source alternative that would democratize the world of online advertising. We named it Revive Adserver. Our vision was to provide a robust platform that could suit the needs of individuals and organisations of all sizes, and in all corners of the world. The Evolution Over the past ten years, Revive Adserver has proven to be a comprehensive, yet easy to use, ad management system with a global community of users and contributors. With regular updates, and improvements, Revive Adserver has remained a significant force in the ever-changing landscape of digital advertising. Key Milestones International Reach: Revive Adserver enjoys international recognition, thanks to its multi-language support and active global community. Security and Privacy: In an era of increasing concern for user privacy and data security, Revive Adserver has continuously improved to align with industry standards and regulations. Since the software is entirely open source, anyone can investigate the source code, and make sure that it is a safe and secure product. Community Engagement: The active community of users and developers has been at the heart of Revive Adserver’s success. Their feedback, contributions, and support have been invaluable. Into The Cloud: in 2018, on our 5th anniversary, we announced the Revive Adserver Hosted edition, a software-as-a-service offering based on the exact same software that was already available as a Download edition. Since then, many hundreds of individuals, small businesses, and also larger companies and even huge global corporations have subscribed to the service. The Impact Revive Adserver has democratised digital advertising by giving individuals, non-profit organisations, and companies of all sizes, access to a powerful ad serving platform, without having to share their data (and that of their site visitors) with big tech companies. It has enabled publishers to monetize their content effectively, and advertisers to reach their target audience efficiently. By providing a transparent and open-source alternative, Revive Adserver has contributed to the sustainability and diversity of the online advertising ecosystem. The Past, Present, and Future As we celebrate the 10th anniversary of Revive Adserver, we look back at a remarkable journey marked by dedication, and a strong commitment to open-source principles. It’s a testament to the power of collaboration and the enduring impact of a project that aims to make online advertising software accessible to all. We look forward to playing our part in the next decade of growth and evolution, confident that Revive Adserver will continue to be at the forefront of open source digital advertising solutions Here’s to the past, present, and future of Revive Adserver – a beacon of open-source success in the world of online advertising! Happy 10th anniversary! The post Celebrating the 10th Anniversary of Revive Adserver appeared first on Revive Adserver. [url={url}]View the full article[/url]

Revive Adserver v5.5.0 released  Revive Adserver v5.5.0 released Sponsor of this release: We’re proud to release version 5.5 of the Revive Adserver software. This version introduces support for the VAST2 standard for video ads, an extension of the support for video ads that has been part of Revive Adserver for many years. This was made possible by a generous donation from Aqua Platform, the company specializing in enterprise grade hosting of the Revive Adserver software. Aqua Platform donated the VidiX plugin, their commercially available product, to be included as a standard, free component of Revive Adserver. Many thanks to Aqua Platform for their continued support of our project. Version 5.5 also contains a number of bug fixes and a small security improvement. Please continue reading these releases notes for the full details.  New features and functionality in this version Version 5.5 of the Revive Adserver software contains a number of new features: We bundled the VAST2 Enhanced Video Ads plugin, enabling support for this IAB video ads protocol. This unlocks the ability to create video ads that – in turn – consist of VAST2 tags from third-party applications, and it also enables the user to generate VAST2 tags that can be used in any VAST2 compliant video player or in any VAST2 third-party ad serving system.  Improvements and enhancements in this version We added experimental command line install / update scripts, enabling system administrators to install or update the software from the command line. This functionality is for experienced sysadmins only and should – for the time being – only be used on test and staging environments. Documentation on how to use these scripts is forthcoming.  Bugs fixed in this version This version of Revive Adserver fixes a number of bugs: We fixed an issue preventing plugin hook “addUrlParams” from being called when generating click URLs since the introduction of the signed clicks functionality. We fixed an issue preventing click-based conversion tracking from properly working. We fixed an issue preventing password recovery from working properly when using a Postgres database. We added a missing check for the tokenizer PHP extension during install and upgrade. We fixed the zone delete action being always displayed regardless of the actual permissions. We fixed the “Export Statistics to Excel” functionality so that the link is only disabled when the selected range has no statistics at all. We fixed usage of specific charset with SPC (single page call) on local invocation. We fixed an uncommon issue preventing maintenance from properly completing in edge cases.  Non-Backward Compatible Changes This version of Revive Adserver has a non-backward compatible change: We removed support for creating new inline video ads using FLV type and/or streaming format. Backwards compatibility for delivery is retained, meaning that banners that were created with older version and that still exist in the database will continue to work.  Security improvements This version of Revive Adserver contains a fix for a very low risk security issue that was reported to us through our HackerOne program. We’ve posted a security advisory on this issue.  Contributions by community members We would like to thank the following community members for their contribution to this release: @kavit-gangar – #1428 @archiewestermann – #1420 @spantaleev – #1399 @pmacko – #1426 @camlafit – #1403  Download Download Revive Adserver v5.5.0 from our Library h Install How to install Revive Adserver on your own server h Update How to update Revive Adserver to a new version  Revive Adserver Hosted edition If you’d like to take advantage of all the features and benefits of the Revive Adserver software, without having to take care of the installation on your own server, software updates, and performance tuning, we’d like to suggest having a look at Revive Adserver Hosted edition. For a modest monthly fee, we’ll take care of all the technical work, all you have to do is log in and get started. The post Revive Adserver v5.5.0 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

If you're not subscribed yet, but are planning to, see https://www.revive-adserver.net/blog/elite-pricing-plan-for-hosted-edition-features-and-benefits/ for details on the Elite pricing plan.

We have no record of anyone with your email having a subscription at Revive Adserver Hosted edition.