Behold, an allegory:  Once upon a time in the Land of Mobile, there were over 25 nations. Each nation spoke its own language, had its own currency and made its own goods. No resident of any nation spoke the language of any other nation, nor could they, nor did they wish to learn. The goods produced by each nation were basically the same but, unfortunately, if someone from outside the Land of Mobile wanted to purchase these goods, they could only buy them from a single nation at a time.


To complicate matters, the price for an identical item sometimes varied wildly from one nation to the next.  But since there was no ability to do business with multiple vendors from multiple nations simultaneously, this inefficiency persisted. To make matters worse, the €œvalue€ of the items varied in accordance with the unique conditions of each nation and these unique conditions were impossible for anyone outside the nation to know.  Finally, there was no central marketplace, no way to identify or value similar items and no way to have buyers compete for those items across the nations.


Such is the condition of mobile app advertising from an exchange perspective today. The nations represent ad networks and RTB (Real-Time Bidding) marketplaces.  The disparate languages represent the various ad delivery SDKs provided by ad servers and ad networks.  The goods, obviously, are mobile app ad impressions.  And the mysterious, unknowable €œconditions€ that exist in each nation are things like undetectable competition, an unforeseen deluge of ad impressions or a sudden jump in rates.


The lesson of the story is this: unlike display advertising, the rules of mobile app inventory can be incongruous at best and thus demand a different, more complex solution if a true exchange is to emerge.


At the most basic level, an exchange is a place where similar objects (in this case, ad impressions), are traded.  The difference is that in the display world, an impression is an impression is an impression; in the world of mobile, unfortunately, this is not the case.


A display exchange is based on the protocols of the Internet (http, ftp, and browsers). As a result, data is formatted in a consistent, normalized manner. This normalized data structure makes it relatively easy for an exchange to onboard fully transparent display advertising inventory from any site and give its programmatic buyers access to that inventory. The data is normalized because the ad delivery mechanisms, like the Internet itself, are all built on the same, shared protocols.


The cookie is a good example of this.  A cookie maintains its value and structure regardless of which browser receives or transmits it. This allows advertisers, publishers and DSPs to reach specific audiences en masse as they traverse the Internet. You could say that the entire exchange ecosystem is basically built upon this single piece of data. Thats the power of normalization!


To be a €œtrue€ exchange, a mobile exchange will need to normalize impression data from mobile websites as well as mobile apps*. In addition, it will need to present that inventory in the most transparent way possible. Why? Because while display exchanges can contain semi-blind inventory, publishers have learned that they can make more money by exposing the full data set of each available impression! However, while onboarding mobile web inventory is relatively easy, onboarding fully transparent mobile app inventory into an exchange from different publishers running different SDKs is a significant challenge.


Mobile app ads are served via an SDK that passes specific data including the devices exact position via gps (lat & long), the apps app store URL, name, ID, carrier, app category, connection type (wifi vs. carrier), Device ID and whatever data the SDK requires, in whatever format the SDK determines. This data passes through to the SDK owners infrastructure (ad network, mediation stack or RTB marketplace) where it is used to maximize the value of each impression


In an exchange environment, RTB buyers must have access to consistent, €œuniversal€ data formatting across an exchanges inventory.  The challenge is that every SDK formats or encrypts data differently. For example, Company Ones SDK may pass Apples Identifier for Advertising (IDFA) in one encryption format (SHA1), Company Two may pass it in a different format (md5 hash) and Company Three may pass it without encryption at all (in the clear). Because of this variance in formatting and encryption, its not viable to simply pass each SDKs data into an ad exchange. In order to onboard app inventory into the exchange, a translation process, or data normalization step, needs to occur whereby data being passed by Company Ones SDK, for example, is translated into the exchanges €œuniversal€ data format before that inventory hits the exchange as a bid request. The exchange will need to translate all data from all SDKs into its own, exchange-specific data protocols each time a new bid request is received. Once the impression data is formatted in a consistent manner, programmatic buyers can transact at scale.


Looking back at our allegorical tale, if a unifying force wanted to create a market for goods from all 25 countries, that unifying force would need €“ at a minimum €“ to take on the complex and difficult task of establishing rules, designing currency conversions, and creating a trans-language description of items and their attributes.  These tasks are enormously intricate and yet they must be undertaken if trading is to commence.


The next generation mobile exchange must address these issues in order to realize the true value and full capability of mobile advertising. The ability to marry real time, normalized mobile impression data across inventory originating from multiple SDKs represents a significant opportunity. Learn more about OpenXs mobile capabilities.



[img]http://feeds.feedburner.com/~ff/OpenadsBlog?i=h4Aeg1ljalc:4LdsU2VFtU8:D7DqB2pKExk[/img]</img> [img]http://feeds.feedburner.com/~ff/OpenadsBlog?d=yIl2AUoC8zA[/img]</img> [img]http://feeds.feedburner.com/~ff/OpenadsBlog?i=h4Aeg1ljalc:4LdsU2VFtU8:V_sGLiPBpWU[/img]</img> [img]http://feeds.feedburner.com/~ff/OpenadsBlog?d=7Q72WNTAKBA[/img]</img> [img]http://feeds.feedburner.com/~ff/OpenadsBlog?d=I9og5sOYxJI[/img]</img>
[img]http://feeds.feedburner.com/~r/OpenadsBlog/~4/h4Aeg1ljalc[/img]

View the full article

View the full article