Testing Guide

This article takes you through the following.

Verifying events and actions your app sends to Marketing Cloud Personalization
Testing mobile data campaigns
Troubleshooting campaigns
Testing campaign URLs on your mobile device

The Event Stream on the Personalization UI enables you to verify the events and actions your app sends to Personalization.

To check the incoming event stream, do the following.

Log in to the Personalization UI and select the Dataset.
From the left-hand menu, click Reports > Event Stream.
Set the Event Type filter to Mobile and look for actions sent by the app.

If you followed the steps in the Tracking guide and are still not seeing any mobile events appear in the specified dataset, get assistance by logging a support ticket.

You're ready to test your mobile campaigns once you've completed the following, as described in the Mobile Data Campaigns and Tracking guides.

Created a mobile data campaign for your dataset/app in the Personalization UI.
Implemented a CampaignHandler for the campaign's target
Tracked actions/events from the same Screen as the CampaignHandler

Put a breakpoint in your campaign handler, and navigate to the screen with that campaign handler and action/event.

If testing or integrating on a non-production dataset, consider setting the campaign state to Published. As long as the rules are easy to fulfill, you can use the app as the user would.
If you are on a production dataset, you should set the campaign state to Testing and enter test URLs in the mobile browser on the device. For more information, see Test URLs on Device.

If your campaign handler is not getting called, there are a few things to troubleshoot:

Ensure the screen/context sends the actions/events (use getScreenForActivity, not getGlobalContext). Additionally, if the campaign has an action rule, ensure the action being sent matches the rule.
Ensure the target defined in the mobile data campaign in the Personalization web UI corresponds to the target used in setCampaignHandler(CampaignHandler handler, String target). It is case-sensitive.
Ensure any campaign rules are reasonable and are being fulfilled.
If the campaign is unpublished, use the Test URLs in the mobile browser on the device.
Ensure the campaign's key/value pairs have valid formats and provide fallback or default values as desired or supported. Personalization will only send the campaign if a value is determined and found.
If using a recipe for recommendations, test that the recipe is providing results.
Consider temporarily using more straightforward key/value pairs.
Consider temporarily removing or loosening campaign rules.

Also worth checking:

You may want the campaign control percentage to be 0% while testing. The default is 10%.
Ensure the key(s) defined in the campaign match the key(s) the campaign handler expects.

If you followed the steps and are still having issues with your campaign, get assistance by logging a support ticket.

To easily manage test campaigns from the device without any additional code, you can open campaign-related URLs in the mobile browser. For this to work, you app must be configured to use its Personalization-generated URL Scheme. For more information, see EvergageActivity.

Test URLs can enable all test campaigns, a specific experience, or disable testing. For information on test URL formats, see Test URLs on Device.

To start testing, once the Personalization-integrated app is on the device, open the default web browser on a mobile device and enter a test URL. The browser will attempt to redirect to the app's Personalization URL scheme. On some devices, you may need to manually click the HTML link that appears. Once the test URL is fully processed, you should see a confirmation message.

You can also find generated test URLs in the Personalization UI. Under Campaigns, select the mobile campaign you want to test. These URLs are generated using the Personalization AppID of the first app used in a Campaign Source Rule, or the AppID of the first enabled app found.

These are the URL formats to type into the mobile browser on the device. Android typically requires a redirect or link-tap from the mobile browser to actually trigger an intent-filter. These URLs are based off the app's Personalization AppID, but will attempt to redirect and display a tappable link to the format based off the Personalization URL Scheme (as defined in processIntent).

Purpose	URL Format	Description
Test all campaigns	`<URLScheme>://test/all`	In addition to default behavior of showing mobile campaigns in `Published` state, also show mobile campaigns that are in `Test` state. All campaign rules will still be active.
Test a specific experience	`<URLScheme>://test/<ExpId>`	In addition to default behavior of showing mobile campaigns in `Published` state, also show the particular experience of a mobile campaign, regardless of that campaign's state and rules that normally determine when its shown.
Stop testing	`<URLScheme>://test/none`	Return to the default behavior of showing mobile campaigns in `Published` state only.

For the URL formats listed in the preceding table:

<URLScheme> is the Personalization-generated URL scheme for the app, which is located in the Personalization UI: Select Dataset, then Settings > Sources > Apps > (this app) > URL Scheme: (format "evgxxxxx").
<ExpID> is the ID of a specific campaign experience, which can be found in the Personalization UI: Select Dataset, then Campaigns > Campaign Summary of the campaign the experience is in.
The URLs require two parameters: a, the app ID, and t, the campaigns or experience to test.
These URLs do not aggregate or combine. The most recent one determines the behavior.
Testing lasts for 30 minutes, or until app termination or another test URL is entered.