It is a M’AD World!

1. It is a M’AD World! A Look inside how mobile advertising really works ravi@drawbrid.ge

2. Overview • A Bird’s-eye view on the mobile ad landscape • Mobile Ads evolution • Device identifiers and Conversion Tracking • Preview on Ad optimizations (Big Data) • Best practices for Advertisers and Publishers • Advanced Targeting Demo • Miscellaneous • Q&A

3. Bird’s eye view • Mobile ads by revenue ~ $9 billion global: http://techcrunch.com/2013/07/09/iab-mobile-ad-revenue-will-pass-9b-globally-in-2013-after-83-surge-in-2012-thanks-to-smartphone-boom/ • KPCB Internet trends - http://www.slideshare.net/kleinerperkins/kpcb-internet-trends-2013 • Number of apps in iOS app store - ~ 900000 with 15Billion downloads • Number of apps in Google playstore - ~850000 with 40Billion downloads

4. Bird’s eye view – cont’d (source: KPCB Internet Trends)

5. Bird’s eye view – cont’d

6. Mobile Ad Evolution Pre Smart Phone http http Publisher Server Ad N/W request impression click 302 redirect Landing Page Conversion

7. Mobile Ad Evolution – cont’d • Lack of advanced html support like iframes, javascipt, css and cookies. • Mostly mobile web pages • Publisher side integrates Ad N/W code (in a particular language – php, ruby, java etc..) which proxies http request from device to the Ad N/W servers – HTTP headers from device very important. • Ad N/W responds with a html snippet which is embedded on the publisher servers before going to the device. • Winning Ad based on closed second-price auction. • Mostly Text ads, but banner and video supported in some makes and models. • Revenue share between Ad N/W and Publisher – e.g. 60 – 40 split. • Advertiser usually charged on CPM (brand display) or CPC.

8. Mobile Ad Evolution Smart Phone http http Publisher Server (optional for apps) Ad N/W request impression click 302 redirect Landing Page / App Store Conversion

9. Mobile Ad Evolution • Smart phones usually support advanced html features – iframes, javascript, css and so on. • On mobile web pages, tag based systems ensure request sent directly from the device to the Ad N/W servers • Arrival of native apps supporting ‘web containers’ in sandboxed environments along with App Stores. • Native apps usually embed Ad N/W SDK • App Stores emphasize ‘conversions’ rather than ‘click’ optimizations for performance based advertising. • With 3rd party conversion tracking, there can be more than one HTTP 302 redirect hops before reaching the landing page / app store. • Lack of X-domain cookies still a major hurdle compared to desktop online ads – ‘common cookie jar’ in the latter a crucial driver for various innovations in the online ad industry. • Richer Ad units possible along with the usual Text and Banners. • Along with CPM and CPC, now CPI a major component in revenue models for performance based advertisers.

10. Mobile Ad Evolution - metrics digression • Basic metrics that are tracked: • Requests • Impressions • Clicks • Conversions • Derived metrics: • Fill rate % = (impressions/requests) * 100 • Click-through-rate (CTR %) = (clicks/impressions)*100 • Conversion rate (CVR %) = (conversions/clicks)*100

11. Mobile Ad Evolution – metrics digression • Spend metrics for Advertisers: • Cost-per-Milli (CPM) = $ / 1000 impressions • Cost-per-click (CPC) = $ / click • Cost-per-install (CPI) = $ / install • Cost-per-acquisition (CPA) = $ / acquisition (CPI is a particular case of CPA ). • Advertisers charged based on the aforesaid spend models by Ad N/Wsand resultant revenue shared with the Publishers – e.g. 60% for publishers, 40% for the n/ws. Can be fixed CPM or CPC deals too.

12. Mobile Ad Evolution • Traditional Ad N/W model limitations: • Proprietary integration for each n/w if publisher need to work with different ones. • Mediation layers somewhat mitigate this problem • Overall less transparency • One solution: Mobile Open Real-time-bidding (OpenRTB)

13. Mobile Ad Evolution – OpenRTB Ad N/W 1 App with SSP SDK DSP 1 DSP 2 OpenRTB Protocol SSP Exchange request Ad N/W 2 Bid requests Bid Responses Win Notification DSP N impression click 302 redirect Landing Page / App Store conversion

14. Mobile Ad Evolution – OpenRTB • Mobile OpenRTB spec: http://code.google.com/p/openrtb/downloads/list (version 2.1) • JSON based protocol • Increased transparency • Publisher inventory available in a competitive open market • Pricing/Operational efficiency

