This service is only available for Hoppex members. Please, contact them directly.

EasySSP serving in the Adverticum AdServer

The EasySSP function has been issued in the Adverticum AdServer. This makes easier the programmatic sales process because our clients can manage all of their campaigns – including RTB ones – at the same interface.

EasySSP in the Adverticum AdServer

For using the EasySSP function two conditions are to be met: first, an adexchange platform connecting to Adverticum on API level. This is the system of Rubicon Project. Secondly, users need an access to the EasySSP function. Our colleagues enable this function to a certain customer.

Before using the EasySSP function, it is necessary to create a profile, zones and insert site data in the Rubicon system which are intended for the adexchange platform. The created ID-s have to be used in the Adverticum EasySSP system to run the RTB campaigns. We suggest using those tags which are in Rubicon, inside the Inventory Setup menu in the TAGS list. Here are all ID-s at the same place.

Site details 

The Rubicon specified sets and the Site data need to be given in the EasySSP menu.

• Site name: the name of the site in Rubicon. Required field.
• Short description: a short description of the site in Rubicon.
• Description: a description of the site in Rubicon.
• Page URL: the URL of the site in Rubicon. One URL can be given by default. It is not required. If the user gives an URL, the system will automatically forward it to Rubicon. If it is not given, the URL collected by Goa3 will be forwarded.
• Site ID: the Site ID in Rubicon [rp_site]. It can extract from the Site Tags. Required field.
• Account ID: the Account ID in Rubicon [rp_account]. It can be extracted from the Site Tags. Required field.
• Domain: the Domain of the publisher in Rubicon.
• Language: default language of the site in Rubicon.
• Keywords: unique keywords can be sent to Rubicon. Basically, the Goa3 reads the keywords of the certain site and forwards it to Rubicon. If it is given, both will be forwarded to Rubicon.
• RTB categories: IAB categories. These can be chosen from a list.
• Forwarded variables: Publishers can share their targeting variables with Rubicon in real time. For further information please visit this site. 

 Important! URLs and domains set in ’Page URL’ and ’Domain’ fields have to be present amongst the sites in Rubicon.

 Attention! With leaving non-compulsory fields empty the system will take into consideration the settings in Rubicon.

Campaign settings for the EasySSP serving

We extended the opportunities of the AdServer campaign settings with RTB specified functions so the system can serve EasySSP ads. The Rubicon zone is to be added as an RTB Banner, but the user can give certain parameters on the zone level as well.

 Important! Only campaigns of the ‘current player’ advertisers can have RTB banners. It applies to campaign and banner copying as well.

Creating an EasySSP goal

To decrease the number of potential errors and for further functionality, the price type for the goal must be given by the Set price field. The user can decide whether the price will be used (Yes) or not (No) and the type of them: price priority and RTB are also options.

 Attention! If ’Not’ is set, the price belongs to the campaign will be applied. This can be modified after saving.

If the RTB option is chosen, the RTB specific settings will be available.

• Bidfloor: the minimum bid price can be specified in USD (Floorprice). It is not a mandatory field, in this case, the value will be „null” and can be modified on the banner. If it is not given, that value will be applied which was defined in Rubicon.

 Important! If Bidfloor is set at the banner, that price will be applied. There is also an option, Ignore Bidfloor, which causes the system to ignore this setting in Adverticum and to use the value given in Rubicon. (If this option is chosen, bidfloor will be ignored either it is given on the banner or on the goal.)

• Bidorder: it specifies the sending sequence of the goals on the same priority level toward Rubicon. First, the system will consider the Bidorder value recorded on the RTB goal. If the Bidorder values are the same on the goals, a further sequence can be given on the RTB banner. If the Bidorder is the same on every banner, or not given, the order of the requests will be defined randomly before sending. Bidorder is only applicable on goals, banners with the same priority levels (zone-goal priority, and zone subpriority).

 Attention! With leaving non-compulsory fields empty the system will take into consideration the settings in  Rubicon.

 Attention! If RTB goal is used, the Price priority settings will not be taken into account.

 IMPORTANT!

• RTB and non-RTB banners cannot be assigned to one goal at the same time. In such cases, only RTB banners will be served!
• RTB banners can only run in goals and zones with RTB settings!

RTB banner creating

•  Attention! RTB banner can be recorded only for those campaigns which are created by your own advertiser. This is valid for campaign and banner copying as well.

The parameters of the RTB banner are the following:

