Android

More than two years ago we embarked on a journey to bring our push infrastructure to Android and tackle the world of high scalability for mobile apps. We’ve detailed some of our past achievements like C500k in past blog entries. We’ve more than quadrupled the performance reported in that post, and have moved on to address the rest of our infrastructure as we march towards supporting billions of connected devices.

We’re now focused on finishing a massive rework of our messaging infrastructure to support our exponential growth in push notification volume. The result will be released with Segments.

We deal with lots of big numbers. Big numbers are often difficult to reason about. As a metaphor, we came up with “light up a stadium in a second” as our throughput goal. Specifically, we now have the capability to send a message in one second to every fan seated in the biggest stadium in college football, Michigan Stadium.

Here’s a high-level look at what we’ll be rolling out:

• Push Tag & Broadcast Service (codenamed Metalstorm) — Manages associations between applications, devices and tags. This new service supports extremely high push throughput and gives us the ability to perform complex tag queries for apps with hundreds of millions of users across a horizontally scalable architecture.

• Segments Data Storage (codenamed Penelope) — A customized, distributed database optimized for querying spatial information including custom location data.

• Message Routing Service (codenamed Gooey ButterCake) — Routing tier that uses a Sort-Merge-Join algorithm to assemble results from queries across multiple heterogeneous systems, for example application tags joined with device location information.

• Edge Message Delivery Service (codenamed Yaw) — Handles last-mile delivery to third-party platform push providers such as the Apple Push Notification System (APNS) with high throughput and low latency. Yaw manages TLS negotiation, message TTL (time to live) and protocol compliance across hundreds of thousands of connections all performing message delivery.

Helium, our end-to-end message delivery platform for Android devices, is optimized to work with this improved messaging infrastructure and works on an expanding universe of devices including Amazon’s Kindle Fire, Nook, and soon Tizen.

We’re also going to leverage Helium for companies moving away from native apps to HTML5. We built a C++ Helium client library for Linux and are working on Tizen integration (more detail on this effort is here). The new Linux Helium client architecture includes a web runtime plugin that provides JavaScript bindings for easy development of HTML5 browser extensions for push notifications.

How improved is the new infrastructure? Our initial dark launch of the new system delivered broadcast pushes at a throughput of over 100,000 messages per second, with a 90th percentile latency of two seconds to first message delivery. We also delivered tag pushes (one API call with arbitrary tags pushing to one or more devices) at over 100,000 messages per second throughput with 90th percentile latency of two seconds before first push delivery.

What does this mean for apps? If your app has 100,000 users, and the app triggers a push notification, your users will receive that message in less time than it takes you to complete a yawn. If your app has 500,000 users, and the app triggers a push notification, your users will receive that message in less time than it takes you to pour a cup of coffee. More than a million users? Pour that coffee, add sugar and stir.

We’re just getting started. This is the low end of what we can achieve with this architecture and we will continue to invest in throughput and latency improvements. Look for an upcoming blog post on the implementation details or better yet, see us talk about it live at upcoming events such as GLUE Conference and HBaseCon.

We’re still working on rollout plans, but this massive scalability for real-time push will be available for everyone who needs it soon. We’ve already moved many of our largest customers to the new architecture. If you have a need for speed right now, and think your system can handle these performance levels before we add configurable speed throttling, let us know.

We’re also interested in understanding your expectations for push notification delivery. Complete this brief survey to get an Urban Airship t-shirt.

Amazon shipped their first Kindle Fires eight weeks ago and since then we’ve seen a lot of interest in the platform from our customers. Consumers are jumping in too, making the Kindle Fire the best-selling product across all of Amazon.com since it became available. We’re also excited about the Kindle Fire, and even more excited to let you know that Urban Airship’s Helium push notifications for Android are already deployed on tens of thousands of devices: it just works.

Over the weekend we had several customers go live on the Fire using our Helium push notifications. Glu Mobile is just one of our customers who are using our push notifications for Android in all of their games for the Fire. When we asked Glu if they did anything special to activate push in their games for the Kindle Fire, Mike DeLaet, VP of Sales & Marketing said, “We just integrated the Urban Airship SDK into these titles like we do for all of our titles, which allows us to utilize push notifications on the Kindle Fire.” Our customers depend on Push to drive engagement and provide the best user experience possible for their applications. With Helium they can do that for the Kindle Fire today.

