One of the big initiatives that Marketo launched last week at Summit 2015 is Mobile Engagements. To coincide with that initiative, they have posted an iOS SDK onto their Github account to easily drop into your apps to collect usage data and interact with your users.
There are some cool things you’ll be able to do with this technology. Imagine one of your customers has an appointment coming up that needs to be moved or cancelled. You send them an email but they don’t open it or respond. You can send them a notification letting them know that their appointment needs to be changed to make sure they aren’t going to show up to something that isn’t going to happen. That’s pretty cool, and a great way of treating your customers right.
There are also lots of ways this can be abused. Even some of Marketo’s examples are clear ways that I would delete – or at least disable notifications on – your app. Here are some things you should keep in mind if you’re going to be a good iOS citizen:
- Send useful push notifications that your customers ask for, or would be helpful to them directly.
- Do not send advertisements as push notifications.
- Do not send push notifications for new versions of your app. The App Store supports auto-updating, and has an update button on the tab bar in the navigation. Your users don’t need to be prompted to update their apps anymore.
- Do keep in mind your users’ privacy. We hear this message from Apple all the time: respect your users. Don’t do anything creepy with their data. Treat them well.
All in all, it’s kind of an incomplete picture right now. We know the functionality exposed by the SDK itself, and a little bit of what they’re doing behind the scenes. Friday is going to be interesting, and I’m planning on digging into the new offerings. My goal is to have a follow-up with more thoughts about the SDK and a sample project next week.
On to the juicy technical bits of the SDK:
First of all, it doesn’t work yet. Marketo’s website will not support Mobile Engagements for a few more days, as it will rollout on April 24, 2015. I’m looking forward to seeing what is possible after everything goes live.
The SDK ships as a framework. You can download it from the Github page or use Cocoapods. I’m very happy to see that they added Cocoapods support since that will make keeping up-to-date really easy. I’m not a huge fan of the framework being distributed with no source code, but I have been told that open source is coming through a closed Github issue. I’ll be pleased when that happens.
You’ll want to look over the readme for the project, because there are a few frameworks to link in. You’ll need SystemConfiguration, Security, CoreTelephony, and CoreData. It won’t build without CoreData or CoreTelephony. I don’t know what it’s doing with those frameworks for sure, but I did decompile the framework using Hopper and it looks like Core Data is being used as an offline cache for activities that get sent when you’re back online. That’s my guess anyway.
There are only 3 classes exposed in the SDK: Marketo, MarketoActionMetaData, and MarketoLead. These all are just NSObject subclasses and they’re pretty straightforward. It’s clear that this SDK is supposed to be a set it and forget it kind of thing. I appreciate the simplicity of a small interface, but I’m excited to see the implementation soon.
To get things started, you should initialize the API in your application:didFinishLaunchingWithOptions: method in the App Delegate. Just call -initializeWithMunchkinID:appSecret:launchOptions: on the Marketo class. From there you can use the +sharedInstance singleton throughout the rest of your project.
Once you’re up and running, you can associate a lead with the client, register for push notifications, and report actions to Marketo. When the backend gets enabled on Friday I imagine you’ll be able to customize what actions your customers can respond to in order to drive things like sending notifications on their devices or emails to their inbox.
