SSL implementation guide

Creatives running on Ad Exchange must be SSL-compliant.

All publisher inventory accessible via Ad Exchange has a secure connection (SSL) and requires SSL-compliant creatives.

This guide will help prepare you for SSL inventory on the Ad Exchange.

First steps for all buyers

  • Your own certification: If you have not yet heard from the Google third-party ad serving (3PAS) certification team or have specific questions about the parameters of testing or the overall process, please contact
  • Your vendors' certification: Ensure that the vendors you use on Ad Exchange are certified for SSL. Google certifies both display and VAST vendors. See the updated Ad Exchange vendors list for details.
Information for RTB buyers

Prepare your bidder

Get your bidder ready to properly interpret and respond to SSL inventory bid requests. Make sure your bidder platform understands the following:

  1. Interpret SSL bid requests

    In the excluded_attribute field, the value 48 represents the RichMediaAdsVendor: RichMediaCapabilityNonSSL creative attribute. In the bid request, this appears as:

    repeated int32 excluded_attribute = 48
    • If 48 is present in the excluded_attribute field, SSL-compliant ads are required.
    • If 48 is not present in the excluded_attribute field, both SSL-compliant and non-SSL-compliant ads can be returned.

    This field will appear in bid requests for both display and in-stream video ads.

  2. Respond with an SSL-compliant creative

    To bid with an SSL-compliant creative, declare attribute 47, RichMediaCapabilityType: RichMediaCapabilitySSL, in the attribute field of the bid response. In the bid response, this appears as:

    repeated int32 attribute = 47

    Please note the following:

    • If your tag is always SSL compliant (e.g., the tag uses JavaScript or a macro to determine whether to make all calls over SSL), always declare the tag as SSL compliant. Do not declare SSL compliance for a creative if the tag changes on the bidder side to toggle SSL compliance.
    • 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.

    • Serving an SSL ad to a non-SSL request is acceptable and runs in the auction as normal.
All media and third-party tracking URLs must be SSL-compliant

If either the ad or the tracking calls do not use https, the bid will be dropped from the auction and the snippet disapproved. Until you confirm that all vendors you work with are SSL-compliant, refrain from dynamic insertion of third-party tracking URLs.

Using https is not, in itself, sufficient. The landing page certificate must be valid and up-to-date. To view this information, click the lock icon in the Chrome browser. Learn more

Enable SSL inventory with RTB pretargeting

For each PretargetingConfig where you’d like to receive SSL inventory, ensure that you do not target RichMediaCapabilityNonSSL. By not targeting RichMediaCapabilityNonSSL, you will receive all non-SSL and SSL inventory that matches your other pretargeting selections. Targeting RichMediaCapabilitySSL will also get you both types of inventory, but is unnecessary.

Important notes

  • As with most changes to third-party ads in the UI, checking the SSL compliant checkbox for existing ads and saving will cause the ads to require another review. This will stop all pre-targeted traffic from serving in the creative until it’s approved. Please reach out to your support team to identify the best way to enable SSL bid requests for your account without interrupting delivery.
  • Ad groups which contain both SSL and non-SSL live pretargeting creatives will not be eligible for SSL-required inventory.
  • Before declaring SSL compliance for all of your RTB creatives, we highly recommend initially testing in small batches.
Information for UI buyers

This section only applies to buyers utilizing third-party ad serving via the Ad Exchange UI. Creatives hosted via the UI automatically support SSL without user intervention.

  1. Understand how to make your ads work over SSL

    For SSL inventory, all calls within a creative snippet must be SSL-enabled. Make sure you understand how to guarantee this for each ad server, pixel tracker, verifier, and other vendors.

    The new %%SCHEME%% macro will insert http: or https: in your tags at delivery, depending on the inventory type. For more information, see the list of supported macros.

  2. Update existing ads

    By default, existing ads will not run on SSL inventory.

    Manual process

    1. The process for making a creative SSL compliant includes two steps on the part of the buyer:

      1. Modify the snippet contents to include/support the HTTPS scheme.
      2. Toggle the SSL compliance checkbox within the Ad Exchange UI.
    2. Once this is done, the changes will trigger a new review, temporarily marking the creatives “Pending” and halting all delivery until reviewed and approved.

      These ads will stop serving while in review. If uninterrupted ad serving is required, create a new, SSL-enabled copy of the ad, and disable the old copy only after the new SSL-enabled ad begins trafficking.

    3. Ad groups which have both SSL and non-SSL creatives will not be eligible for SSL-required inventory. If you need to have both types of creatives, you should split them into separate ad groups.

    Automated process

    1. Before using this workflow, notify your Ad Exchange support team so they can help ensure a smooth transition.

    2. Buyers must agree in writing to the following to allow us to approve your creatives in bulk:

      • Ads are "copies" of only ads that are currently approved (disapproved ads will not be reviewed).
      • Ads do not introduce changes to actual creatives rendered.
      • Ads are not part of new, not-currently-running advertiser campaigns (only ads in existing campaigns will be reviewed). Note that this means that while the SSL transition is happening, no new ads may be added under the specified campaign IDs.
    3. Define a process to make changes to relevant existing ads. The best way to make bulk changes is through the SOAP API. For best results, follow these instructions:

      1. Download existing ads.
      2. Make any necessary SSL changes to the HTML tag.
      3. Upload as new creatives (since changing existing ads causes these ads to halt serving until review is complete).
      4. Pass the list of new campaigns, ad groups, and creatives to your support team for bulk setting of the SSL flag and bulk approval.
      5. Note that we do not support checking the SSL compliance checkbox initially, which is why you should work with your support team to check them in bulk.
    4. Once the new SSL-ready ads are approved, you may want to delete or pause the existing campaigns/ads. Ads with the “SSL compliant” checkbox enabled are able to serve on both SSL and non-SSL inventory.

    5. Be aware there are some limits throughout this process:

      • Campaigns per account: 10,000
      • Ad groups per campaign: 20,000
      • Placements + audiences lists + topics per account (including both inclusions and exclusions): 5,000,000
      • Ads per ad group: 2,000 active

Frequently asked questions

For more information on SSL implementation, please see the SSL implementation FAQ.
Was this article helpful?
How can we improve it?