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

Description description

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?

Resolution resolution

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.