A little background: the Fire is an Android device with a few key differences. It is missing Google’s Mobile Services (Android Market, C2DM, Google IAP, etc). Additionally, your app cannot require a gyroscope, camera, WAN module, Bluetooth, microphone, GPS, or micro-SD to function. Beyond that, it’s Android 2.3.4 with a new screen size and functions just like any WiFi-connected Android device.

We know that in the world of mobile phones, tablets, PC’s, and other IP connected devices, powerful engagement tools are a requirement for success. We’re continually working to extend our services to any device and as many platforms as possible. But device and platform support only gets you so far–and that’s where our tools come into play. Urban Airship enables you to effectively address and engage with your application audience. With our recent acquisition of SimpleGeo, the future holds many exciting additions to our products, like enabling audience segmentation on a local level for the Kindle Fire and beyond. These are exciting times and we’re just scratching the surface on what we can do.

For more details on setting up an app for the Kindle Fire and selling it in the Amazon App Store, see their Developer FAQ. If you are interested in using Helium to power push on a Kindle Fire or any other Android device, check out our Pro Plans. And finally, if you want to make addressing your Kindle Fire audience easier, take a look at our FAQ on setting tags for your Kindle Fire app installations.

With the launch of iOS5 we’ve been busy updating all our phones around the office and watching the adoption numbers go up. But along with the new Notification Center comes a whole new set of visual styles for Push Notifications on the iPhone, iPod, and iPad. So we’ve updated Push Composer with a few new previews to cover the new visual landscape that is Push on iOS5! We’ve also added a few new features to boot. There are three new ways that notifications can appear, and a bunch of new user controls for governing these new features.

Lock Screen Preview

The most common view will be “Lock Screen” notifications, which are similar to previous iOS versions but with a new style and sans buttons.

Pull Down Display Preview 

This pull-down view displays all your unacknowledged notifications in an aggregate view (by app) and lets you launch the app from any specific notification or clear them all. Each of these is now available in full preview mode within Push Composer.

Banner Notification Preview

Additionally there’s the new “Banner” notification that rotates into view at the top of the screen when your device is in use, even within other apps.

Push To A Deep Link

But that’s not all. We’ve also added the ability to send Key/Value pairs of data directly with any push from within Push Composer. What this means is that you can include a “deep link” to a specific place, page, or story within your app. This long-standing API feature is now available directly through the web interface in composer.

Improved Byte Count Accuracy

We also improved the byte counts for your message composition to more accurately reflect the total space remaining in your message, especially around non-English characters.

 All of these additions join the previously available preview screens (for users on iOS3 & 4, and Android) as well as other great features like Scheduled Notifications, sounds, badges, and tags. Timezone calculations have also received some updates. Anything you can do within a Push message in our API can be accomplished with Push Composer.

Get started with Push Composer now!

Cool: Nielsen Smartphone Analytics. Similar to those devices that track how much television people watch, Nielsen has a new effort that tracks and analyzes data from on-device meters installed on thousands of iOS and Android smartphones. The first reported data from this effort looks at Android App usage.

Among the interesting findings, the average Android user spends more time with apps than with web and only a very small proportion of apps (10%) account for most of the app usage (43%). The top 50 apps account for 61 percent of all time spent:

So if your app isn’t one of the top 10, it’s sitting idle, not getting used. Why? Because your users forgot about it on account of it doesn’t say anything to them in the pushes and such. Engage them, dangit! Context them!

Editor’s Note: This post was compiled and created by Scott Andreas, who can be reached on twitter: @cscotta.

Exploring the Durability of IP Connections from Android Devices

We see a lot of phones each day. Our Helium messaging platform serves hundreds of different models of Android devices from over 5100 global network providers in 208 countries via links running the gamut from GPRS to 3G to satellite. In order to maximize reliability and deliverability across our network, we’re continuously analyzing the behavior of our systems and the data available to us about devices in the field. Recently, we’ve taken steps to automate a more thorough analysis of these logs to understand how network interruptions impact individual devices and our system as a whole. This gives us some insight into what’s happening on these devices and the networks to which they connect.

Connection Durability as a Metric

