Adobe Experience Platform Mobile SDKs – Recap

This article is part of the Adobe Experience Platform Mobile SDKs mini-series. It is about the series as such.

You can find the overview here.

I don’t think I have ever done anything like the AEP Mobile SDKs mini-series before. In total, I posted 10 articles, including this one, and I did it with a weekly cadence rather than the usual 2^nd & 4^th of the month schedule.

It was hard work to keep up.

Some of the content wasn’t ready until the evening before I posted!

In hindsight, a little bit more time would have helped in some places, but posting it on the regular schedule, it would have taken 5 months to post the whole series.

So, let’s look at the big picture.

The BIG Picture

Looked at from really high above, the Experience Platform Mobile SDKs are both similar and different, compared to the old Mobile Services and Campaign SDKs.

Similar in the sense that you work with your app developer to make things happen — like tracking of Views, Activities, and specific actions, or handling the JSON responses sent by Target — in your app. Similar in the sense that there is no tag management, no “easy way in” for you. Similar in the sense that most changes require an update of the app, and that you can’t force people to update, really. Similar, also, in the sense that you’re using context data instead of explicit events and eVars.

Different, because you can change some things on the fly.

Different, because of the way the new build process is more familiar to your developers.

Different, because the SDKs can be extended by 3^rd-parties (or yourself), adding new capabilities.

Deployment Workflow

Again, from a great height, here is the deployment workflow that you can follow.

Step 1 — decide which Experience Cloud applications you want or need to use in your app. Analytics only? Target? Places? How about 3^rd-party Extensions?

Use Launch to add those applications and Extensions, then publish them in Launch and provide your developers with the code you find in the Production install dialog under the Environments tab.

Step 2 — decide which elements in your app you’d like to be able to Target, be that for A/B test or to serve content tailored to users.

Speak with your developers about how to use Target, or rather about how they take the JSON response from Target and turn it into something useful in the app.

In the example I built, I used Target to replace some text, and to decide what external content should be loaded into the app. That is just a very simple use case! That fact that you have to work with your developers is a down side of using Target in an app, but the upside of that is that you can literally do anything you like in the app with Target.

Simplified a lot, the logic is built into your app, and Target just tells that logic which path to take and/or what elements to use on the path. Sort of “you’ll have fish, here’s your fish knife” for one user, and “steak for you, here’s your steak knife” for another.

Step 3 — decide what to track, and what meta data is important for you.

For Analytics, you decide what names to give your Views and Activities (such as “Home”, “Settings”, “Profile”, “Message Editor”, etc.), and you decide whether you want to track additional data, like the language.

Again, you work with your developers here. They should be able to grasp the concepts quickly, especially because context data are key-value-pairs (“language=en”).

At the end of this exercise, you should have a list of Views/Activities that specifies what needs to be done on each one in terms of Target and Analytics.

For my (very simple) sample app, that list might looks as follows:

Step 4 — give your developers some time to build.

Step 5 — when your developers give you an early version of the app, use Project Griffon to see whether the data that flows is in line with the document and your expectation.

At this stage, you will likely loop back to steps 2 & 3 a couple of times.

Depending on how agile your developers actually work, you might even do this loop once a week. I consider that a good thing, and it will likely allow you to sneak new stuff into the app.

Step 6 — go into Analytics and map context data.

Step 7 — use Project Griffon to make sure your app tracks what you think it should track, and that the data ends up in Analytics in the right events and eVars.

Step 8 — you are done. Watch your developers release the app, and marvel in the quality of data you receive in Analytics… well, hopefully.

Notes

While using the Experience Cloud applications is still more involved on mobile than it is on the web, it has been streamlined a lot since v4 of the old Mobile Services SDK.

My highlight is Project Griffon, which finally lets me debug properly, and the fact that people can build Extensions.

And you know what’s great? Project Griffon is currently in beta, so there I guess it will a) evolve some, and b) I can at some point run an article on the final result. Secondly, people will write Extensions, and those may or may not necessitate articles, too.

There are some other things on the horizon, too, which are related, and cool.

I think I’ll write some more about mobile in 2020.

Unless you tell me not to, of course 😉