How to keep reporting siloed in Target for native mobile A/B tests

Last update: 2022-11-08


Adobe Target

What is the recommended approach for developing, testing, and releasing A/B tests for native mobile with Adobe Target so that test traffic does not impact production metrics?


Most mobile engineering teams use the same code base from dev, staging, QA, pre-prod, and prod.
To keep the reporting separate, you should change the mbox/location names of the dev app, or have a specific mbox parameter for dev builds that are not passing in the prod app.
For example, the dev team could pass a key-value pair for each environment, something like env=dev, env=prod.
A campaign should be set up in Target for each environment to keep reporting clean when QA happens.
So you could have a QA campaign setup on mbox location “QA”, or with audience condition that checks for env= QA, and likewise do the same for a production campaign.

On this page