The Mobile Browser is dying

Comscore’s latest report confirmed what everybody already knew: consumers mostly use mobile apps, desktop is becoming a niche play and mobile browsers will soon be a thing of the past.


For ad platforms, this has profound implications. Selling monetization services to app developers is a totally different ballgame than convincing media folks to throw a new ad tag in their ad server.

Also, apps developers have historically favored more “native” advertising units over low-CPMs banners.

MoPub, Smaato and other pioneers in the programmatic native app space gained prominence by distributing broadly their advertising SDKs in the early 2010s.

SDK no more

The business is changing, however.

No developers want to add “yet another SDK” to their app. As networks become more sophisticated, and HTML5 gain traction, calling an ad network endpoint become a viable options for developers to retrieve ads.

In parallel, video and native video advertising is opening new opportunities. For example, Video CPMs and higher fill rate are high enough to entice game developers to offer watching ad as an alternative to in-game purchases.








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.


The Future of Header Bidding is Server-Side


It’s been a little over a year since header bidding became mainstream, and the technology has been adopted by half US premium publishers to deliver ads programmatically.

As a result, competition is heating up. Where previously tech companies were looking for a solution to appease their publishers, there is now a battle for market share. AppNexus announced PreBid pro last month as an enterprise-class upgrade to its popular Prebid.js open source wrapper. OpenX has announced header bidding for in-app. Index is betting the farm on its black-box, fully supported solution. Inversely, Rubicon admitted its costly mistake in not developing an offering.

Yet as these offerings hit the market, a fault-line is emerging between two distinct camps: the client-side wrapper versus the server-side wrapper. Client-side wrappers gives publishers full control over their monetization without costly data centers. SSP-managed server-side wrappers gets publishers up and running quickly, but the SSP has a say when adding new demand sources.

Ultimately, publishers will pick server-side.

Once upon a time, wrappers were all client-side

Client-side wrappers have been around since the early days of header bidding. Pioneers like RTK didn’t have the infrastructure to handle complex real-time bidding (RTB) auctioning within their data centers, so writing client-side software was an easier start.

On the pub side, early adopters were willing to deal with the complexity and limited feature set of these early javascript wrappers, attracted by the transparency and revenue gains offered by header bidding’s holistic yield management.

But as more of publishers’ traffic shifted to header bidding, the complexities built up. Robust analytics became a priority, more buyers needed to be added and finally privacy came to the forefront. Not surprisingly, header bidder wrappers are now big, hairy pieces of software, delivering mission-critical functions from the inherent flimsiness of browsers. The Prebid.js open source framework saw 17 releases in one year, and now comes with 27 built-in demand partners.

Operational Management and Latency Concerns

Some vendors responded to this complexity by moving the most critical functions of header bidding away from the user’s browser and into their data center. Moving the most complex functions of header bidding to the server presents several advantages.

First, powerful vendor servers provide a more reliable and scalable environment for executing really complex tasks like real-time bid optimization and fraud detection.

Second, server-side wrappers are a lot easier to implement. In many cases, header bidding tags are like regular tags that publishers can copy from a self-service console and paste into their CMS. That’s all it takes.

Third, complex client-side code is more likely to slow down publisher pages. Beside the bandwidth required by a bigger payload, there are limits to the number of connections the browser can keep open, obliging some level of serialization of the bidding workflow beyond a certain number of real-time buyers.

Whose Data Center?

It’s therefore no surprise that server-side wrappers are becoming more popular. But that does not mean that client-side wrappers will go away. Far from it. For publishers with deep technical resources, client side wrappers will stay the preferred header bidding implementation for the foreseeable future. Client-side wrappers stay fully within the control of the publishers, allowing them to build and maintain the checks and balances that suit their business.

At some point, publisher will have the expertise to host server-side header bidding within their data center.

But for now, SSP-managed header bidding is the best solution for publishers who want to embrace header bidding rapidly and with minimum tech investment.

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.

Maintaining a Balance between Data Transparency and Monetization

privacyTransparency in data is an important topic right now. To be both transparent and ethical should always be a priority in adtech. In an era of the always-on connected consumer, it is vital to maintain privacy. Being honest about what data is being used and how it is being used creates trust between all who play a part in the process, from consumers to publishers. And trust is the most valuable asset a company can possess.

Recent headline-grabbing articles about personal data leaks and hacking of high profile services have pushed the broader data privacy issue to the forefront. As for transparency in particular, there is increased awareness that the multiplication of services and intermediaries has made it much harder for users and those representing them to control the flow and access of their data. As an ad platform, we are being approached every single week by vendors selling user data. These vendors range from large, established data aggregators and resellers, to tiny publishers I’ve never heard of, trying to monetize a niche audience on their site. With such a multiplication of players and incentives, it is critical to define industry-wide schemes to ensure transparency. This starts with building up awareness as to the importance of data transparency among all stakeholders.

Is this really Privately Identifiable Information?

As the topic of data security seems to saturate ad tech conversations lately, it is crucial to shed light on the practical considerations that companies need to pay attention to, yet aren’t quite doing.  Everybody I talk to agrees that private data should stay private, and that the notion of “private” is relative to the socio-cultural context of the user. Data vendors always tell me they do not sell Privately Identifiable Information (“PII”). They sell “aggregate” data, or encrypt sensitive information like email addresses; for the most part these vendors mean well, but at the same time, most vendors barely know or understand the origin of the data they are selling. Hence, how can they really guarantee that their data were collected ethically and transparently? It is somewhat akin to these complex mortgage securities before the financial crisis, who had become so detached from the actual mortgagers that the financial broker who sold these instruments had no way to assess how solvent these borrowers were.

Openness and Transparency!

So I ask you this question: What is the ideal balance for monetization? The current consensus seems to be that if you do not disclose any PII, anything is fair game.  At PulsePoint, we uphold strict No-PII standards to never accept any name, addresses, social security number or credit card info, for example. Nor would we expose email addresses or device serial number without encryption. This is clearly stated in the T&C signed by all publishers, vendors and advertising partners associated with the PulsePoint platform. It is of utmost importance that we uphold a firm practice of only processing data that cannot be linked back to a specific person. For example, we may disclose that a user is on an iPhone in Manhattan, which leaves a few millions possibilities. If we also reveal this user is a young male professional in the financial industry currently shopping for a new car, that’s still OK, but if we continue adding data points we may narrow down the pool of possible candidates to just one individual. That’s why we need strong internal policies and full disclosure on how data is consumed and shared, to ensure we never cross that line.

Strong internal policy is key for any company to operate in a transparent and ethical manner. Speaking from a personal example, PulsePoint’s advertising platform processes billions of user sessions every day, so it is imperative that we have robust and well-defined processes for deciding which data we ingest and distribute. This starts with full disclosure to our publishers and data providers as to the kind of information we are comfortable ingesting. We go to great lengths to ensure that appropriate data, as well as the majority of our advertising performance metrics and targeting attributes are fully available via our real-time dashboards.

It’s important to note that not all platforms are as open with their data, often launching themselves into murky waters with less than ethical practices of data harvesting and usage. The best way to create an environment where all participating parties feel safe and protected is to collaborate constructively with customers and partners to maintain full transparency on how data is generated and used.

At PulsePoint we are very much committed to making ads matter. We believe maintaining user privacy and reaching very specific audiences are not mutually exclusive. And ultimately, knowing well your audiences is the best way to deliver messages that are meaningful and timely to users.