How to keep reporting siloed in Target for Native Mobile A/B tests

Description

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

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 param 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