It can be surprising how small details can impact the serving or tracking of ads. Secure and non secure tracking pixels are one example of this.

A secure tracking pixel is one that uses ‘https’ as the protocol while a non secure one uses the standard ‘http’ protocol. The secure protocol is supposed to provide greater security by making it harder to be intercepted and read. For this reason it is the standard used to transmit sensitive information such as financial data or login credentials. Depending on how a company views tracking pixels and the information it contains, they may choose to transmit it over a secure channel.

A secure tracking URL is not a problem on the surface, but it could cause issues depending on the protocol of the page or video player that sends out the requests. Typically a non secure page should be able to send a request for a secure tracking pixel without any issues. The user may receive a warning about the page utilizing secure and non secure items but it should work most of the time. It is possible for the user to configure their browser in a such way that it could block the request or only be sent with confirmation from the user. Different browsers and mobile devices can handle it differently so testing is needed.

In addition, video players, which send out the different video tracking and quartile pixels, could be configured in such a way as to only send out requests to URLs that match the page protocol. There is no definitive answer for all scenarios so testing must be done.

The mixture of protocols becomes a big issue when a secure page attempts to call a non secure tracking pixel. In this instance it will most likely not be sent, and thus the advertiser will never receive confirmation that their ad displayed. Video players on a secure page may function the same way.

Typically an advertiser will determine which type (secure or non secure) of assets and tracking pixels to return based on the protocol of the ad request to them. That of course requires the advertiser to support receiving both types of requests and utilizing logic to return URLs based on the request protocol. Some advertisers do not support both protocols and they do not provide an alternative way to inform them if the ad will be displayed on a secure or non secure page. This could potentially create a large discrepancy in reporting if the ads are displayed on secure pages and they are returning non secure ads.

If advertisers or publishers are noticing a large discrepancy in impression reporting, this is something they should investigate. It may or may not be an issue but it is something that needs to be on the checklist. If publishers are running a secure site, they should inform advertisers of this at the beginning of the relationship. Advertisers also need to make sure they can support sending secure and non secure URLs and that they provide a way for publishers to inform them which protocol they are using. With Google scaring more and more websites into falsely believing that switching their site to ‘https’ will benefit them, this scenario may become more common.