Create mobile tag properties

Used by thousands of customers for web tag management, Adobe Launch can now be used to manage your mobile SDKs. Let’s take a look at creating a new mobile property in Adobe launch.

When creating a new property in Launch, you are now presented with a choice between web and mobile. Selecting mobile allows you to name the property. You can also change the privacy’s default settings to opt in, opt out or unknown. These settings control the default state of data collection in your application and can be useful when designing your application to be GDPR compliant. On the property settings page, you can also toggle HTTPS on or off.

After creating a mobile property, you can begin to manage all of your SDK configuration settings. First, let’s take a look at what has been set up for you. When you navigate to the extensions page, you’ll see that you already have pre-installed the Mobile Core and Profile extensions. With Adobe Launch and the new Experience Platform SDKs, you can add extensions to your SDK build to augment your application with additional features and functionality. The Mobile Core extension is the base SDK which is needed to provide lifecycle event data to all other solutions. The Profile extension allows the SDK to store client-side data that can be accessed across sessions. Clicking on the catalog, you can see additional extensions that can be installed and configured for your application. Right now you can see that we have created extensions for Adobe solutions such as Analytics, Target and Audience Manager. Having all the Adobe solutions managed as extensions allows for maximum control and flexibility of your SDK build.

Moving on to adapters, you’ll see that we have pre-created a “managed by Adobe” adapter for you. All this simply means is that Adobe will take care of hosting your SDK configurations for each environment that you set up.

Clicking on environments, you will see that there is a Development, Staging and Production environment created automatically for you. Each environment created represents a different hosted configuration endpoint. For example, in an iOS mobile app development workflow, you could wire up the SDK build in your Xcode project to the Launch development environment, while a separate build in TestFlight is hooked up to the staging environment. And finally, your released application should be configured to point to the production environment. Depending on your needs, you can configure multiple development environments, but you will only ever have a single staging and production environment.

Next to each environment, you will see a package icon that will pop up a window with installation instructions that can be used to quickly pull the Adobe Experience platform SDK and select the extensions into your application project.

We’ll come back to this in a minute.

The publishing tab is where you control how SDK configuration changes are deployed. A bundle of configuration changes is called a library. By clicking the Add New Library button, I’m taken to a screen to name that library and then select the initial environment for deployment.

After that, I can choose which resources or changes I want to include.

This level of granular control is incredibly powerful as it provides the flexibility to deploy or test specific changes rather than going with an all or nothing approach. You can see that I can add all changed resources, or I can selectively add or remove items to my library build.

Once I’m satisfied, I can click Save & Build for Development.

You will see that the publishing workflow will now show progress to save these changes up to my development environment endpoint. If I want to progress this build to my staging environment, I first need to approve it, and then Build for Staging.

This same process is followed for pushing your library build to into production.

Coming back to environments, you notice that if I click on the installation instructions for my development environment, I will see the Gradle and CocoaPods snippets for bringing in the appropriate dependencies.

What’s important to remember is that this set of installation instructions window will only affect, will only reflect the set of extensions that have been published as a build. Let’s see how this works.

Suppose I want to add the Adobe Target extension to my build. Notice that the Target extension is not in my current set of installation instructions. I’ll navigate back to the extensions tab and then click on the catalog to add my Target extension.

Next, I need to add this to my development build. So I’ll click on the Publishing tab and click Add New Library.

I’ll click Add All Changed Resources and I’ll see that the Target extension will be a part of this new development build.

I’ll click Save & Build for Development.

After getting the green light, I can go back to my environments tab and click on the package installation instructions for development.

You’ll notice that the Target extension now appears in the installation instructions for both Android and for iOS.

It should be noted that you only need to go back to the environments tab for updated installation instructions when you’re adding new extensions to your build for the first time. Subsequent configuration changes to the extensions, or the addition of any rules or data elements, will be deployed automatically and don’t require you to come back to the environments tab for new installation instructions.

Thanks for listening to this overview on configuring mobile properties in Adobe Launch, and make sure to check out some of our other video content on working with the Adobe Experience platform SDK.