Carriers and industry analysts have conducted many studies on the speed of mobile networks, dropped call stats, and coverage. In this post, however, we explore a different dimension called connection durability. Connection durability refers to the average duration of a mobile IP connection, or more precisely, the average number of times a device’s data connection reconnects throughout the day. While such irregular blips are unlikely to interrupt web browsing or Twitter-checking unless they occur during it, these blips do affect the reliability of background services such as sync and messaging. As these services are the lifeblood of a mobile device, it’s worth looking into what happens over the course of a tumultuous day on a mobile network.

What factors affect connection durability?

Several factors combine to result in low-quality or short-lived network connections. You’re probably familiar with many of them: walking into an elevator, taking the subway, or moving away from the windows inside a large building or descending to the basement. CDMA devices suspend their data connection each time a phone call is made. All mobile networks have dead spots. For devices using WiFi or WiMax connections, many devices will aggressively manage the link, shutting it down as often as possible. Switching between WiFi and 3G/EDGE connections also triggers a temporary drop. Task Killer apps trigger a similar effect, interrupting a connection until the service restarts. While the quality of a network may appear very good while you’re using it, most mobile phones take a silent beating over the course of the day as connectivity fluctuates.

To better understand this fluctuation, we’ve analyzed the server-side logs generated by the connection activity of a slice of one million devices on our messaging cluster. After plotting a global baseline, we’ve analyzed this data to see what we can learn about connection quality by country, carrier, and device type. Due to a variety of factors, this data does not permit us to offer firm statistical conclusions about the quality of a given network, device, or connection from a country. It’s important to bear in mind that this data speaks primarily to the ability of a device to maintain a persistent connection in the presence of all factors that diminish connection duration, including the OS itself. By analyzing this data in different dimensions, we seek to understand if any interesting correlations are present.

Diving In: Connection Events Across All Devices

Let’s start by looking at the global statistics of connection events per day across this slice of devices:

Click to Enlarge

This chart shows that most devices in this sample lose and regain their data connection fewer than 10 times per day (55%), with the vast majority losing their connection fewer than 100 times per day (96.2%). Two reconnects/day is the most frequently-occurring value, followed closely by three and then one. Following this, we find a long tail of a handful of devices with much higher reconnect rates, most likely indicating either a malfunctioning phone or one with a consistently poor connection. As a high rate of disconnect and reconnect events will typically occur when the device is in an area with marginal coverage (passing through a subway, dead spot, elevator, or building), these events are likely concentrated to small portions of the day during which adverse conditions are present.

With this data we can establish that over the course of a day, most mobile devices will experience a relatively low rate of reconnections. 55% of devices in this sample reconnected 10 or fewer times per day, averaging less than one connection event per 2.4 hours.

Geography: Breaking it Down by Country

We’ve also examined the breakdown by country. Might connection durability vary unevenly across national boundaries? Via MaxMind’s Geo-IP Country database, we’re able to map mobile device IPs to the country from which they’re connecting. While it’s not possible to reliably pinpoint city or regional data by mobile IP, we can determine the country with a high level of confidence.

Click to Enlarge

The y-axis in this chart repesents the number of times a device located in a given country reconnected throughout the day. Here, we see that devices in this sample connecting from China experience the fewest reconnections per day (12), slowly climbing upward toward Canada and the US with 21. However, after these, we see a spike indicating that connections from Indonesia, France, and Japan are significantly more volatile. While many devices in the sample from these three countries demonstrated low reconnect rates, others varied widely with samples in the hundreds of reconnects in each. Note that this plot excludes countries from which fewer than 1000 devices in this slice of data have connected.

Variations Across Mobile Networks

Surprised by the numbers in France and Japan, we broke the results down by network to see if uneven connection rates appeared at the carrier level as well. Via MaxMind’s ISP/Organization database, we can map device IPs to network providers. Parsing this data takes work, as many mobile networks function as independent systems under one brand following mergers with other carriers (e.g., AT&T and Cingular, or Verizon – Bell Atlantic – GTE). Rather than attempting to group these, we’ve provided the raw data of device-to-network mappings below. Note that this chart represents networks from which we see greater than 1000 devices in this sample connecting.

Click to Enlarge

In this chart, AT&T Global Internet Services and “Service Provider Corporation” (formerly Cingular) represent AT&T. Cellco Partnership is the corporate name of Verizon Wireless. Orange Communication SA and Orange PCS Ltd. are networks operated by Orange in multiple countries. We also see landline and fiber providers due to devices connecting via WiFi. Once again, the y-axis in this chart repesents the number of times a device located in a given country reconnected throughout the day.

