Scroll down to learn more about GeoEdge's ad security and verification solution!
GeoEdge University

HTTPS Encryption and the risk of 3rd Party Tags

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.‎