• Name: the name of the banner. Required field.
• Description: description of the banner.
• Short description: a short description of the banner.
• Zone ID: the ID of the zone in Rubicon [rp_zoneID]. Required field. It can be extracted from the Site Tags, from the value of the rp_zonesize before the dash.
• Banner size: the required size of the RTB banner (width and height). These are predefined and adjusted to those values which are set in Rubicon. It can be chosen from a list, maximum three sizes for a banner. There is the Rubicon ID before the name, which can be extracted from the rp_zonesize after the dash.
• RTB Site: Sites given on EasySSP tab are choosable from a list. This object will assign the site-specific settings to the RTB zone on the banner. These will be automatically sent to Rubicon.
   Important! Choosing the wrong site to the RTB banner will result in sending wrong values to the SSP system and no answer will be sent back.
• Ignore Bidfloor: by clicking the checkbox, the system will ignore the minimum bid price and take into account the value set in Rubicon.
• Bidfloor (USD): the minimum bid price can be specified in USD (floorprice). This overwrites the value defined for the goal. If it is not given, the value will be applied which was defined in Rubicon.
   Important! Bidfloor and Ignore bidfloor options given at banner level will be applied.
• Allow Interstitial: by clicking the checkbox the RTB Interstitial display from Rubicon is enabled. Works only if the setting is also chosen on the RTB zone.
• Display: RTB

The actual Bidorder and Bidfloor values can be reached in the Goal/Banners list.

The banner will inherit the Bidorder given by the RTB goal, but it can be modified in the list.

To finalize the new setting they have to be saved by using the appearing “Save changes” button in the Goal/Banners list.

 IMPORTANT! The banner’s Bidfloor only can be set at the details of the goal, or at the details of a banner. In the Goal/Banners list, it is not possible.

 IMPORTANT! The Bidfloor value appearing in Goal/Banners list will be forwarded to Rubicon.

Zone settings

To run an RTB campaign in a certain zone, it is necessary to enable the RTB function on the zone as well (Yes/No). Here can be defined if the zone is to take part in the EasySSP serving or not.

RTB specific settings on a zone are:

• RTB: Yes/No are the options. If Yes is chosen, the further RTB parameters will be available. Required field.
• Allow Interstitial: by clicking the checkbox, the RTB Interstitial display from Rubicon is enabled. It must be activated on the banner as well otherwise this setting will not be applied.
• Position: zone position. It indicates where the zone is located on the site. Required field.
• Display type: to make the display settings easier, the RTB display type must be chosen in case of RTB zone. Required field.

 Attention! In a zone with RTB settings, both RTB and non-RTB goals and banners can appear.

RTB zone compatibilities:

Size:

• If more than one size is chosen at the banner, in the banner lists only the first one will appear and this value will be taken into account when the “Filter for banners” options is turned on. However, if there is any size at the banner that is compatible with the zone, the assignment’s status will be “Good”, in case there isn’t any compatible banner sizes the status will be “Bad”.

Display:

• It is important to keep in mind that in the process of status counting only the display setting matters. If the zone doesn’t have RTB display it won’t be compatible with an RTB banner or goal. However, if the zone has RTB display, but has no RTB setting, it will be marked as compatible in the status but won’t work in live serving.

Competing goals with Price Priority settings in Adverticum with banners arriving from the SSP system, in consideration of commission and exchange rate calculation

With the EasySSP service, we provide a solution for serving ads from Rubicon SSP system and competing them with other price prioritized campaigns, striving for the highest income.

It's in the Publishers interest to have a higher income than with a usual campaign in Adverticum by using the SSP system even after paying commission to Rubicon. To achieve it is necessary to consider the fee of the SSP system besides the highest value of goals in a zone when comparing prices.

Counting with 18% commission of the ads' prices, we must send the price to the SSP system with a 1.219512 multiplier, so the served banner will provide more income even after paying the commission.

An example:

Let’s say the most expensive ad in a zone in Adverticum costs 99 HUF. In this case, the AdServer sends a price modified to request a banner. The system will ask for an ad with a higher price than 99x1.219512=120,7316 HUF. If it would ask for an ad with only 99 HUF the answer could be a 100 HUF banner, but after paying the 18% commissions it would only mean 82 HUF income.

Besides, there is a new function in the system counting daily market rate to have all bids on the same currency.

In Rubicon the default currency is USD, so we had to manage to change every available currency in the system to USD so they can compete for impressions in the two systems.

It means, that there is a chance to set up prices in all three currencies (HUF, EUR, USD) and the system will change them into USD in order to handle them on the same level.

