Posted:
Over the years, many developers have let us know they'd like to see more real-world AdWords API examples to help them drive their own success. To deliver on this, we've worked closely with our partners to share their innovative strategies for using the AdWords API to boost their business.

You can now find these case studies on the developer website. We plan to post more in the future, so check back for fresh insights from digital marketers on making the most of the AdWords API.

If you have any questions or feedback regarding these partner stories, please let us know on the forum.

Posted:

Starting with iOS 10, Safari on iPhone and iPod supports inline video playback. This opens up some new rendering options for your video player and the IMA SDK, but also introduces some caveats.

So what changed?

Previously, Safari on iPhone played all video in a fullscreen player. With iOS 10, Safari now supports the playsinline parameter on a video element to play that content inline.

Fullscreen playback on iPhone Mobile Safari. The default with iOS 10+ and the only option for iOS <= 10

Inline playback on iPhone Mobile Safari. A new option in iOS 10+

How will the IMA SDK work with inline video playback on mobile Safari?

On iPhone Safari, the IMA SDK re-uses your content player to play ads. We call this "custom playback." So if you add the playsinline parameter to your content video tag, IMA ads will also play inline - it's as easy as that.

Inline video playback also opens the door for the IMA SDK to play skippable ads on iPhone Mobile Safari. Previously these ads were dropped by the SDK because we could not render a skip button on top of the fullscreen player. If your player is inline, however, we can render that skip button, but there's a catch.

So what's the catch?

IMA SDK skippable ads are not supported with the "custom playback" method. To use skippable ads, you'll need to use our new API, ImaSdkSettings.setDisableCustomPlaybackForIOS10Plus(). This will cause the IMA SDK to render the ad in its own inline player on top of your content player. That player does support skippable ads. Disabling "custom playback", however, will break your fullscreen implementation for iPhone web.

Why do I need custom playback on iOS?

The need for "custom playback" on iOS boils down to one thing - fullscreen support. Mobile Safari only supports fullscreen via videoPlayer.webkitEnterFullscreen(). In this mode, the SDK cannot render anything on top of your content player. Therefore, to support fullscreen ad playback we must use "custom playback".

What if I want skippable ads and fullscreen support?

Unfortunately, this is not possible on mobile Safari today - you must choose between support for skippable ads and support for fullscreen.

What's the deal with iOS <10?

Prior versions of iOS (<10) do not have support for playsinline, so pages in those environments will always use "custom playback" mode, with support for fullscreen but no support for skippable ads.

I'm still confused.

That's OK! This is a complicated change with a lot of moving parts. Below is a support matrix outlining what is and is not supported based on your content player's playsinline mode and the "custom playback" mode you've set for the IMA SDK. Remember, this matrix only applies to iOS 10 and above - anything running version iOS 9 or below falls into the top left quadrant of the matrix, as this is the only option.

Posted:

To help developers integrate with the IMA SDK, we're always looking for ways to provide both basic and advanced examples of features supported by the SDK. Toward this end, we're pleased to release a sample JavaScript VPAID creative and sample ad tag to aid in troubleshooting JavaScript VPAID 2.0 creatives. You can check out the new sample on GitHub, and find the new ad tag in our list of IMA sample tags as 'Sample VPAID 2.0 Linear'.

The VPAID sample plays a linear video ad and demonstrates the use of the video player proxy element required to run a VPAID ad in a secure iframe.

If you have any questions, feel free to contact us via the IMA SDK developer forum.

Posted:

We've recently released some improvements to the DFP Python Library alongside support for v201705. Our goal was to reduce the boilerplate required to construct entities and DFP statements—keep reading to see what's new.

Improved statement creation utility

Previously you had to construct filtering statements manually out of strings, and write a lot of code to bind variables into statements. Here's what the code commonly looked like:

values = [{
    'key': 'startDateTime',
    'value': {
        'xsi_type': 'DateTimeValue',
        'value': {
            'date': {
                'year': start_date.year,
                'month': start_date.month,
                'day': start_date.day
            }
        }
    }
},{
    'key': 'orderName',
    'value': {
        'xsi_type': 'TextValue',
        'value': 'My Order%'
    }
}]
statement = dfp.FilterStatement('WHERE startDateTime > :startDateTime AND '
                                'orderName LIKE :orderName', values)

Dealing directly with strings opens up many potential errors, and we decided that the above was way too much typing just to bind variables. To make things easier, we've introduced a new utility called StatementBuilder. Now you can write code as simple as:

statement = (dfp.StatementBuilder()
             .Where('startDateTime > :startDateTime AND orderName LIKE :orderName')
             .WithBindVariable('startDateTime', start_date)
             .WithBindVariable('orderName', 'My Order%'))

StatementBuilder will automatically infer your variable types and construct the values object. You can then pass this to an API request in the same way that you did with FilterStatement:

response = creative_service.getCreativesByStatement(statement.ToStatement())

Automatic datetime unwrapping

Previously, you had to break out dates and datetimes into our format when constructing entity dictionaries:

line_item = {
    'orderName': 'Awesome New Order',
    'startDateTime': {
        'date': {
            'year': start_date.year,
            'month': start_date.month,
            'day': start_date.day
        },
        'hour': start_date.hour,
        'minute': start_date.minute,
        'second': start_date.second,
        'timezoneid': start_date.tzinfo.zone,
    },
    # ...
}

Starting in this version, you can simply pass a native Python date or timezone-aware datetime object directly:

start_date = datetime.datetime(2017, 6, 1, 9, 0, 0,
                               tzinfo=pytz.timezone('America/New_York'))
line_item = {
    'orderName': 'Awesome New Order',
    'startDateTime': start_date
    # ...
}

Our library will unwrap the datetime object into our format automatically. We're continuing to support passing the full dictionary, so there's no requirement to migrate your code.

We hope these changes will make building DFP integrations in Python easier. As always, please feel free to get in touch on the forum with any questions.

Posted:
We’ve enhanced structured snippets to now have even more header translations, increasing from 12 to all AdWords languages. Structured snippets are extensions that highlight products and services in your ads. Existing structured snippets will not change, so no AdWords API code changes are necessary, but consider adding structured snippets to any campaigns targeting the newly available languages.
Here are some resources to get you started with structured snippets:

As always, if you have any questions, please contact us via the forum.

Posted:

AdWords API v201607 will be sunset on June 27th, 2017, after which all v201607 API requests will begin to fail. This version was deprecated on February 28th, 2017. If you are still on v201607, we recommend that you skip v201609 and v201702 and migrate directly to v201705. Please be sure to migrate prior to the sunset to ensure your API access is unaffected.

We've prepared various resources to help you with the migration:

As always, if you have any questions about this migration, please contact us via the forum.