Verify the token and secret are for the correct app.
Verify the use of the latest SDK.
Verify you’ve updated the app version in the Upsight Marketing Dashboard (App Settings).
Verify the token and secret in your app's code match the token and secret in the Upsight Marketing Dashboard. Make sure that you’re looking at the correct version of your app in each case: iOS vs. Android, Free vs. Premium, Phone vs. Tablet, etc. A mismatch will cause Upsight to fail in numerous ways. Your token and secret can be found in the “App Settings” section of the Upsight Marketing Dashboard.
Please always use the most recent version of our SDK to get the most recent feature improvements and bug fixes. Check our SDK page to see if there is a more recent version of our SDK.
Setting up your App Version (this is your app version i.e.
188.8.131.52) that is set up in your IDE to control versioning of your app. By constantly keeping an updated list of app version, you enable the ability to target different versions of your app out in the market.
Opens are vital function to Upsight’s platform and failure to implement them will cause your session metrics (and all metrics based on number of sessions) to be incorrect, and cause numerous other Upsight failures. Open calls on launch and resume are absolutely mandatory for an Upsight integration.
To set up the Open calls in your app’s code, please see the Opens section of the appropriate Getting Started Guide for the SDK or Plugin you are using.
To set up the Placement calls in your app's code, please see the Content section of the appropriate Getting Started Guide for the SDK or Plugin you are using.
Your app should make a Content Call (usually to
app_launch) when launched. This is vitally important, as it is often very useful to be able to show the user a content unit as soon as the app starts up.
Your app should make a Content Call when restored from the background to the foreground (usually also to
app_launch). Omitting this is a common integration error and represents an enormous loss of potential revenue and/or opportunity to connect with your players. Approximately 70% of Upsight app “launches” are actually resumptions from background.
You should test each of the Upsight placements in your app. When you arrive at the point in your app where the Upsight placement should trigger, verify that a Content Call is made and that the Placement Identifier is correct.
To see if a placement has been called, check your console log for a call to
http://api2.playhaven.com/v3/publisher/content/. This call should contain a
placement_id= parameter that should be set to the name of the placement.
Verify your content units in the Dashboard are linked to the proper Placements in your app, otherwise they will not appear, or will not appear in the correct place in the app.
Verify your content units in the Dashboard are targeted at the correct segments (not leveraging segmentation will result in your content unit being sent to everyone).
Verify the scheduling and frequency capping are set the way you want them to be set.
Verify the Announcement appears.
If the Announcement has a link to the review section of the app store, test the link to verify it works and sends the user to the correct location.
If the Announcement contains a URL or URI, test the URL or URI to ensure it goes to the proper location.
For instructions on setting up an Announcement in the Upsight Marketing Dashboard, see the Announcements section.
Note Some older versions of the Upsight SDK (pre 2.x) do not support URI links in Announcements.
Verify that the Internal Cross-Promotion appears.
Verify that tapping on the Internal Cross-Promotion takes the user to the appropriate place in the App Store.
For instructions on setting up an Internal Cross-Promotion in the Upsight Marketing Dashboard, see the Internal Cross-Promotions section.
Note If a device has installed and run a given app (e.g. “App X”), then “App X” will never appear in an ad or cross-promotion on that device. (To test an Internal Cross-Promotion on a device that has already run that app, make the device a Test Device. Then this suppression will be turned off.) Note that to do an Internal Cross-Promotion for a app, it must be set to Live in the Upsight Marketing Dashboard.
Verify that the More Games Widget appears.
Verify that the “Featured Game Preroll” (i.e. a full screen ad that appears before the actual More Games Widget) is enabled or disabled, according to your preference.
Verify the More Games Widget is showing the type of games you want (Internal Games, Advertised Games, or a combination of the two).
If you are showing advertised games, verify the filtering is working the way you want.
If you are using a Notification Badge to put a red number on your More Games Widget button, verify it appears correctly.
For instructions on setting up a More Games Widget in the Upsight Marketing Dashboard, see the More Games Widget section.
To set up a More Games Widget Notification Badge, also called a Notification View (i.e. a small red number that appears on your More Games button to show the number of new games available) please see More Games Widget section of the appropriate Getting Started Guide for the SDK or Plugin you are using.
Putting a Notification Badge on your More Games button increases traffic to that button greatly (~300% in some of our tests).
Note In order to promote internal games in a More Games Widget, they must be set to Live in the Upsight Marketing Dashboard.
Verify that the user can actually fill out the data and submit it.
Wait two hours, then verify the data submitted can be downloaded from the Upsight Marketing Dashboard.
For instructions on setting up an Opt-In Data Collection content unit in the Upsight Marketing Dashboard, see the Opt-In Data Collection section.
For instructions on downloading the data, see the How do I access collected data? section. Remember that it can take a couple hours between when the data is gathered from the device and when it is available for download. Note also that the Opt-In Data Collection must be Published rather than merely Saved (i.e. visible only to test devices) for the inputted data to be available for download.
Verify that the specified reward is actually given when the reward is accepted by the player.
Verify that the reward cannot be triggered more times than you want.
For instructions on setting up a Reward in the Upsight Marketing Dashboard, see the Rewards section.
To set up the Reward in your app's code, please see the appropriate Getting Started Guide for the SDK or Plugin you are using.
Basically, when the player accepts a reward, a Reward event is triggered which calls a certain function/method. This method is passed a string (the name of the reward) and the quantity of the reward. In this function/method, you are responsible for implementing the code that actually gives the item to the player. We also recommend sending a message to the console log with the name and quantity of the reward to assist in debugging and verification.
To control the number of times a Player can see (and thus collect) a reward, you may want to use frequency capping. To enable, go to your reward content unit in the Upsight Marketing Dashboard
Verify that tapping on the VGP content unit actually initiates the purchase sequence for the appropriate In-App Purchase item.
Verify that if the player purchases the item, an In-App Purchase tracking call is sent to Upsight (see In-App Purchase Tracking).
For instructions on setting up a Virtual Goods Promotion in the Upsight Marketing Dashboard, see the Virtual Goods Promotion section.
To set up the VGP in your app's code, please see the Virtual Goods Promotion section of the appropriate Getting Started Guide for the SDK or Plugin you are using.
To test VGP Content Units, see the Test VGP Content Units articles.
To check whether an IAP tracking call is being made after the player purchases a VGP, see the section on In-App Purchase (IAP) Tracking in this document.
Verify that whenever the player makes an In-App Purchase, an IAP tracking call is made to Upsight.
Note This call should be made whether or not the purchase was triggered by a Upsight content unit.
price parameter in the IAP tracking call matches the price of the IAP item.
iOS Verify that receipt data is included in the IAP tracking call.
IAP tracking is vital to being able to target your users based on amount spent.
Failing to make an IAP tracking call for every single user purchase is a common Upsight integration error. Failure to do this will mean that Upsight’s targeting by user spend will be inaccurate.
To check if you have IAP tracking calls implemented correctly, make an In-app purchase in your app (either the app store or via VGP). Make a note of the time when you make the purchase. Open your console log viewer, and look for a URL that begins with:
http://api2.playhaven.com/v3/publisher/iap/. Check the timestamp for this log and verify it matches when you made your purchase. In the URL look for the
resolution parameter and verify it is set to
resolution=buy. Also check your logs and verify that there are no additional IAP calls for this purchase with a
buy (you may see
resolution=cancel if you had canceled the purchase before successfully buying it). You only want to have a single IAP tracking call each time a purchase is made. Extra IAP tracking calls will inflate your numbers.
iOS To verify that receipt data is included in your IAP tracking call, check for a
receipt=parameter in your IAP tracking call. It’s a very long parameter that will look like a stream of random characters. Failure to include receipt data with your IAP Tracking Call will mean that fraudulent transactions will be included in your Upsight revenue data, which will distort your metrics and cause targeting by user spend to be inaccurate.
Verify you have uploaded the correct APNS (iOS) or GCM (Android) certificate to the Push Dashboard.
iOS Verify that the certificate type (Development or Production) matches the type of build you are attempting to push to.
Verify your app is registering for push each time it launches (it is not necessary to register for push on resume from background).
Verify that a push sent from the Push Dashboard to your device actually appears on the device when the app is completely closed (i.e. completely killed and not running in the background at all).
Verify that a push sent from the Push Dashboard to your device actually appears on the device when the app is running in the background.
Verify that a push sent from the Push Dashboard to your device actually gets to the device when the app is running in the foreground.
Note On iOS, the operating system does not show a pop-up in this situation.
Verify that when the app receives a push notification, it sends a Push Open Call to Upsight.
Verify that you can use the “Push to Content Unit” option in the Push Dashboard.
Verify Push to Content Unit works when the app is not running at all.
Verify Push to Content Unit works when the app is running in the background.
Verify Push to Content Unit works when the app is running in the foreground.
Verify that you can use the “Push to URI” option in the Push Dashboard. When the user opens the push notification, the app should launch and the specified URI should immediately be launched.
To set up Push notifications, please see the appropriate section of the Push Guide.
To verify your app is registering for push each time it launches, check your console log for a call to:
http://api2.playhaven.com/v3/publisher/push/ upon launch. This call should NOT contain a
message_id=parameter. If it does, it is a Push Open call, not a Push Registration call. If the application is not sending a Push Registration call, push messages to that app will probably fail.
iOS Once the app has registered for push notifications, it is a good idea to look in Settings -> Notification Center and scroll down to find your app. If you cannot find your app in this list, it means that it did not register for push notifications successfully.
iOS The operating system does not automatically show a pop-up when a push notification is sent to an application that is running in the foreground. So it may appear that the push notification did not arrive, when in fact it did. We recommend placing a message in the console log in this situation, so that it is easier to verify that the push actually arrived.
To verify that your application is sending. a Push Open call to Upsight when receiving a push, check your console log for a call to:
http://api2playhaven.com/v3/publisher/push/ upon receipt of the push. This call should contain a
message_id=parameter. If it does not, it is a Push Registration call, not a Push Open Call. If Push Open calls are not being sent, the push metrics in the Upsight Push Dashboard will not be accurate. Also, failure to send Push Opens probably means that the Upsight push handler in the app is not seeing the push notifications, and that functionality like Push to Content Unit and Push to URI will fail.
When you use the Push to Content Unit feature, upon opening the push notification the app should launch and the selected content unit should immediately be shown. When testing this, be sure to select a content unit that will be shown on the device you are using to test; don’t use a content unit that has segmentation, frequency caps, or other restrictions that might make it not appear. Often it is useful to create an announcement content unit specifically for this purpose (and attach it to a placement that is never actually called in the app).
Push to URI feature: When the user opens the push notification, the app should launch and the specified URI should immediately be launched. To test this, you can use URIs like
fb://profile (which launches the Facebook app, if installed, opening to the profile page).
When testing push notifications, it is important to test all three of the following conditions:
The app is completely closed.
The app is running in the background.
The app is running in the foreground.
The reason for doing this, is that the code path in your app for handling each of these situations is different, and the way the operating system handles the situation is different. So it is very possible to have push notifications working in one of those situations and not working in another.
myapp://open-the-store) into the Safari browser. On Android, it is more complicated and you will have to refer to Intents and Intent Filters in the Android documentation.
opt_out=1parameter when the user should not be tracked.
This only applies to the following versions and above of the our SDK or Plugin:
iOS SDK: 1.21.1 +
Android: 2.1.1 +
Unity Plugin: 2.0.0 +
To set up the COPPA compliance opt-out, please see the COPPA section of the appropriate Getting Started Guide for the SDK or Plugin you are using.
If you have implemented the “Opt Out” flag for COPPA compliance, verify that the Open call contains the
opt_out=1 parameter when the user should not be tracked.
Note Setting this Opt Out flag has dramatic effects on the sorts of content that can be shown to the user. No ads will be shown to users who have this Opt Out flag set.