Product Management Insight

There were 178 billion apps (statista) downloaded in 2017. With that amount of volume, it'll be unthinkable for any major organization today to not have a mobile app that allows existing and potential customers to interact with its brand. Most Apps regardless of their purpose have some kind of analytics tracking embedded in them and one of the tracking solutions they leverage is Adobe Analytics.

Adobe Experience Platform SDK (informally known as SDK V5.0) was recently launched and it aims to give clients more flexibility around mobile SDK deployment as it leverages Launch by Adobe to publish changes in an external environment outside of the native app. This was not the case with the previous version v4 of the SDK. The reason why that's exciting is because any configuration changes to the SDK around Analytics can now be done in Launch without having to go through the App Store. There are other differences between the two versions which is covered in more detail here.

There are two primary methods to setup the AEP SDK which are either using CocoaPods or the manual method but in this post, I'll cover how to set this up manually. A lot more information is provided in the Mobile team's official documentation but my aim is to take their instructions and document it visually using my sandbox. I'm covering two main components of this setup which leverage Launch by Adobe and XCode (V10) to setup the SDK.

Launch by Adobe Setup

• Create a mobile property in Launch and select the platform as Mobile.

• We then setup extensions in Launch and by default, you should see two extensions already added called "Mobile Core" and "Profile" which are explained below. I'm not going to cover these in detail as we only need to add some basic details to the Mobile Core extension. Additionally, we also need to add the Adobe Analytics from the Catalog and install it. Let's review these extensions.
• Mobile Core: This provides essential SDK related functionality as well as the library to deploy the Experience Visitor ID service
• Profile: It stores user attributes on the client and more details can be found here
• Adobe Analytics: It provides the Adobe Analytics library to the SDK. 

• Once we've installed the extensions, we need to retrieve the iOS libraries that are accessible in the Environments section in Launch. This snippet contains a reference to libraries that need to be included in XCode to deploy the SDK (see below). 

XCode Setup

Before diving in, I highly recommend that you review the steps outlined in Adobe's official documentation on configuring the SDK. Some of what I'll cover is outlined in the documentation but I'm including a lot more detail in the form of screenshots from XCode which the documentation doesn't include. So, let's continue.

• Download XCode and setup a basic App which allows you to simulate an iOS App experience.

• Download the AEP iOS SDK from Adobe Experience Platform's Github branch located here.

• The "iOS" folder needs to be added to XCode and mapped to the Target in XCode. Once the mapping is done, we need to add some frameworks to the "Embedded Libraries" section in XCode to provide the necessary libraries to the SDK. Please note that for an actual iOS Apps, you need to use the frameworks present in "device-only" but for Simulators (my use case), you need to use the frameworks present in the "universal" folder. I've tried to color code the relevant details in this screenshot.

• Once the required frameworks are added, we need to reference all libraries and call specific methods to activate lifecycle calls, enable logging and other methods as explained here. I'm using Objective C but the documentation covers Swift and Android syntax as well. Please note that I copied the installation code directly from the Environments section in Launch (covered above) and included it in XCode which ties the SDK with Launch. I've included these methods in the AppDelegate.m file of my App. The integration with Launch is done via the configureWithAppID call to which we pass the Launch App/Environment ID.

• Once the basic lifecycle tracking methods are added, we can add a trackState (page view) method call to trigger an event. I'm basically sending data to the "screenName" variable populated with a value of "homeview". That is typically done in the ViewController.m file.

• Finally, we need to make sure that the App build is successful and test the Analytics call. In my case, I'm looking for the variable called "screenName" which is populating in the debugging console as shown below.

The Adobe Experience Platform SDK is still relatively new and is being evolved but the process of installing the SDK is fairly easy once you get through the initial learning curve. I will continue to keep track of all upcoming features and will write about other functionalities tied to Launch by Adobe to trigger different types of mobile events.

• Configure the Email Pixel: The general format of the email pixel is very similar to display banner pixels with some minor differences. Below is a screenshot of an email pixel as well as a walkthrough of the various parameters.

• Subdomain: This is the Audience Manager subdomain. In my example, it's "ags542" as per the screenshot. 
• d_event: This is the event type which can either be 'imp' (impression) or 'click'  depending on where you want to capture this event.
• d_cid: This parameter allows us to sync a user ID with AAM.
• DataSourceID: This is the data source ID created for this data point. It's '133374' in my case and I've covered this in detail below. 
• HashedEmailID: It's 'ABC789' as per the example but it can be any numeric or alphanumeric ID for ID syncing purposes.
• c_emailopen and c_campaignname: You can pass any customer specific parameters (c_) which in my case are outlined in the screenshot. Note that we will need to create rule based traits to capture these parameters.

• Create Data Source and Profile Merge Rule to Capture IDs: Given that we will be syncing user data with AAM, we need to create a cross device data source as shown below.

• Create Rule Based Traits: The next step is to create rule based tied to custom attributes that you want to capture for the email pixel. In my case, they are c_emailopen and c_campaignname. Below is what one of these customer specific traits look like.

• Deploy the Pixel in the Email Marketing Software: As explained above, once you've completed the prerequisites of setting up the data source and the necessary traits, you can go ahead and setup the pixels in your EMS. Please make sure that there are no extra spaces and the pixel should look very similar to this example where you need to include the additional "%01" and "%011" characters to follow the ID sync conventions. https://ags542.demdex.net/event?d_event=imp&d_cid=133374%01ABC789%011&c_emailopen=yes&c_campaign=ags542_test. 

• Monitor Audience Traits: This process is often not known to everyone but there is an easy way to test if user IDs synced as part of the email pixel, made it into AAM. This can be done by going to the Audience Traits folder and clicking into the ID sync trait created for email as shown below.

• Create Rule Based Traits for the Landing Page: Given that we're only capturing the email open impression and not click, the recommended approach is to create a rule based to capture users who clicked on an email tied to your landing page URL. So, the trait condition will be tied to the following attributes h_referer == AND c_campaign==ags542_test.

• Upload CRM Files (if applicable): One interesting use case of syncing user IDs with AAM is to upload demographic or other customer data from the CRM. The process is the same for uploading files in AAM and I've covered it in detail here.