Consistent with our breakdown by country, we see that connections from NTT Docomo (Japan) and Bouygues (France) experience the highest level of interruptions. Devices on these networks experience significantly more dropped and re-established data connections to our messaging cluster than on other networks in other countries. This data also shows that connections originating from landline and fiber providers are interrupted more often. With the exception of NTT and Bouygues, the upper bounds of this dataset are weighted toward landline providers such as Cox, BellSouth, Charter, and Comcast.

Device Models and Manufacturers

What variations present when we slice this data by device type? This chart represents the mean reconnect rates from devices (frequency > 1000) in this sample.

Click to Enlarge

The Motorola Xoom leads here, which may be attributed in part to the fact that tablets are less likely to be carried through volatile network conditions throughout the day. On the opposite end, LG’s Optimus V, T, and M phones showed significantly greater reconnect rates, topped out by Samsung’s Nexus S and the T-Mobile G2. The middle of the pack is dominated by an alternating flurry of Samsung, HTC, and Motorola phones. This chart does not demonstrate a direct correlation between device manufacturers and reconnect rates, suggesting that the variations between individual models (radios, chipsets, software, etc.), the networks on which they are deployed, and user behavior (such as leaving a tablet on a coffee table) may be more significant than the device’s manufacturer.

Wrapping Up

This sample is not pure enough to support statistically sound statements regarding the reliability of a particular device, carrier, or connection within a country. The number of confounding factors prevents us from making such statements with confidence. This would require a cleaner dataset, and a more thorough analysis that cuts across each of these categories to account for the variations introduced.

However, it provides a fascinating picture into the life of a mobile device on data networks deployed throughout the world. We see that these devices must be capable of gracefully and transparently handling network failures throughout the day, retrying connections and backing off as appropriate. Network and geographic factors may correlate with the ability of a device to maintain a reliable IP connection to a remote server. We can also see that devices registered on mobile data networks tend to maintain more stable connections than those connecting over WiFi via traditional network providers. Finally, the data demonstrates that connection durability rates can vary widely across different Android device models as well.

More importantly, this slice of data provides insight into the behavior of devices connected to our messaging cluster. These results enable us to tune our software and systems on both the client and server to maximize connection durability and the reliability of our messaging services, while minimizing the impact on the device. Regardless of the factors contributing to poor connections, this type of analysis provides us with a better understanding of the best, average, and worst cases that devices are likely to experience, and feeds directly back into our development process. This rigorous analysis of our data is important, and constantly helps us to improve the reliability and performance of our systems.

Post Script

We initially performed this analysis back in January on a much smaller dataset. After re-running the same jobs across a dataset about 8x the size, we found surprisingly little variation. Previously, 63% of devices connected 10 or fewer times per day (compared to the current 55%). Consequently, reconnect rates increased about 10% across a few of the dimensions we analyzed (country, network, and by device type). While a few elements changed in the new analysis, it was refreshing to see that a revisit of this data six months later validated our first analysis, paving the way for more confident, data-driven changes to our messaging systems.

It’s been a very busy week at the Airship. In addition to spending the week immersed in push notifications at WWDC and chatting about mobile at numerous events over in London, we’re now live with a bunch of new products and tools to help you optimize your mobile apps. We are excited for you to get your hands on these products – Push Composer and Reports, our new Embedded Push and In-App Purchase for Android.

Try Push Composer & Reports for Free

We’ve gotten nice response from Beta testers and have  incorporated their feedback. In appreciation of all our customers, we’re giving away Push Composer & Reports for free for 45 days.

Urban Airship Push Composer offers a clean, simple, web-based dashboard where you can craft, configure and activate your mobile messaging campaigns. Deliver messages to specific groups of users with our tag system. You can also schedule messages to go out at a time and date in the future or in real-time.

Urban Airship Reports provides quantitative data on user engagement with your apps. With the metrics now available, you can figure out how many times your users open your app, how push notification campaigns trigger app usage and how much time users are spending within the app. Presented in easy-to-interpret graphics, you can quickly and effectively monitor engagement metrics.

Sign Up Now to pump up your push.

Android Client Library, including Embedded Push and In-App Purchase now available to all. We also offer C2DM push and other cool stuff for Android.

