It is a M’AD World!

A Look inside how mobile advertising really works

ravi@drawbrid.ge

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

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

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

Bird’s eye view – cont’d

Mobile Ad Evolution

Publisher Server

Pre Smart Phone

http http

Ad N/W

request

impression

click

302 redirect

Landing Page

Conversion

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.

Mobile Ad Evolution

Publisher Server (optional for apps)

Smart Phone

http

Ad N/W

request

impression

click

302 redirect

Landing Page / App Store

Conversion

http

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.

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

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/Ws and resultant revenue shared with the Publishers – e.g. 60% for publishers, 40% for the n/ws. Can be fixed CPM or CPC deals too.

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)

Mobile Ad Evolution – OpenRTB

App with SSP SDK Ad N/W 1

DSP 1

DSP 2

Ad N/W 2

DSP N

SSP Exchange

OpenRTB Protocol

request

Bid requests

Bid Responses

Win Notificationimpression

click302 redirectLanding Page / App Storeconversion

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

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-

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.

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 the multiple 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.

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.

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

Best Practices - Advertisers

• CTR By Ad unit size

CVR by Ad unit size

Conversions/1000 impressions

Best Practices - Advertisers

•

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.

Advanced Targeting

• Demo

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.

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.

Q&A