Adhese Gateway and Direct Ad Server
Gateway and Ad Server function entirely server-side and keep all client implementations as simple as possible to avoid exposing business rules and configuration. This allows for easy integrations in many different platforms and devices without the need for complicated development.
Once implemented, no further client-side changes are needed. Publishers can activate new demand sources, add or shape the data they share with their partners, set business rules, multipliers and even exceptions through a centralised web application. These changes are executed instantly and do not need any intervention from web admins or app developers.
Implementing for using Gateway features or Direct Ad Server features is the same. Below you can find links to the various repositories with examples and code.
Libraries & SDKs
Gateway is available as a Bidder for both Prebid.js and Prebid Server and has been used in various custom wrappers made by publishers pr SSPs.
Prebid.js Bidder on prebid.org
Prebid Server Bidder on prebid.org
Native Mobile SDK
An open-source native Android and iOS SDK are freely available. Mobile apps can implement the Adhese instance as a pure API and give them full control over the user experience.
Adhese for Android on github.com
Adhese for iOS on github.com
Any publisher can implement their Adhese instance as a pure API, calling the ad server endpoints directly from their mobile app, CMS system, Connected TV app, ... In one request, they receive campaigns for several placements that can be visualised according to the device and context.
Detailed documentation is available at API Documentation.
There are several ways to integrate the Adhese ad tag into your platforms:
- The most common implementation method: JSON or JSONP.
The JSON or JSONP method bundles all advertisements in one request and visualise the creatives in the reserved spots on your website. With this method, it is easy to consider when an ad has an actual change to be seen (‘viewability’). JSON or JSONP is the most suitable method to use in a responsive environment.
- Classic or legacy method: tag.js
document.write instruction on the implementing page.
You can find examples on the Implementation of the Adhese Ad Tags page.
Migrating your old ad server to Adhese
Migrating from an existing ad server to Adhese can be accomplished in various ways, depending on the customer's requirements.
One approach is to focus on getting the Adhese tags up and running. Based on the inventory setup, all tags are made available. Existing tags of the legacy ad server can be implemented in Adhese as a standard campaign, serving the legacy tags as third-party ads. One hundred per cent of the inventory is sent to these campaigns to provide continuity. New campaigns are booked in Adhese and, if necessary, can take priority over the legacy tags. Eventually, the legacy campaigns stop running as no more traffic is needed, and all new or updated campaigns are booked in Adhese directly.
Another approach is to postpone tagging and start booking new campaigns in Adhese. Adhese tags or third-party tags can then be uploaded to the legacy ad server. You can do this on a per-campaign basis or send 100% of traffic to these Adhese campaigns in the legacy system. As tags are being distributed across the customer's network, they will show the same Adhese creatives but are either called directly through the Adhese tags or passing through the tags of the legacy ad server.
Be the first to like this