Hosted bidding

Hosted bidding is a new real-time bidding alternative that allows you to quickly and easily run low-volume campaigns directly from the Ad Exchange interface, without the need for proprietary RTB technology.

You should now use hosted bidding for all non-RTB campaigns, rather than the old interface. Beginning early 2016, the old interface will be deprecated and all non-RTB campaigns created outside of this platform will be turned off. Learn more

UI updates

Multiple account access for individual users

It is now possible for an individual Google login to be associated with more than one account. Users with access to multiple accounts can easily switch between accounts in the Ad Exchange interface. Learn more

Re-send invitations for pending users

If you have administrator access to your Ad Exchange account and manage account users, you can now re-send an email invitation to a "Pending" account user. Learn more

Video support for Creative Validator

You can now view the SSL-compliance status of your video ad tags, in addition to display ad tags. The creative validator accepts either a VAST URL or XML for video ad tags. Learn more

Real-time bidding updates

New auction behavior using the deal ID

With Preferred Deals and Private Auctions, you have the option of bidding on impressions for specific preferred deals or private auctions using the deal ID, or sending them directly to the Open Auction. Learn more

Cookie matching container tag

A new optional URL parameter now exists in cookie-match requests that allows you to redirect to a encoded dynamic URL. This URL is then decoded by Google and redirected to the URL. If you typically call multiple partners in a single chain in your URL, this enables you to dynamically order those partners.

To prevent any fourth-party from reading the cookie set by another party, the new parameter is only allowed when using hosted match (can only be used in conjunction with the google_hm parameter, cannot be used with the google_cm parameter). Learn more


Unencrypted fields for RTB callouts

The entire RTB callout is now encrypted when sent to secure bidder endpoints.

Since this change removes the need for individual fields to be encrypted, unencrypted versions of the following fields have been added and are now being used when sent to secure bidder endpoints: hyperlocal_set, advertising_id, hashed_idfa, constrained_usage_advertising_id, constrained_usage_hashed_idfa.

The previously-encrypted versions of these fields still exist, and will continue being sent to both secure and non-secure bidder endpoints.


Google verified video player size

The width and height fields are included in the RTB callout for the all ad slots. For VAST video ad requests, these values specify the Google-detected video player size. Bidders should use these values to determine the size of the video player for the ad slot. If Google cannot detect the size of the video player, these fields will default to the player size reported by the publisher.

Height and width values for video ads are strictly informational; there is no restriction on the size of the video ad that you can return.


New RTB callout fields: deal_type

The deal_type field is now included in the RTB callout. Bidders should read the status in this field to determine the type of deal for the ad impression. Available options are UNKNOWN_DEAL_TYPE, PREFERRED_DEAL, and PRIVATE_AUCTION.


See these fields in the updated Real-Time Bidding Protocol.

Additional announcements

New behavior for autoplay Flash creatives in Chrome

The Chrome browser has rolled out a new feature that pauses any peripheral plugin content that is not part of the main webpage. Because ad content is usually considered peripheral, auto-play Flash creatives now appear in a paused state and do not animate until a user clicks on the player.

Users now need to click Flash creatives a second time before being redirected to an advertiser landing page. This affects most standard-sized Flash creatives within the Chrome browser. Learn more

Upcoming change to RTB callout field: adgroup_id

Beginning February 2016, we are changing the adgroup_id field from optional to repeated. This allows all matching adgroup_id instances to be sent in a single MatchingAdData field, per buyer, per bid request. In addition, the adgroup_id field is being renamed billing_id to provide parity with the buyer REST API.

Bidders should update their bidder logic to correctly interpret the repeated instances of the adgroup_id field in the MatchingAdData field of the bid request and use the new billing_id field name. If you do not update your bidder logic, you will only see the last value of the repeated field.

The billing_id field can now be found in the Real-Time Bidding Protocol, but the change goes into effect in 2016.


View the announcement archives.

Was this article helpful?