We want to say thanks to the hundreds of developers who’ve worked with us to test and refine the latest in our Android lineup. With your feedback, we’ve streamlined integration, put together sample apps, and refined our documentation for developers. We’ve taking off the wraps and invite everyone to give the new library a try. Both C2DM + Helium Push and In-App Purchase are included in the client lib, giving you a platform for push, purchase, and engagement in just a few minutes. Our sample apps and docs should get you started; help is a click away if you need to get in touch.

More about our Android offerings:

• Embedded Push / Helium. Urban Airship’s Embedded Push operates entirely outside the Google stack, allowing mobile developers to offer richer features and reach more devices.  Now that this release is out, we’re continuing to work on new features including “quiet time” customization, an inbox of past notifications, guaranteed Quality of Service and return receipt. Additionally, Urban Airship’s Helium solution gives each app its own secure connection that is optimized to minimize battery impact. The direct end-to-end connection between each app and devices allows near-instant message delivery.
• C2DM Push Notification Support. We’ve also created an option for developers who send limited numbers of push messages to use Google’s C2DM service. Developers who choose to use this tool will need an account with Google. Please refer to the plans and pricing page for plan options.
• Urban Airship Push Composer & Reports is now available on Android as well.

As we continue to help thousands of developers send notifications and fulfill app purchases, some best practices begin to emerge. So this week, we did a guest post over at Mashable to cover some best practices for Android In-App Billing. Some highlights include:

• Make sure if you’re selling additional features and content in your app, that you’re still providing value as-is without the add-ons. People are much more likely to buy you from you if you prove your value within a free app already.
• Don’t overlook the opportunities to re-use archived or previously unavailable content. Musicians can take advantage of live recordings or outtakes to turn old material into new revenue.
• Take advantage of In-App Billing as a way to keep your app underneath the app size restrictions. Even if the in-app purchase is free, it allows you to allow the user to download content in stages, choosing what information he/she wants on the phone.

Read the whole article to get lots more information and best practices on Android In-App Billing.

Google announced today it will release in-app purchase (or In-App Billing as Google calls it) for the Android mobile platform next week. This long-awaited feature will allow Android developers richer opportunities to monetize their apps – we predict it will be the primary way Android apps will make money in the future.

As Tricia Duryee of AllThingsDigital points out, “the launch of in-app payments will literally open the door to thousands of applications currently available on the iOS platform, which have been waiting for a way to effectively monetize their applications.”

Game developers monetize apps via in-app purchase by selling additional game levels, maps and virtual goods, often via the “freemium” model, in which the app itself is free and users purchase additional content as they get more engaged in the app. In-app purchase is also key to content providers such as media companies, that sell additional news stories, chapters, or interviews from inside the application. In-app purchase is also critical for publishers to be able to offer subscriptions for their tablet apps.

All in all, this is very exciting news. As Scott Kveton, Urban Airship CEO, points out in the article, our team has been working with Google to make the integration process even easier for developers to build in-app purchase into their applications.

Our beta program is open; if you would like to be part of it, please fill out the form below. Developers will be able to get going quickly with our sample application and create In-App Purchase items for testing within their app right away.

*Beta Signups Closed*

Today we announced the availability of Embedded Push for Android. As more platforms crop up and as more devices running different versions of Android come to market, developers are challenged to build and maintain the significant infrastructure needed to support mobile features across multiple platforms. We are excited to offer Embedded Push, an alternate push notification solution to C2DM that will help Android developers and users. Our Embedded Push product is more robust than C2DM and works on versions of Android from 1.6 and newer; C2DM works only on devices running Android 2.2 (also known as Froyo) and newer and requires the installation of the Android Market and a Google account on the device. Future versions will automatically give you the option of using either C2DM our our push solution.

As part of this announcement we’re excited to be powering the ESPN ScoreCenter app, the shopkick app and Tapulous’ Tap Tap Revenge apps with this initial release.

Our Embedded Push solution operates entirely outside the Google stack, which allows developers using Embedded Push to offer richer features and the ability to do more with notification delivery and also making it so you don’t need a signed-in Google account on the device.  Examples of such features in development include “quiet time” customization, allowing end users to define times not to be interrupted, an inbox of past notifications, guaranteed Quality of Service, and return receipt. Additionally, this solution gives each app its own open connection that is synchronized to save battery life. The direct end-to-end connection between each app and end user devices allows near-instant message delivery. The platform will also support in-app purchase on the Android platform, so developers can offer additional content to users within Android apps by offering simple, one-click billing. Urban Airship will provide a single library for Android that includes support for all our product offerings, as well as direct support for C2DM in addition to Embedded Push.