The system uses the following market rate provider for the change:

• HUF/USD conversion is based on the market rate of the National Bank of Hungary
• EUR/USD conversion is based on the market rate of the European Central Bank

For further information on Price Priority, please visit this page.

RTB Statistics

It is also possible to manage the EasySSP statistic access the Account Seat/Profiles page by clicking on the user’s name.  Click on the user’s name and set the access on the User details site with the activation of the "All measuretypes" checkbox.

Access could be regulated by all users in the profile uniquely (full access is required for access-management).

 IMPORTANT! Statistics of Rubicon define the basis of accounting. They will serve the punctual and detailed data.

Statistics of RTB campaigns can be pulled out from Adverticum AdServer.

The AdServer statistics have not changed significantly. We have introduced three new measure points in the system. Users can follow the Rubicon defined price of the sold impressions.

• EasySSP income (USD): effective income
• EasySSP income (USD) #: number of purchase / events
• EasySSP income (USD) AVG: the average income

Process of serving

To provide faster and more efficient operation, the Goa3 treats the RTB zones as a separate request. It is essential, so this different kind of service mode will not influence the site load.

The client can decide whether the Goa3 treats the RTB and non-RTB zones as one or separate requests. We did not modify the tags and do not distinguish the zones using default operation.

In case of using the default operation of the document.write implementation, the RTB requests and answers will be handled in the <head>. Browsers wait for these answers, so the sites' loading times can significantly increase. 

Separated requests

 Attention! RTB zones mean zones set up with RTB properties.

If we would like the RTB zones to be treated as a separate request, the following meta tag is to be embedded into the <head> tag of the website.

<meta name="separateRTB" content="true">

 The tags must be used as usual, without any changes.

If this meta tag is in the site, the invocation will be modified in the following way.

When the zones are invoked, the Goa3 will get the non-RTB zones from the servers first. These will be treated and embedded without any changes. After all requested zones have been served, the RTB zones will be served in a new request.

Using this method, displaying of the banners can be faster because the zones will not be waiting for the answer of Rubicon and it has no effect on the loading of the sites.

Its conclusion is that the non-RTB ads can exclude the RTB ones because the RTB invocation starts when the non-RTB banners are displayed.

Changes of the Document.write invocation

The above-mentioned meta tag has to be placed into the site, as a conclusion, the Doc.write invocation will be modified in the following way.

The loadZones() method is to be used in the known way for every zone, the system will automatically select and handle the RTB zones.

The zone implementation is to be done with the currently used insertBanner() method. This will insert the non-RTB banners with the usual method, while in case of an RTB zone it will implement a “simple” Goa3 zone into the site. Essentially, the RTB zones will be served with a Goa3 invocation.

Because we serve all RTB banners in an iframe after the dom.ready event you can use doc.write codes without any backfires.

Advantages:

• Long waiting times can be avoided with this method.
• Browers will not wait for an answer from Rubicon.

Disadvantages:

• RTB zones invoked via Doc.write are served with Goa3 requests, so other RTB and non-RTB zones will already be inserted into the site before them.
• In this case already built in banners can exclude RTB banners.

Process of evaluation

In a certain zone Rubicon requests for multiple zone sizes can be parallelized in the same waterfall level. If we do not get any answers from the Rubicon in time in case of RTB requests timeout, the selection of the banners will continue as if the Rubicon could not have answered to the request.

We can send those requests in a parallelized way to Rubicon, that are running in the same zone and their priorities are the same as well. The sequence of parallelized requests toward Rubicon can be defined in the Bidorder field, but we serve the most valuable requests from the sent ones.

 The number of the parallelized requests can be maximum three (though according to the current agreement with Rubicon, they can modify it unilaterally).

In case of one page load, the RTB requests are sequential to every level and zone of the waterfall model (assuming that we implement the waterfall model by recording RTB goals at different priority levels).

 It is important to highlight that the serving comes from Rubicon may take longer as usual.

If there is an interruption in the serving of Rubicon, a „Rubicon per request” timeout will be created in the EasySSP system. There is another timeout as well, called „Rubicon all request”, because sending of more requests will happen toward Rubicon.

Current values of timeouts:

• Per request (request timeout): 1 second
• All requests (global timeout): 5 seconds

These values can be configurated in the system and can be modified if it is requested.

  It is important to highlight that the non-RTB serving will not happen till the system of Adverticum is waiting for the response of Rubicon when non-separate requests are used.