Introduction to Adobe Mobile Services

10 Sep 2017 » Mobile

In most of my posts, I refer mainly to the Adobe Experience Cloud applied to the web. I have written a few posts on mobile apps, but I have not yet written an introduction to Adobe Mobile Services. In my experience, it has surprised me the lack of knowledge there is about what you can do with an app. Today I will explain how to use the Adobe Experience Cloud with mobile apps.

Comparison between websites and mobile apps

Let’s start with the basics. We are all familiar with websites and mobile apps. We can clearly see that they are very different in many ways, but there are some commonalities too. Let me summarise the most important of both, which apply to the usage of Adobe technologies.


As you can imagine, there are many differences between the two technologies. Just by launching an app or accessing a website with your browser, you can clearly see they are not the same thing.

  • Technology. Websites are created using technologies like HTML, JavaScript and CSS. Some organisations have tried to port these technologies to the app world, but have largely failed (anybody remembers Firefox OS?). Nowadays, the main technologies are Java (Android) and Objective-C/Swift (iOS), completely different from web technologies.
  • Data persistence. A mobile app is like any other computer program. When launched, you have an instance of the app running continuously while you interact with it. As a consequence, mobile apps keep the data while the app is running and the operating system offers a way of storing data permanently. On the other hand, each individual web page is completely independent from the previous and the next. This statement applies even to pages from the same website. Therefore, by default, no data is persisted while you browse a website. The most common solution to this limitation is through cookies, but this is not the only one. Apps do not have cookies, as they do not need them.
    Note: I am fully aware of single page apps, but I am not considering them in this description as they are still not that common.


Again, I will only cover those commonalities that apply to this post.

  • Interaction. Both websites and apps expect very similar interactions from the user. Clicks and taps, move from one screen/page to another, menus, downloads, links…
  • Interface. Except for mobile games and a few other examples, most apps behave very similar to a website. Basically, you navigate between different screens or pages, interacting with them.
  • Links. It is possible in both cases to create internal links to go from one part of the web/app to another. And you can also create external links to launch the app or go to the web from an external source.

Web solutions used in mobile apps

Looking at the commonalities from the previous section, it was clear to Adobe that the existing marketing solutions for web technologies could be used with apps:

  • Marketing Cloud ID Service. It creates a unique ID, which all other solutions use. Instead of using a cookie, the data is persistently saved in the mobile storage. Unless a user deletes and re-installs an app, it will keep the same MCID. Remember that in the web browser, you can easily delete cookies. It can even capture the CRM ID when the user identifies himself.
  • Adobe Analytics. Track the interactions of the user with the app. Instead of clicks we have taps, but the concept is the same. It is even better with apps, as the visitor metric is more accurate since the MCID is only seldom deleted. It is usually good practice use a separate report suite for apps, but nothing prevents you from using existing ones and combine web and app data in a single report suite.
  • Adobe Target. I have already explained how to optimise mobile apps with Adobe Target.
  • Adobe Audience Manager. With and Adobe Analytics implementation in place, AAM will get exactly the same data as Analytics. You can create traits and segments, exactly as with the web. You can even capture the GAID/IDFA and target the same user in other apps with tailored messages.
  • Adobe Campaign. One of the many capabilities of Adobe Campaign is to send push notifications to mobile devices based. You can use all segmentation and personalisation capabilities from Campaign.
  • Adobe Experience Manager. You can use AEM as the backend and content management system of the app. Instead of delivering HTML, using other technologies, like JSON or XML, the app and AEM can communicate.

As you can see, with some minor tweaks, you can use most of the Adobe Experience Cloud for both apps and websites.

Mobile-only features

mobile only We have just seen how we can take advantage of the commonalities between web and apps. However, mobile apps have some distinctive features, which cannot be found in webs. Adobe Mobile Services is the solution to address these features, which are not present in any of the Adobe solutions. Let me summarise these mobile-only features.

  • Lifecycle metrics. Since the app is installed in the device and it can use its permanent storage and access mobile technologies, additional metrics and dimensions can be gathered. Some examples are: number of launches, number of first launches (which will be very close to installs), app version, crashes, previous session length…
  • Acquisition. Linking is deeply engraved in web technologies. In fact, it is arguably one of the key features of the web. Using the Marketing Channels report, you can analyse where your traffic is coming from. The situation in apps is very different. For starters, you need to actively install an app. The main mobile operating systems (Android & iOS) do not provide any information on why an app was installed. As a consequence, you can create a great marketing campaign to promote you app, but you will only get some basic reporting, like number of downloads. If you want to go deeper than that like, for example, which email/link/affiliate… is driving more app installs and conversions, you need to use one of the services within the Adobe Mobile Services: acquisition.
  • Location. All modern mobile devices include location features, like GPS. If you configure the app with the right permissions, you can get the mobile device location to perform some additional activities. For example, when the user is within the vicinity of a point of interest, track it in Analytics or show a message on screen.
  • Messaging. Mobile operating systems support push messages, which I am sure you are tired of receiving. However, well used, you can use them to re-engage with your customer base. Adobe Mobile Services supports push messages and also the capability of showing in-app messages. The most important piece of this offering is that you do not need to embed these messages in the app when you submit it to the app store. You will have noticed that this feature is duplicated in Adobe Campaign.

I will address each of these mobile-only features in future posts.

Adobe Mobile SDK

In order to get all of these features (web solutions and mobile-only), it is necessary to include additional code in the app. This is very similar to the web libraries where you need to add VisitorAPI.js, AppMeasurement.js, mbox.js/at.js or DIL. The main difference is that, in apps, you only need to include one library, the SDK. There are versions of the SDK for the main mobile operating systems, but Android and iOS get more updates than other environments.

I will not explain how to use the SDK in this post. If you want to know more about it, here you have the documentation:

Related Posts