2017 Native Predictions

native_conceptual
I and the other members of the IAB Native Standardization committee wrote our predictions for native advertising in 2017.

My notes:

Native standardization by the IAB has bridged the gap between social marketing and the programmatic display ecosystem.

At PulsePoint, our social marketing & sponsored content distribution platform used to be siloed from our programmatic offering.

Native standardization enabled us to distribute native-style display ads across hundreds of publishers, leveraging existing OpenRTB integrations.

Similarly, our DSP partners started scaling up native campaigns without worrying about the how their ads would blend within publisher content, enjoying far greater engagement and reach than with banner.

In 2017, we anticipate native advertising to be our fastest growing channel, slightly ahead of pre-roll video.

In-feed will still make up the bulk of native ad revenue, as many of PulsePoint traditional publishers focus on text-heavy or user-generated content.

We have big ambition for native video for next year. Constraints are mostly demand-side, but both publishers and advertisers are getting more comfortable with embedding video content within in-feed ads, at a substantial CPM premium over static media.”

This said, and as a few of my co-members noted, adoption of native has been below expectations in 2016.

Video is the main reason, as Kayla Wilson noted: “DSPs de-prioritized [native buys] when they realized this year was actually all about in-app video”.

VPAID is doomed

IAB kick-off meeting for VPAID 3.0 standard took place today.

How VPAID interact with the playerVPAID was designed to offer rich interaction with a video ad, but in practice is mostly used for verification & viewability.

Hence most discussions today were centered around bringing back VPAID to its original purpose, and standardizing verification as VAST events.

I am not convinced VPAID has much of a future.

Custom scripting technology within the video templates always sounded an awkward idea, and doesn’t jibe with standard media creation workflows within agencies. Controlling player behavior from javascript within the page is just cleaner and simpler.

Publishers will be particularly happy to see the back of VPAID, along with its security and performance issues. Trying to restrict access of the entire DOM to VPAID script is just a patch. As are attempts at controlling VPAID scripting language to limit, say, latency-inducing ad server calls.

Scripting capabilities within the VAST payload is simply a doomed idea.

 

OpenRTB 2.4: a few good ideas and many missed opportunities

ORTB24OpenRTB version 2.4 is now released. While not a major upgrade by any stretch, the new protocol does introduce several new features that will bring clarity to programmatic transactions.

Support for Audio-only ads has been the feature most talked about. Podcasters and music apps will definitely welcome the addition, but few publishers will benefit besides this niche.

Another widely anticipated feature is video skippability, now included in bid requests. Publishers can indicate pre-bid if a video ad can be skipped, and under what conditions.  PulsePoint will encourage its publishers to send this flag, in order to bring more transparency to video buy.

Those concerned with brand safety can rejoice. With 2.4, buyers can indicate in their bid responses, if their creative is suitable for either young children or adults, which may help with ongoing monitoring of buyer performance in the long term. PulsePoint, like most platforms, rely on third party vendors and manual checks to ensure compliance of creative with what’s requested. Obliging advertisers to systematically indicate the media rating of their creatives will make it easier for all parties to monitor compliance and flag violators.

Not all of the 2.4 upgrade is augmentative, as the IAB is removing some flexibility in resizing banners. Prior to this new version, maximum and minimum sizes could be specified; however recently, the IAB opted to mandate a list of exact banner sizes, reserving the resizing of banners exclusively for native impressions. This signals that IAB now sees banner as a single purpose ad format.

Finally, IAB added 6 attributes to the content section of the bid request, including the artist and genre of the content where the ad will appear. However, I doubt this will be of much use. The content section is rarely populated on PulsePoint exchange, and even less often consumed by buyers.

A few disappointments.

The IAB trumpeted increased support for location in 2.4, however this is quite a stretch. The new lat/long accuracy parameter (designed to specify the accuracy of the device that generates the location signal) will be of little value, as precise lat/long are used by geofencing campaigns which aren’t effected by the discrepancy of a few meters. More importantly, since the device of the GPS is often passed along, geofencers already have a sense of the accuracy of the GPS, and probably won’t trust what the publisher sent through the bid request. Knowing the IP geolocation provider will be of even less value, as most DSPs will keep using their own vendor lookup.

Despite some actions to enhance the monitoring of compliance, OpenRTB 2.4 still fails to mandate a maximum time lapse between a bid request and when the creative is finally delivered. We’ve seen bots circumventing quality filters by holding a creative for a few minutes and releasing them in batches, taking advantage of a hole in OpenRTB specifications. This topic caused many discrepancies between platforms and advertisers as well, yet OpenRTB 2.4 only added a recommended maximum time lag. PulsePoint will strongly suggest its buyers to provide this maximum lapse with each bid, and we are considering contractual wording to define liabilities accordingly.

Quickly implemented, quickly forgotten.

It appears that the most significant change may be the specs’ upgrade for native. This comes up in a different specifications document: The Dynamic Native Ads Protocol. The main OpenRTB protocol is unchanged, only referring this Native API.

PulsePoint will become 2.4 compliant right after the specs are finalized. Mostly because this is expected from a leading exchange, and less for the business value of the upgrade.