If you are interested in signing up for the Android Embedded Push Beta please sign-up below:

*Beta Signups Closed*

To learn more about the detailed features and behaviors of our push messaging platform across the mobile operating systems we support, reference the table below.

Fred Wilson writes a great post about the potential for mobile notifications (which ironically I noticed from my mobile notification bar on my Android phone).

It’s been 18 months since we sent our first push notifications for Tap Tap Revenge 2 on iOS (then iPhone OS 3.0). And over those 18 months we’ve sent over 2.3B notifications to over 100MM devices on iOS, Android and BlackBerry and we’ve learned quite a bit about what it takes to be successful with mobile notifications.

The first use of notifications we saw from publishers were them looking to reach out to their users and drive engagement. They weren’t pushing, but rather, trying to shove their users back into the app. Unfortunately this doesn’t work like traditional forms of notifications (phone, SMS, email, etc). Your mobile phone is an intent driven device. You pick it up to take action: make a call, check your mail, look for notifications. This means you can’t just blast away at users with your messages and expect them to be delighted at your interruption. You have to start a conversation with them and think more about how to send the notification at the right time, to the right user when they are ready to see it–all with the right content.

If you do blast users with notifications they will silence you, or worse, delete you from their phone. We’ve seen some of our customers learn the hard way from this. When a user disables notifications they’re turning off the life blood of your app; engagement. Given the intent-driven nature of mobile devices you have to carry on relevant and timely conversations with users. (The only caveat here being sports notifications; sports fans have an insanely high tolerance for notifications–like in the hundreds per day. But again, this is relevant content to them which explains their high tolerance.)

Dictionary.com is a great example of Push done right with their “Word of the Day” notifications. Those daily updates are a natural extension of their app and brand, and a great way to keep the app top-of-mind. Other examples include Mashable sending out notifications on trending stories (instead of say every single story for the site), Groupon or Living Social sending out the daily deal, Tapulous doing in-game challenges or opt-in notifications for opt-in content. All of these are about creating a relationship and slowly dripping relevant content to them over time.

Another potential example came up during my recent conversation with Rob Woodbridge over on Untether.tv. So many app developers are still trying to replicate the functionality of their website on mobile. That’s missing the point. Take the Toyota iPhone app. You can fully configure your new Toyota, then get a quote for your vehicle all within the app. Now, call me crazy but I can do that on my laptop, and with a better experience. The app doesn’t add anything to the conversation, nor takes into account how a user may want to interact when their phone is the only computer near them. However, with your app in the customer’s hand, you could create value and conversation with that user. What if instead you could enter your VIN and have detailed information about your car? What if you could tie that to the tune-up and oil change records (instead of how most people track via receipts in their glovebox)? Now, hook in mobile notifications and you’ve got the ability to tell the user that their car needs an oil change and oh, by the way, there is a service bay that is open just a few blocks from you right now. Stop by in the next 20 minutes and we’ll give you 15% off. Now that would be an effective conversation with a user of a mobile app coupled with notifications.

Where we are really starting to see interesting possibilities are when look at a large volume of notifications. We’re starting to see trends across apps on when users consume messages, on the types of messages that users respond to effectively, and most importantly being able to aggregate this data anonymously for use by all of our customers. We’re combing through mountains of data to help make sense of it all. Imagine if Groupon could know the best time of day (for that specific user on that specific day) to send a notification because of anonymous data aggregated from how other users use other apps? This is where we see mobile notifications going along with much more sophisticated tools for publishers to send and understand their impact on usage of their apps.

The challenges are many. Each of these mobile platforms behaves differently and there is anything but feature parity across them. Being able to understand the effectiveness of notifications between iOS, Android, BlackBerry and now Windows Phone 7 is only going to get more difficult. Having a view across all of them will be essential.

We are in the early phases of mobile and just like we saw with the early days of the web, people are trying to apply traditional models to a new medium. Just like print ads didn’t translate directly to the web, the same will be true with mobile and notifications. Learning to harness behavioral data in aggregate will be the real magic I think that will unlock the potential for mobile as a successful channel for publishers to reach users effectively.