SSL implementation FAQ

Creatives must be SSL-compliant.

All inventory available through Google partners has a secure connection (SSL) and requires SSL-compliant creatives.

For more information, see the SSL implementation guide.

Should I explicitly declare when an ad is not SSL-compliant?

This is not required. Bid responses that do not have attribute 47 RichMediaCapabilityType: RichMediaCapabilitySSL declared will be considered non-SSL-compliant. The attribute 48 RichMediaAdsVendor: RichMediaCapabilityNonSSL only exists in the creative attributes dictionary file for use in the bid request’s excluded_attribute field. It should not be used as a declaration in bid responses.

When do I begin seeing SSL bid requests?

You will see SSL bid requests once you (a) are whitelisted, (b) check the SSL box in your pre-targeting campaigns, and (c) target Google owned-and-operated inventory.

What if some of the third-party tracking URLs in my VAST tags do not use https://?

The bid will be dropped from the auction and the snippet disapproved. All media and tracking calls must be SSL-compliant. Until you confirm that all vendors you work with are SSL-compliant, refrain from dynamic insertion of third-party tracking URLs.

What happens if I serve an SSL ad to a non-SSL request?

Assuming all SSL certificates are valid, the ad will run in auctions normally.

What happens if I declare an ad as SSL-compliant but it makes non-SSL calls?

The snippet will be disapproved, thus being ineligible to win in auctions until corrected, re-reviewed, and approved. For RTB buyers, the pre-targeting ad will not be disapproved. The disapproval reason will be reported as INVALID_SSL_DECLARATION (SSL support declared but not working correctly).

What happens if I return a non-SSL ad (which lacks SSL declaration) to an SSL bid request?

The bid will be dropped from the auction in the same way that other bids are “post-filtered” (e.g., bidding with a financial product’s creative on inventory where a publisher excluded financial products).

What if my tags only need to swap out http with https to be compliant?

The new %%SCHEME%% macro resolves to http: or https:, depending on the inventory type. Only the HTML tag’s text provided to Ad Exchange will be adapted, so fourth-party calls outside the HTML tag’s text will not be adapted by this macro. This macro is not supported for VAST in-stream video.

Should I use a separate buyer_creative_id for the SSL and non-SSL creative versions?

You should use a separate buyer_creative_id for SSL and non-SSL versions of creatives.

While, attribute 47 RichMediaCapabilityType: RichMediaCapabilitySSL can be used as a part of a unique identifier for a creative, using a separate buyer_creative_id for separate versions is highly recommended.

To easily distinguish between creatives, you should also consider including the SSL status of the creative in your naming convention.

Are there any changes for SSL-compliant tags when using the REST API to submit creatives?

There are no changes to the REST API itself, but we highly recommend using a separate buyer_creative_id for the SSL and non-SSL versions of the same creative.

If your bidder toggles the SSL declaration on and off for a single buyer_creative_id, you will need to submit the SSL and non-SSL tags separately. Remember to declare attribute 47 RichMediaCapabilityType: RichMediaCapabilitySSL as you would in the bid request.

Can I programmatically set the “SSL compliant” flag for UI creatives (e.g., via the SOAP API)?

No, this functionality is not yet supported. Please consult with your support team for options.


Additional questions

Please reach out to your account team with any additional questions, or contact us .

Was this article helpful?
How can we improve it?