Web pages that meet HTTPS protocol/encryption (Hypertext Transfer Protocol over SSL) are known to be more robust and also more loyal to their customer base (users) with the information presented and the ads shown on their sites.
These web pages also usually meet higher standards with search engines and other ranking sites. This benefits the publisher with higher rankings and enables him to sell his inventory at a higher cost, now that RTB and programmatic buying are reviewing the quality of web pages before they bid.
Secure pages require secure tags. For a Publisher, having secure web pages/sites actually means that they are served over an HTTPS protocol. The HTTPS protocol (HTTPS-enabled site) requires that all content on the page must be secured, including images, tracking pixels, analytic tools codes, and of course, tags.
As part of the content, the publisher must ensure that the Ads on the sites are secured. This means that the Tags that are placed on the HTML source code will be fully secured with an SSL-compatible ad code.
What this means is that the SSL-compliant ad units will be accepted by the ad server (should they be placed as a 3rd party tag in an Ad Server), or accepted by the web page itself (should it be fully encrypted and review all elements within). If the Ad Tag is not secured, it is most likely that it will not be shown on the page, and instead a blank ad will be served.
An additional issue that the publisher may face is a clear discrepancy from the amount of impressions given to the actual impression seen. When a seller (publisher) is calculating his total impressions (for a specific placement on the site), he is expecting the same count from the ad network/advertiser. In many scenarios the count is different due to discrepancy of non-linear requirements… some of the issues may be due to Daisy Chaining (when placing 3rd party tags on Ad Servers and extracting an additional tag), while other issues may be due to secured/non-secured tags.
The same issue applies when we are trying to place a secure tag on a non-secure page – resulting in situations where the ads are not seen – hence no impression is made even though it was presented by the publisher, and initially served by the ad server.
In both cases, the required 3rd party tag is to be set as fully secured and approved by the platform. This is reviewed by the platform to see if it meets all requirements. In some cases a 3rd party tag may call on other units (other servers/technical vendors) which may not comply with the SSL request, and as such may not be approved.
The publisher then risks having unwanted advertisers presented on the site. This is also the case when running today’s dynamic RTB/Programmatic ad serving technologies. Understanding the content to assure that it complies with secured data is a must in today’s ad industry.
Another important issue is the destination URL of the user (the landing page). If the landing page is non-secure, the user is redirected from a secure environment to a non-secure environment. This switch may result in the user receiving a non-approved landing page. An important factor is to review the full funnel for the Ad Tag; the creative, where the data is coming from (Ad Exchange/Ad Server), and the destination location of the landing page from the advertiser’s side.
The problem in this matter can be easily solved by applying an ad verification service. This service will review the Tag, monitor what is allowed (and what is not allowed on the site), review the end location from the tag (the landing page), and assure that it complies with all aspects of the HTTPS protocol/encryption – giving the publisher the peace of mind he needs.