15. Mobile Ad Evolution – OpenRTB • Leading to specializations: • Supply-Side-platforms (SSP) - Publishers/App Developer side focus • Demand-Side-platforms (DSP) – Advertiser focus • An ad request translates to several bid requests to all demand participants, and the highest bidder (CPM) picked as the winner. The bidders are expected to respond within 120ms. • SSP exchanges select a winner by closed auction (usually second price), and the winner notified with the CPM price in real-time • DSPs’ buy impressions on a CPM basis, but most likely getting paid only on CPM, CPC or CPI basis – effectively a trading platform! • Publishers / App Developers can set a price floor for various ad units dynamically. • For more details refer to: http://www.mikeonads.com/2007/05/01/the-ad-exchange-model-part-i/ • Sample RTB requests and responses - http://doc.drawbrid.ge/#65,67,88-

16. Device Identifiers • Crucial for conversion tracking (see best practices)! • Only available in native app traffic. • iOS 4 and older – usually SHA1 of UDID (now deprecated). • iOS6 and above – Identifier-For-Advertisers (IDFA): • Usually passed in raw. • Users can turn off tracking, or change the identifier (transient). • During transition between UDID deprecation and IDFA, various solutions were in place: • SHA1 of MAC Address (all uppercase colon separated) • ODIN1: SHA1 of MAC Address in byte form • OpenUDID (uses iOS Pasteboard) • iOS7 onwards: IDFA the only approved device identifier: • Pasteboard changes deprecate OpenUDID • MAC Address api always returns 02:00:00:00:00:00 • Android ID (permanent identifier) still acceptable in Android platforms along with IMEI.

17. Device Identifiers – cont’d • Real-time conversion tracking essential for CPI based campaigns. • Conversion events can be latent • Standard click to conversion window is 14 days but can be configurable in some DSPs’ • Various third-party conversion tracking solutions now available which solves themultiple attribution problem – usually ‘last click’ wins. • Increasingly advanced advertisers demand post-conversion optimization – analyzing life-time-value (LTV) of users. • Conversion tracking still possible without device identifiers via ‘device finger-printing’ approaches at the expense of accuracy.

18. Ad Optimizations – Big Data • In a nutshell, serve the most optimal ad that maximizes advertiser ROI and other goals, and maximize revenue to the Ad N/W / DSP and publishers. • Optimal Ad selection based on various features/dimensions: • Attributes of the source of the request (native app or mobile web page): • Keywords • categories • Ad position • Ad dimension • Geo Location (Country, State, City) • DMA zone • Past performance of Ads under various dimensions: CTR, CVR • User attributes (behavioral targeting): • Demographic (Age, Gender, Profession, Income Range) • Audience segments applicable to the user (technology professional, high-income) • Much more! • With OpenRTB, effective bidding strategies! • Details not in the scope of this discussion but happy to answer them in the Q&A portion.

19. Best Practices - Advertisers • For CPI based campaigns, collect device identifiers for real-time conversion tracking either via 3rd party conversion tracking solutions, or in-house approaches. This needs to be integrated to Ad N/Ws and/or DSPs’ • Have all the various standard IAB creatives for banner ads ready. • Well designed creatives that grabs user attention. • Periodically refresh the creatives (for at least top performing units every month) • Choosing the right campaign strategy: • ‘Run of Data’ • Audience Targeting • Re-targeting (Desktop to mobile or vice-versa) • Post-conversion optimization • Support ‘App urls’for launching and deep-linking (if applicable) – can enable ‘re-engagement’ and other post-conversion optimizations: http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html

20. Best Practices - Advertisers • CTR By Ad unit size CVR by Ad unit size Conversions/1000 impressions

21. Best Practices - Advertisers

22. Best Practices - Publishers • Ensure advertising fits into the larger monetization strategy • Free version of app with Ads leading to fuller paid versions • In-App purchases • Freemium model • Design up-front on where to place the ads - native app or mobile web page • Use device ids (for native app publishers) to maximize revenue from performance-based advertisers. • Provide as much hints about the user as possible – see sample ‘user’ fields in OpenRTB spec. • Maximize on larger ad unit sizes – e.g. interstitials, using natural pauses/breaks in the app to present ads (e.g. - leveling up in a game), not too distracting to the users and so on.

23. Advanced Targeting • Demo

24. Misc. • Lot of improvement and innovation possible in richer ad units highlighting mobile strengths: • Geo Location • Click to Calls • More interactivity (esp. in tablets) • In-App purchases (Ads leading to purchases without exiting the apps) • ‘Re-engagement’ campaigns • Dynamic Ad creatives • Native Ads - increasingly a popular ad unit’that fits well into the app or web page content – e.g. Facebook mobile feeds.

25. Misc. • Future trends seem to indicate moving towards ‘cross screen advertising’. • Re-targeting from desktop to mobile or vice-versa – e.g. user doing some preliminary research in a mobile device, but completing the transaction on the desktop. • Devices will include next-generation DVRs’ – convergence of desktop/laptops, tablets, smart phones and TV. • Ability to link users across their various respective devices. • Taking to the next level, ability to link online campaigns leading to a offline purchase.

26. Q&A