Adobe Target VEC for Mobile Apps - Part 2 - Test Build
Published on 04/09/2019
8 min read
A demo showing how to use the newly released visual experience composer for mobile applications
Dan here and this is the second part of my video series into the Adobe SDK version 5. In the first section of this series, I covered the implementation of the SDK using Adobe Launch and embedding the code with the Luma application and we also configured a deep link.
In this second section, I want to show how we would take that deep link and use it in the Target interface to pair our application and build a pretty simple A/B test and then move onto something more complicated and build some experience targeting activities that use lifecycle events to create an audience.
So if I jump across to the Target interface, we will go in and click “Create Activity”, select “A/B Test”, click “Mobile App” and by default the Visual Experience Composer will be selected, then click next. We now have to select our app – I have two prepared already but for the purpose of this demo we will pair a new app. We need to enter our deep link here that we’ve configured from the previous video – if you’re a developer, you’re going to understand exactly where this deep link comes from and if you’re a Marketer, your developer will supply this for you (you don’t really need to know how it works). If we jump back to our app and we go back into the main Luma file, into info and go to URL types, we configure the deep link by taking the URL Schemes, paste that in plus :// and then paste our bundle identifier and that’s how we create our deep link. The deep link is surfaced in a few ways – you can email it to yourself, you can scan a QR code or you can do what I’m going to do in this demo, which is simply copy it. To pair our application with Target, it is a simple case of just going back over to our application, closing it, opening up a web browser, pasting in our deep link and hitting enter. This will then ask us if we want to open the Luma app which we do, and then what we’ll see here is the Target interface should (once the app has loaded) mimic our application. So what we can see here is that our current view is the home view. This home view is something we set up in the first video from the home.swift file (you can see it here). This is the only view which is set up manually in the entire application, we use this TargetVEC.setTargetView function to set the home view so this is the view you set when the app initially launches. Every view other than this one is set automatically by Target so as we navigate around the application, the lifecycle events are passed into Target and it will automatically create the views. To demonstrate this, if I start to navigate around, we can’t navigate in the Target interface, as we would do with normal web tests that we build. The way we navigate is to actually navigate in our virtual app here. So if I move onto one of the info pages, we see our current view changes to autolumaproductinfo. Anything with this auto prefix means that it has been automatically created by Target for us. If we move back, we see our set manually sets homeview and again any other page will have the auto prefix.
So now moving onto creating an experience so obviously there’s a vast array of things you could do here such as changing colours, positions etc however I’m going to keep it pretty simple and swap out a couple of images. I’m going to take some images that I’ve already got and just swap them into our experience (excuse the aspect ratio here!) and then change the colour of this text to white so we can see it more clearly, and now that is our experience B complete. We’ll move through the Target workflow, make 100% of the traffic go through experience B so we can definitely see our experience, set up our reporting source (in this case we’ll just use Target) and engagement will be our goal, give the activity a name and then save. You’ll see that the changes we made were mimicked in our application but as should we save, they then are removed from the app. So if we then activate this experience, we will close our app and rebuild. One thing to note is that this would work exactly the same way if you were using a real app on a real mobile device that was actually live on the app store so you wouldn’t have to keep building the application like we’re doing here. Now we have rebuilt our application and we can see that our experience is being served exactly like we have just seen from the Target VEC. So hopefully now it becomes a bit clearer, once the one off implementation of setting up the Target VEC within your mobile app is done, to create simple A/B tests is really quick at this point.
The last thing I want to cover is experience targeting and creating audiences based on lifecycle events that are emitted from your mobile application. So what we can see here in the debugger is that there are a lot of things that are passed into Target when we call an mbox or we call a test so we can see that we have the Marketing Cloud Visitor ID, we have the location hint, we have all of the analytics logging but more importantly we get all of the context – screen height, screen width, colour depth, device name, device type and we get things like the view, the operating system, the carrier name (if it had one), the resolution, hour of the day but the one I want to look at here is this a.Launches.
So app.launch is a lifecycle event that is emitted every time the application is launched and that will obviously increment as many times as you open the app. I want to use this to create a couple of audiences so that we can then target content to those audiences. So if I just jump back into the Target interface, I’m going to go into “Audiences” and I’m going to create two audiences. One that is called “First App Load” and we will use the rule of custom for this and as we’ve just seen in our application it’s a.Launches we want to use and we will say a.Launches is less than 2. So anything less than 2, the visitor would be classed as being in the audience of first app launch. Save this and then I will just duplicate it to save time and we’ll call it “App Launch > 1”. So this time it will be a.Launches is greater than or equal to 2 and save it. And now I’m going to create a new activity. This time it will be “Experience Targeting”, we’ll select “Mobile App” again and “Visual” by default. This time we can select our application from the drop down list. Now it’s worth noting that once your emulator is closed, you will need to keep repairing the device, which we’ll do now. If you’re using a real device to do this, the device will remain paired forever and it will just be a case of re-launching the app and the relevant device will light up from the list here but because we’re using the emulator, we need to repair. So we’ll go back to copying our deep link so we can pair our device, paste the deep link and open the app again and now we get the app in the Target interface.
So what I’m going to do this time is create two different experiences – I’m going to create one for our first app launches and a new one for app launches that are more than one. So basically there will be an experience that is served to the user when they first log onto the app and then a different experience should be served every time they launch the app after that. I’m going to go into one of the info pages (again I navigate from the mobile application). I have some more images here which I’m going to use – I’m going to take this picture of a cat and we’ll set it as the background and then in first app loads, we’ll take our picture of a dog (obviously the tests you guys build should have more business relevance than just putting a nice picture of a dog or a cat but for testing purposes this will do!). So first app load we should get the dog, subsequent app loads we should get the picture of the cat. So again, advance through the workflow, we’ll set up our reporting source, name the test and then save. Now this has saved we’ll see our changes are reverted back to what the app looks like without the test, we’ll activate this experience targeting and once this is live, we will close our app and rebuild. What we see here is the test we built earlier and as we close this and we generate a launch event, that will be passed into Target, Target should now say we’ve launched the application once, we get our picture of the dog, close the app, launch it again, launch should now be two so it should fall into that second audience we’ve created of app launches more than one, and now we get the picture of a cat. This was just a very simple demonstration but I hope it helps you see the type of things you can do in the VEC. It does not completely replace using mbox calls to the API as you previously did with the SDK version 4 but it does mean that if you have simple experiences, tests or personalisation you want to set up, it can be done via a Marketer once the one time set up of implementing the Target VEC extension from Launch in your app is complete.
The final thing I want to mention before concluding this video is just that you are not limited to the lifecycle events like I have used here. There are functions that would allow anything to be passed into the mbox so in this home.swift file, if I scroll down from lines 80 – 95, you can see that in the “viewDidLoad” function, there are actually custom mbox parameters and profile parameters being passed in. So if I just search in here, we can see all of the lifecycle events that are automatically passed in but as we scroll a bit further down, you can see the category ID furniture (which we get from this line here) is passing in a product and an order value. This could be used for anything – it could be cart value so you could say if a user’s current cart is more than £300, we want to serve them an offer which says they get an offer of free delivery. You’d do that by setting up a variable in here which would be cart value and then it’s basically just a key value pair so it would be cart value and then you would pass in a variable that’s been created in the app that would dynamically keep passing in the value of the cart as the user navigates around the application. You would then target the experience exactly the same way as we did for our very simple dog and cat picture test earlier on - you would just literally create your audience and you would basically say (depending on what you name it) mbox cart value and you’d say if that is more than 300 then create the audience, and then you can serve any experience you wanted based off that.
That concludes the video – I hope it makes the whole SDK v5 a little bit clearer. Thank you very much for watching and stay tuned for my next video!