Integrating Adobe Target and Audience Manager into a Major American Bank's Mobile App

[#1]

Author: Vinay Sodha

Learn how Adobe delivered a successful proof of concept and technical specification for Bank of America, allowing them to use AAM segments in Adobe Target for their mobile app.

As an Adobe Target consultant working with a major American bank, I am fortunate to be on the front line of engaging projects. The bank is continually evolving and looking for new ways to take their personalization and DMP investments to the next level. This year, its pursuit has led teams there to an integration project between Adobe Target and Audience Manager (AAM) within the Bank’s mobile app. This Target/AAM integration is something the bank currently leverages outside of the mobile app on their responsive site, so there has been a general excitement on both sides to extend this functionality to their mobile app. Also, the use case was simple — we all wanted a way to leverage AAM segments to create personalized experiences in Target for both the bank’s responsive site and its mobile app.

With the bank already taking advantage of Target’s RESTful APIs to power its mobile app, we had a solid foundation upon which to build and extend that functionality. The first step towards success was to have a cross-collaborative team in place to put together a proof of concept and technical specification that would work for the bank. On the Adobe side, we assembled a team comprised of a multi-solution architect along with Target and AAM consultants.

To deliver a successful proof of concept and technical specification, there were quite a few challenges we had to overcome. Rather than one comprehensive endpoint used across the mobile app, the bank has three unique endpoints that include Target’s REST v1 API, REST v2 API, and a non-native portion that leverages the at.js library. As a result, we needed to deliver a solution that would work across all three of these endpoints.

Since we didn’t have access to lower-level environments on the client side to prove out our solution, we turned to Postman to formulate requests and verify responses for a successful Target/AAM integration. With the help of Adobe Engineering we were able to take advantage of a feature in the Target APIs that would allow us to pass in the various AAM parameters required along with an Experience Cloud ID (previously known as Marketing Cloud ID) to allow AAM segments in Target activity targeting.

Figure 1: An example of how AAM parameters are passed in for the REST v1 API request.

 Figure 2: An example of how AAM parameters are passed in for the REST v2 API request.

To get started, we used the Target/AAM integration on the responsive site as a basis to pull together example parameters that we could then pass to the API requests. Once we had that we could set up a proof of concept Target activity that would have, in the targeting, a simple AAM segment of our choosing.

Using an AAM segment in our Target activity audience.

A successful proof of concept showed us that, falling into the Target activity we set up, we were able to match the AAM segment associated in the audience. Using a combination of Postman and the response token feature in Target, we were able to confirm a successful match of our POC activity looking at the response:

Figure 4: Response token.

 With this Target/AAM integration proven out for the REST v1 and v2 endpoints, we just needed to prove out the non-native portion of the bank’s mobile app. The good news was that, since the non-native app leverages the same at.js library as the responsive site, proving it out would be relatively straightforward. To verify the last endpoint we took an XHR request made by at.js and adapted it with the appropriate AAM parameters. A successful match would return back our expected Target activity and therefore match AAM segment in the response token.

Figure 5: Response token confirming an AAM segment match.

Thanks to a great team effort, we were able to create a successful proof of concept and technical specification. Look out for part two of this story in the near future, where we take a look at the next step in the process: taking the POC to a live implementation.

Originally published: May 04, 2020