One challenge for even experienced Marketing Ops teams when they start to introduce their mobile push strategy is determining which push notification provider to partner with for delivery, and then how to thread that provider’s SDK into their app. It’s a tough question for a variety of reasons, one of them being that they often don’t even know they may not need to bother with the second part at all.
When we rolled out support for sending push notifications earlier this year, the big differentiator for us was that we are offering an alternative to the SDK for those who need it. But, even when we tell first-time users that, we often get the question: What is the MessageGears SDK-less solution, and how is it different from other vendors?
The mechanics of how push notifications get sent are a little confusing. However, when stripped down to its core, there are a few basic differences between how we send push notifications that make MessageGears stand out. First, let’s dig in a bit as to why the presence or absence of an SDK matters, and then we’ll look at why going SDK-less could be an attractive option for a lot of teams.
Sending push messages through an SDK
The world saw the advent of brand-based push notifications when Apple rolled out iOS 3 in 2009 — and was soon followed with the Android platform in 2010. Since then, an entire industry has been centered on creating and servicing mobile Standard Development Kits (SDK), which are development kits that live inside the application and perform certain functions. SDKs are now the norm across the world of mobile applications, as the average application contains 18 SDKs executing code inside of it. You can find SDKs for just about everything — security, reporting, payments, and (of course) messaging.
Sending notifications via mobile SDK is, at the moment, the most common method for brands to send push messages. And there is a good reason for that too: Interfacing directly with app stores programatically can be difficult without great interaction between marketing and marketing ops departments, and the desire of the marketer for an intuitive and easy-to-navigate user interface while still delivering easily consumable reporting metrics can eat up IT resources.
It’s important to note that this isn’t unique to mobile push; this applies to other channels too! I’ve previously written on the perils of building in-house email systems.
SDK providers give marketing users all of the messaging creation and reporting they need, while still being relatively low maintenance for the IT department. All it typically takes is a one-time installation of the SDK into the application, and the SDK handles everything from there. Additionally, because the SDK is always active within the app, they can measure other things for the user — things like how long the app is open after each notification, which notifications were dismissed at what time, and many SDKs even send in-app messages as well.
However, these capabilities come with some downsides that large organizations are ever more reticent to deal with — including vendor dependence, application bloat, and cost.
The downside of using mobile SDKs
For instance, by allowing SDKs to take care of core functionality within an application, enterprises are able to slim down business logic within the application itself and rely on their vendors to carry out individual tasks. But that’s not necessarily a good thing, as it diminishes what the actual application is responsible for. In fact, one of our partners recently told me that they had more SDK code functioning within the app than app code itself.
By taking the power out of the application to carry out its tasks, brands lose flexibility in how to send and track messages, and are handcuffed to the capabilities that their SDK provider makes available for them. And because the SDKs are executing code within the application, they need space within the app to function, increasing the overall size of the app. Add to that the likelihood of an SDK crashing the application, and you can see why some IT departments are starting to more closely examine any dependencies within the application.
Finally, SDK solutions are far from cheap. In fact, cost was named a “caution” for several of the leaders and visionaries in Gartner’s recent Magic Quadrant for Mobile Marketing Hubs. Although interfacing with the app stores does not have much of an inherent cost, the overhead of building features into a UI, offering reporting statistics, and providing support add a large amount of extraneous cost to sending push notifications.
What is an SDK-less solution?
When MessageGears introduced push messaging earlier this year, we wanted to ensure that our partners had as much control as possible over the messages they were sending while still providing our marketers with the resources they’d need to improve and understand their brand communications. That’s why we chose to integrate directly with AWS Pinpoint, a highly available API interface into the app stores. Through Pinpoint, we have the ability to send any push notification possible, meaning we are able to have true feature parity with other big-name SDKs. Additionally, our hybrid solution always guarantees that marketers can use the data in their own data stores — staying true to our core promise to always allow our users to send content using their real-time data.
Sending push notifications directly through the app stores allows us to deliver messages quickly and accurately. With a throughput capacity of 25,000 push messages a second and all of the personalization capabilities that our email channel has, marketers are able to send deeply personalized communications at scale. And if you’ve seen our recent demo, you’ll recognize that message formation is easy to use and woven into the rest of our template-creation process.
But, as we know, it isn’t enough to just send a message. Engagement and attribution are core to any marketing strategy. Our restful Push Notification click tracking capabilities allow developers to easily track audience engagement with push notifications via their own application, making the application logic smarter and empowering the app to do more. And, similar to our email URL Append, our “data” payload allows the user to pass along any additional information to the application, allowing for enhanced campaign reporting that could be communicated from the app to our users’ data warehouse whenever recipients interact with a notification.
By providing end-to-end capabilities without the need for an SDK, we’ve been able to cut out pain points that are all too familiar to many users while still delivering on the core functionality that mobile marketing teams need. Following on the heels of our Deep Linking feature, we are proud to continually build and improve the ways that brands can drive interaction into their applications. But the question remains: How do you know if it’s right for you?
Figure out what’s best for your needs
SDKs may be the norm today for mobile applications, but it’s important not to let that convince you that you must find a mobile ESP partner who has one. Take into account the downsides of these SDKs and determine if your messaging operation could benefit from an SDK-less option.
If the flexibility of your current solution or your application’s dependency on third parties are challenges for your mobile application in the current SDK environment, that may be a sign that introducing another SDK into the mix may be more of a hindrance than a help. If you’ve never considered a new approach to sending push notifications, perhaps now is the time. And remember, the flexibility of an SDK-less solution allows you to send messages anytime — even if you’re already using an in-place SDK provider.
Whatever partner you choose for your mobile messaging strategy, the key is to go into the decision-making process with full knowledge of the options available to you, and why going SDK-less is an approach worth considering.