Site News

Site News

Email Notifications
For Feedback & Customer Support Widget Activity

Oct. 27, 2015

A new feature has been enabled for the Dashboard. Now accounts can get email notifications whenever there is in-bound Feedback or Customer Support widget activity for one of your Apps.

Emails include what the App user typed, along with most of the details visible from the Dashboard Feedback tab. You still have to use the Dashboard to respond, but this is a great way to monitor activity and keep an eye on multiple Apps.

For accounts with lots of Apps or which get lots of Feedback, there is also an option to get a daily digest, rather than individual emails. The daily digest is sent once a day and batches all activity for all Apps into a single email.

Don’t show it too soon after a user installs or upgrades. Soon is relative to your App and we suggest reviewing the App Retention analytics for a setting that selects the top 40-45% of users.

Show it to users that use Apps frequently. Frequently is a relative term depending on your App and we suggest reviewing Average Sessions Per Device analytics for an appropriate setting.

Consider asking users that responded YES, to rate again after 60 days.

Consider asking users that respond NO again. 15 days is reasonable given that NO often means I’m busy right now.

NO response data is just as important as your YES response data. A large number of NOs relative to YES might indicate that you’re prompting at the wrong time. Try changing the Tag, if you use them, or adding them if you are not.

Rating Booster Settings

Once Rating Booster is turned on, Settings, Tags and Rules determine which end-users are prompted to rate an App. Some general guidelines:

You can turn Rating Booster ON or OFF and adjust settings at any time.

Changes take effect immediately.

Rating Booster Uses Store Kit

This setting works for iOS Apps only, Android does not offer an equivalent concept.

Requires iOS SDK v4.1 or later and Apps must include Store Kit framework. When set:

ON – Store kit view is opened within your App and users do not leave the App to Rate it.

OFF(or Store Kit is not found) – Users are taken out of your App to its Reviews tab in the App Store App.

Note: There is one drawback to turning this ON. Store Kit does not provide a means for users to be taken directly to the Reviews tab of the App’s store page be. Users are taken to the App’s store page but will have to find the Reviews tab on their own.

Request Feedback

Requires: iOS SDK v4.1 / Android SDK v2.0 or later. Rating Booster can first show a prompt asking users if they like the App. If they reply Yes, the normal Rating Booster Rating prompt will immediately show. If they reply No they are offered an opportunity to provide feedback. Feedback is displayed on the App’s dashboard in the feedback section.

The style of widget used to collect Feedback is controlled by Feedback Uses Customer Support Widget setting. It work as follows:

OFF – Collects feedback via a simple widget having only a text entry field for comments.

ON – Collects feedback via the Customer Support widget which supports two way live conversations with end users. For details about using Customer Support widget, see the SDK Documentation.

Requesting feedback eliminates negative reviews by channeling them into useful feedback. The only disadvantage is that it sometimes intercept good reviews. Regardless, we recommend you leave it turned ON at all times. It can often quickly improve an App’s Rating average by 20% or more (1 star)!

Prompt More Than Once Conditions

Rating Booster NEVER asks a device to rate any particular version of an App more than once. However, it has settings that let you decide if the same device is asked to prompt subsequent versions of an App.

Rating Booster has three buttons: Yes, No, and Remind Me Later, each of which can be independently configured.

YES Condition: Sets the minimum amount of time to wait before prompting a user who previously responded with YES, to rate it again. The value is a number of days, e.g., 60. This condition overrides all others and only after the specified number of days has passed AND the App Version has incremented, will any other condition be evaluated.If you don’t want devices whose previous response was YES to ever be asked to Rate again, select the checkbox next to “Never show it again”.

NO Condition: Sets the minimum amount of time to wait before prompting a user who previously responded with NO, to rate it again. The value is a number of days, e.g., 30. This condition overrides all other Rules and Conditions and only after the specified number of days has passed will any other condition be evaluated. Note: The App version does NOT have to increment for this rule to take effect.If you don’t want devices whose previous response was NO to ever be asked to Rate again, select the checkbox next to “Never show it again”.

Remind Me Later Condition: If a user responds with ‘Remind Me Later’, they are prompted again after the number of days set here (unless they get an App update in the intervening period).

Customize Rating Booster Prompts

It is very easy to customize Rating Booster prompts for some or all supported languages. Use the edit button to open the prompt Edit dialog and add: title, prompts and button text for any of the more than 30 supported language (all languages supported by iOS).

You also have the option to use our default prompts for the ones NOT customized or to NEVER use our default prompts and specify which of your custom prompts to use as the default.

Rating Booster Tags

Starting with SDK 2.0 Tags are used to control where Rating Booster pops up in App workflow.

To learn more about how to:

Use Tags to Control widgets from the Dashboard, see: Dashboard Documentation –Rules & Tags Explained

Tag locations in App code, see: SDK Documentation – Tags

Rating Booster Rules & Conditions

Rules are groups of conditions that must be met for an end user to be prompted to rate an App.

A few points to keep in mind:

You must define at least one Rule for Rating Booster to work.

The order of precedence is as follows:

If a user has not previously rated then all the Conditions in at least one Rule must be met.

If a user has previously rated and is allowed to be asked again, then:

The number of days set for waiting after a previous response must have passed.

The App’s version must have increased for users whose previous response was YES.

All the conditions in at least one Rule must be met.

There can be more than one rule and each rule is considered independently from the others.

Feedback

View & Respond to Feedback

All feedback submitted by App users via either the Feedback widget during the Rating prompt sequence, or via Customer Support widget is displayed on the App’s dashboard Feedback tab.

Conversation threads with the most recent unread end-user comments are displayed at the top. And show the following information:

Date of last activity.

The device type it came from.

The platform OS, e.g. iOS.

The version of your App running on the device feedback came from.

The version of the AskingPoint SDK your App is using.

Any meta data you provided via the SDK User Data convenience methods.

Viewing Full Conversation Thread & Responding

To see the complete conversation thread, including all your responses, click the Respond button on the right side of each feedback thread.

The Feedback Response dialog will appear enabling you to scroll through the entire conversation thread and also to respond.

Feedback sent by any device can be replied to, regardless of if it was sent during the Rating Booster prompt sequence or because you’re using Customer Support widget.

NOTE: To ensure that all users see your responses, you are required to do some additional work and implement support for Push Notifications and/or listen for the Notifications in the App. See the SDK Topic titled: Getting Dashboard Responses To Feedback for details on how this works for your platform.

Monitoring Feedback By Email

AskingPoint can notify you by email whenever there is in-bound Feedback coming from your Apps. Depending on the number of Apps in the account and the volume of feedback generated, you can elect to get an individual email for each Feedback event, or a daily digest. Daily digests are sent once a day and include all feedback for that day, for all Apps in the account.

This is a handy way to stay on top of what’s happening with lots of Apps without having to monitor the Dashboard. It is also a very handy way to keep your Development and Support teams apprised of what is going on.

NOTE: Feedback notifications by email, requires a paid Plan.

Enable Feedback Notifications

To turn these on for your account:

Click Account in the main menu.

Select the user account or organization you want to enable notifications for in the sidebar.

Click Edit to change account settings.

Enter an email address where notifications should be sent in the Feedback & Customer Support Widget Notifications section.

Choose the notification frequency.

Click Done.

Turn Off Feedback Notifications

Click Account in the main menu.

Select the user account or organization you want to disable notifications for in the sidebar.

Click Edit to change account settings.

Remove the email address from the Feedback & Customer Support Widget Notifications section.

In-App Messaging

In-App Message Performance

In-App Messages include a number of features to help measure effectiveness, and track the number of New Installs achieved by Cross Promotion messages.

Tracking New Installs Generated By Cross Promotion Messages

For a detailed explanation of how to track installs generated by your Cross Promotion messages, see the Site Documentation Topics covering: Text and Ad Creative Messages.

Viewing Message Performance & New Install Data

Every In-App Message includes the following metrics to help measure performance and track the number of new installs generated by Cross Promotion messages:

Number of times a Message was Sent

Click Count for Each Button

Count Of New Installs

In-App Message performance data and charts are located right on each Message’s Dashboard panel.

Message Performance For All Apps

The Dashboard includes a Message Performance Dashboard where you can quickly see how ALL messages for all the Apps in your account are performing.

The Message Performance view displays key performance metrics for all your Cross Promotion messages, active or paused. Use it to mange them, see more detailed charts and monitor the clicks and new installs they are generating for you.

Ad Creative Message (SDK v3.1 or later) – Works like an Interstitial Ad and displays Interstitial images from an App’s Ad Creative Image Bundles. Supports localized images. Has a built-in close button and a Tap Action that opens the App’s store page.

Action Button – Optional. Use the Add and Del button to add / remove one. Select a pre-translated button type, or supply your own text. Use the slider to re-arrange them. We set a default URL, but you can change it.

Ad Creative Message:

Dismiss Button – Added by AskingPoint in the upper right corner.

Tap Action URL – Required. We set a default URL, but you can change it.

URL For Action Buttons and Tap Actions

AskingPoint assumes that In-App Messages showing Ad Creative or having Action Buttons are for Cross-promotion. Both types require a URL for the action:

The default URL for Action Buttons or Tap Actions uses the Platform App Id for the App owning the message. (Platform App Id is set on the App Settings Panel).

AskingPoint can easily construct default URLs for iOS Apps and Android Apps in the Google or Amazon App store using the Platform App Id. For other stores set an explicit URL.

Overriding App Id for Download Tracking

The default App Id used for download tracking is the Platform App ID of the App on whose Settings Panel the message is created. If you prefer to collect messages in one place and or use a different App Id, you can override the default by changing the value in the App ID for Download Tracking field. If this field is changed to something else, you are responsible for providing the matching Tap or Action Button URL.

NOTE: On iOS download tracking requires that both the promoted and promoting App use the same type of Device Id. Either Vendor ID, or Advertising ID.

Text In-App Messages

In-App Messages that display Text are useful for promoting your other Apps or service and for communicating with your App users. They are localized via the Text Edit dialog when the selected Message Type is Text. It looks something like the image below.

Editing Message And Button Text

Enter Title, Message Body and Action Button Text(if not using one of the pre-translated Action Buttons) for each language your are localizing for. The correct language will be shown to recipients based on their device language settings.

Devices using languages for which a translations is not provided see the Default Language version of the messages. An App’s Default Language setting is on the App’s Settings Tab, but this can be overridden this for any message using the Make Default button.

Titles are optional, but if added for one language, they must be add to all.

Message Text is required.

Action Button Text is required when pre-translated action buttons are not used.

To add more languages, select it in the language dropdown at the top of the dialog.

When finished select the Next button to enter targeting Rules and Conditions now, or Done to do it later.

Image In-App Messages

The primary use for Image In-App Messages is Advertising, Promotion and Cross Promotion. They act like Interstitial Ads and can open any URL you specify, including an App’s Store page, when tapped. See also the Dashboard documentation for Ad Creative.

If you are promoting an App and it also uses the AskingPoint SDK we can provide Download Tracking.

Selecting Ad Creative Images

When Ad Creative Message Type is selected, the Edit Dialog displays a list of Image Bundles currently on the Apps Ad Creative tab. Select one containing the images you want to use.

How Messages use bundle images:

The Interstitial image that best fits the device displaying it is automatically selected from the images in the bundle. For example, if an iPad size is unavailable, iPhones sizes are used; conversely when only iPad sizes exist they are scaled down to fit the iPhone.

If a bundle contains localized images (images with text in other languages), the correct ones are used on devices using that language. Images from the default language group are used when a localized version is not available.

We strongly recommend testing Messages on various device type to ensure the images are legible and represent you well. For best results upload portrait and landscape orientations in both iPhone and iPad sizes.

URL For Tap Actions

In-App Messages showing Ad Creative require a URL for the Tap Action:

A default URL is generated from the Platform App Id of the App owning the message. (Platform App Id is set on the App Settings Panel).

AskingPoint can easily construct default URLs for iOS Apps and Android Apps in the Google or Amazon App store using the Platform App Id. For other stores set an explicit URL.

Overriding App Id for Download Tracking

If you prefer to collect messages in one place and or use a different App Id, you can override the default by changing the value in the App ID for Download Tracking field. When this field is changed to something else, you’re responsible for providing the matching Tap or Action Button URL.

NOTE: On iOS download tracking requires that both the promoted and promoting App use the same type of Device Id. Either Vendor ID, or Advertising ID.

Ad Creative

The Ad Creative tab can be found on every Apps Settings panel. Use it to upload groups of related images that can be used for a variety of purposes, including:

Cross Promotion via In-App Messages

More uses coming soon…

The Ad Creative tab holds collections of Ad Creative called Image Bundles. Each image bundle typically contains various sizes and orientations of the same Ad. Eg portrait and landscape versions of the Banner and Interstitial version of the same Ad.

Localization

Image bundles can contain localized versions of images. For example a bundle can contain one version of an Interstitial Ad having English text on it, and another in French. When that image bundle is used in a Cross Promote Message the French version will display on devices using the French language.

Using Ad Creative

AskingPoint is adding new features that can use Ad Creative all the time. When one of our services can use them, it will offer the option to select one of the App’s Image Bundles, for example: In-App Messages. All you’ll have to do is select the Bundle’s name and AskingPoint does the rest.

AskingPoint selects the image most appropriate for the use. For example, when using them for Cross Promotion one of the appropriately sized Interstitial sizes will be selected.

Cross Promotion

AskingPoint In-App Messages are designed for Cross Promotion and this section focuses on how to use them for that.

Sending Messages To Groups Of Apps

To send Cross Promote Messages that display Text or Ad Creative Ads, do the following:

On the Message Edit dialog, select Display to a GROUP of Apps radio button.

Choose the selection criteria used to filter how Apps in the account are selected:

Inclusive – Show only to selected Apps.

Exclusive – Show to all Apps except those selected.

Check Apps according to the selection criteria in the list of Apps in your account. All Apps in your Account are listed there.

Using Tags

Tags work the same for messages going to groups of Apps, as for messages going to individual Apps. Include the Tags you want to target from each of the Apps you are showing the Message in. When no Tag is included for an App in the target list, the message displays when App launch. See the Dashboard documentation: Rules & Tags Explained to learn more about using Tags.

Using Rules

Every message requires at least one Rule to be shown. Rules used on Cross Promote messages should be broad enough to include all the Apps in the target list. Avoid conditions specific to one App in the group, else you will lose downloads. For example, avoid Rules using App Version.

Show Cross Promote Ads Several Times

We recommend using Repeat Conditions to show Cross Promote messages at least 3 times separated by an interval of 1 or 2 days. Repeat Condition increases the chances that recipients eventually visit the promoted Apps store page. This is standard advertising practice and assumes that the NO means: “Not now” or “I’m busy, or ask later”.

Download Tracking

Cross Promote messages have a URL associated with them that opens the promoted Apps store page. When the promoted App also includes the AskingPoint SDK, we can provide download tracking.

Note: for download tracking to work, Apps being cross promoted must use the AskingPoint SDK (and on iOS AdSupport.framework).

App Store URL – the default points directly at the App’s Store page. It is based on the Platform App Id set on the Apps General Settings Tab. Verify that it is correct. You can replace the URL with another if needed.

Note: For iOS and Android Apps we can detect if an App was downloaded from Apple, Google or Amazon App store. For other stores we use best efforts. If a URL is NOT provided we will construct one from the Platform App Id.

Viewing Survey Results

Survey results can be viewed on the Dashboard Survey tab where all your Published and Un-published surveys are listed along with their respective responses. Results are available in real-time (refresh the page to see the newest responses).

Understanding The Display

When a Survey is selected in the sidebar, aggregated responses from allpublications are shown.

When an individual Publication is selected in the sidebar, only responses for that publication are shown.

Sidebar Response counts, count respondents. Users who use the No, Thanks button are not counted.

Response and Skip counts for individual questions are shown under each question.

Exporting Results

Select a Survey or one of its Publications in the sidebar to export either aggregated or specific publication results respectively. Once selected, click Export on the Settings menu to export the data. Data is exported in .csv format.

Push Messaging

About Push Messages

AskingPoint Push Messaging enables you to reach ALL your opted-in App users when you need to, regardless if they are using your App or not. They are great for service announcements, notice of important updates and re-engaging users. This capability is invaluable and beneficial, but should be used with care to avoid annoying users.

Push vs. In-App Messages

The following table outlines the primary differences between In-App messages, and Push messages. It will be helpful in deciding when to use which type of message.

1. Create A Certificate Signing Request

Login to the iOS Developer Portal, and go to the Certificates, Identifiers & Profiles section.

Select Identifiers in the iOS Apps section.

Select the App ID for the App you want to add Push Messaging to. (Note: If an App ID does not already exist, then it is a more involved process and you should first read the Apple documentation for creating App IDs.)

Select the Edit button at the bottom of the panel which appears when you select one of your App IDs in the list.

From the Edit panel you can enable Development and Production Push for the selected App ID, and download certificates.

Check the box to enable Push.

Use the Create Certificate button to upload the CSR you earlier created to get Certificate(s) for Development or Production.

After the portal generates the Certificate, use the Download button to save it to your desktop.

Open the the Keychain Access App and find the Push Certificates for the App you are working with. The certificates look something like the ones shown in the image below. Note the following:

Push Certificates have Production or Development in the name depending on if they are for APNS or APNS_SANDBOX.

Push Certificates have the App Id of the App they are for in the name. Choose the right one for the App your are working with. Push Certificates are App specific and cannot be shared by other Apps.

Properly installed Push Certificates have a little expansion arrow to the left of them. That means they have a Private Key associated with them. This is important, because without a private key they will not properly export to a Certificate.p12 type file.

To export the certificate and upload it to AskingPoint:

Right click on the Push Certificate you want to upload.

Choose Export.

If the certificate has a Private Key properly associated with it, it defaults to exporting as a Certificate.p12 file. That is what is needed to upload to AskingPoint.

Provide a password to lock the file and note it down, the password is required during upload.

Go the the Settings Panel on the AskingPoint Dashboard for the App you are working with:

Select the Push Messages tab.

Click the Add / Update Certificates button.

Select the Certificate Type you are uploading. This MUST match the type of certificate obtained from the iOS Provisioning Portal..

Browse to the Certificate.p12 file.

Enter the password used to lock the file during exported.

We do our best to catch the various things that can go wrong and provide intelligible error messages at upload time. For example:

Not an actual Production or Development Push Messaging Certificate. You exported the wrong thing.

Password provided is not the password used to lock the certificate during export.

If the process was successful you should now see the Certificate on the Push Message panel, in the Certificates section.

Note: certificates are never deleted from the system. They are simply replaced by subsequent uploads. It is important that it work that way so as to NOT dissociate devices which have already agreed to receive Push Notifications from your App.

AskingPoint does not store certificates or passwords on our systems. They are stored in the Amazon SNS system and associated with the AskingPoint system account.

4. Provisioning Profiles

If you’re not familiar with Provisioning Profiles for Push Notifications, or have gotten rusty we include a brief refresher here.

Provisioning Profiles authenticate devices and are required to include authorization for each device used to test Push Notifications. There are two things that can be wrong with existing Provisioning Profiles and which can be confusing during testing. These are:

Provisioning Profiles must be regenerated and updated after an App Id is enabled for Push Notifications.

Provisioning Profiles must list each device being used to test Push Notifications.

If either of these things is not true, you get build exceptions, or during App Startup the App running on an unregistered device cannot Register for Remote Notifications. The build exceptions are more obvious, the failure to register for remote notifications is less so, but can be seen on the console when running connected to Xcode or the Xcode Organizer(see Dashboard Documentation: Push Trouble Shooting for more details).

It is relatively easy to update Provisioning Profiles for Push and to include new devices. To do so, or to check if a device is already Provisioned do the following:

Login to the iOS Developer Portal.

Go to the Certificates, Identifiers & Profiles section.

Select Provisioning Profiles.

Find the Provisioning Profile you’re using and select it.

Once selected it will open out to look something like shown in the picture below.

There are several things to notice and be on the look out for:

The Profile is listed as either Development or Distribution (when working with Ad Hoc/Production builds).

The App Id section should mention the App your working with.

The Enabled services should include Push Notifications.

The Profile’s Status should be Active (green).

Depending on the state of any of these various things you may have to take one of the following actions:

If you’re not using the correct Profile with Xcode in your Build Settings change it to use the correct one.

If Push Notifications is not included in the list of Enabled Services, you have to add it to your App Id. We outlined the steps for doing that in #2 of this section. After doing that you have to re-generate the Provisioning Profile, and use Xcode to download the updated Profile.

To see if a device is included in the list of devices supported by the selected Profile, click the Edit button on the profile and check for your device in the list. If it is not there or checked you must add and/or check the device. After doing that, you have to regenerate the Profile and download the updated Profile via Xcode.

Hope that helps you find your way through the weeds that is iOS Push Provisioning :)

Push Getting Started – Android

To enable Android Apps to use AskingPoint Push messaging, add the appropriate Keys, IDs and Secrets for your App, to the AskingPoint Push Settings tab on the Dashboard(requires Android SDK v2.0.2 or later).

Google Cloud Messaging (CGM)

Apps in the Google App store using GCM for Android should provide a Google API Key. These can be obtained from your Google Developer console. If you are not familiar with GCM, see the Google Cloud Messaging documentation for details on creating your API Key.

Amazon Device Messaging (ADM)

For Apps in the Amazon App store, provide the App’s Amazon Client ID and Client Secret. If you are not familiar with these see the Amazon Documentation for Obtaining Amazon Device Messaging Credentials. You may upload multiple ADM Keys if you use different test and production keys.

Apps In Both Stores

If Apps are in both Google Play and Amazon App Stores, provide both sets of credentials. AskingPoint detects which store a device obtained an App from and will use the appropriate service to deliver your Push messages.

Creating Push Messages

Push Messages are easy to use and can be sent from the Dashboard to any App built using the AskingPoint SDK (iOS v2.3 / Android v2.0 or later). Simply provide a localized message for the languages you’re supporting and indicate which custom sound to use (optional) and fire!

To send a Push Message follow these steps:

Select an App in the list of Apps in the Dashboard sidebar.

Click Settings in the App Menu Bar.

Select the Pushtab.

Click the Create New Push Message button and follow the steps outlined on the dialogs.

The first dialog prompts for a name (only used on the Dashboard) and the Delivery options.

Custom Alert Sounds

If your platform (iOS or Android) supports playing custom sounds when Push Messages arrive, use this field to provide the name of the sound file that should be used. See your platforms Push documentation for up-to-date information about which types of sound files it supports.

Delivery Options

There are three types of Delivery that options that can be specified:

Immediate – Messages are sent when the Send button is hit and confirmed.

Scheduled, Specified Time – Messages are scheduled for sending at the specified date and time when the Send button is hit and confirmed.

Scheduled, Specified Time On Device – Messages are scheduled to be sent at the specified date and time in their own time. Example: If 8:00 AM is specified, devices on Eastern Time get it at 8:00 AM in their time, and then another group gets it one hour later when it is 8:00 AM in Central Time, and so on.

AskingPoint sends messages at the indicated time and will use best efforts to deliver messages when scheduled, however please note that due to message load and system latency message arrival may occur at a time after the specified time. Please plan accordingly.

Message Display

Some Push messages are not relevant to users that are actually in the App and using it at the time a message arrives. When this is the case for a particular message, uncheck this box and only users who are not using the App when it arrives will see it.

Adding Message And Button Text

The next dialog prompts for the message Text and optional custom view button text:

Message text is required.

Custom View Button text is optional:

The View button appears only when messages are displayed using Alert Style.

When users select the View button the App is opened.

If not specified, iOS labels it with the localized equivalent of: View

You can specify for some languages and not others and when not specified will fall back to the iOS default.

To Add message text for more languages, select it from the language dropdown at the top of the dialog.

At this point you Rules can be added later by clicking the Done, or click Next to add them now.

Please Note: regardless of delivery options, NO MESSAGE IS SENT OR SCHEDULED for sending until you hit the Send button and confirm sending.

Scheduled and Sending State

When messages are in the Scheduled or Sending state they cannot be edited. If you need to edit them, use the Cancel button. Depending on the Message state one of the following things happens:

If the delivery date is in the future and nothing was sent, the message reverts to the Editing state where anything as per the above can be changed.

If the message was in process of being sent, AskingPoint will clear the queue of unsent messages and cease sending of any more of that message. The message then transitions to the Sent state and nothing further can be done to it.

For an explanation of how to use Rules & Conditions to control AskingPoint features see: Dashboard Documentation: Rules & Tags Explained.

Debugging Push Messages

iOS Push Certificates and Provisioning Profiles are the most frequent cause of issues. Please check the following before contacting us.

App Store Review Issues

1. You got an email notice about Push Notifications like the one shown below when an App was submitted for review.

In case you’re worried, the App is NOT rejected. You can verify this by checking the status of the App in iTunes connect. Unless the status is Binary Rejected, your App is still in review and all is ok!

App Not Provisioned For Push Warning Notice

Dear developer,
We have discovered one or more issues with your recent delivery for <Your App Name Here>.
Your delivery was successful, but you may wish to correct the following issues in your next delivery:

Missing Push Notification Entitlement – Your app appears to include API used to register with the Apple Push Notification service, but the app signature’s entitlements do not include the “aps-environment” entitlement. If your app uses the Apple Push Notification service, make sure your App ID is enabled for Push Notification in the Provisioning Portal…

Why this happens: Apple scans Apps for various API calls as an initial sanity check and if it sees calls to Push Notification services but the App is NOT entitled/provisioned for Push, it emails a warning notice like that shown below, in case this was an oversight.

If you DO NOT use Push Notifications, you can simply ignore this. Nothing bad will happen.

If you DID intend to use Push, your App is not entitled/provisioned for Push Notifications and you should review Apple’s Docs and/or the AskingPoint docs for Push Notification setup.

Coding Issues

1. Are you using AskingPoint SDK v2.3 or later?

If you did not build an App using SDK v2.3 or later, or the App on the device is not running an App using SDK v2.3, it cannot receive Push Notifications sent from the AskingPoint Dashboard.

2. Did the App register for Push Notifications in the Application Delegate?

If the App fails to call [[UIApplication sharedApplication] registerForRemoteNotificationTypes:] then there will be absolutely NO indication on the console that the App has registered or failed to register for Push. In other words, you will not see anything like what is shown (underlined in red) on the console printout in the answer to question 2!

Certificate & Provisioning Issues

1. Was the correct APN Certificate uploaded?

When Push Certificates are uploaded, the dialog requires you to indicate if it is a Development or Production certificate. We also try and detect that on our own by examining the Certificates OIDs. The Certificate Upload dialog throws an exception and refuses to accept certificates when what you said it is (development or production), does not match what we think it is. We do this to help ensure the right one is uploaded, BUT we cannot tell so easily which App the certificate is for. So please check that you uploaded a certificate for the right App.

2. Is the test device included in the Provisioning Profile used to sign the App?

Make sure the device your testing with is included in the Provisioning Profile being used. If not, add it via the Provisioning Portal and update the Provisioning Profiles on your local machine via Xcode. To do that Open Xcode and select from the menu bar: Xcode > Preferences > Accounts > View Details > refresh button.

One way to detect if an App and Device is properly provisioned is to connect the device to Xcode and start the App your working with. At the beginning of the startup sequence you should see the following printed to the console:

If something is wrong with Provisioning or the device is not included in the Provisioning Profile, there is usually an exception indicating the nature of the problem.

Testing Issues

1. You get the following error when sending a Push Message to a registered Test Device: “This device is NOT Provisioned for Push with this App.”

This happens when the registered test device has NEVER been seen by AskingPoint registering for Push in that App. There are lots of ways this can happen. Here are some:

You didn’t Provision that device for Push. Check Provisioning Portal.

You’re not testing the device you think you are. Check that the Device ID logged to the console matches the one shown on the Test dialog.

You initially registered the Test Device using a UUID and we subsequently changed it over to Advertising ID at some point after SDK v2.1 rolled out. Check that Test Device ID on console matches the one shown on the Test Dialog.

You stopped or started including Ad Support Framework and the device now uses a different ID from when you registered it as a Test Device.

Not one of these? Check around this section for other possible solutions.

2. Custom Alert Sound not played when push message arrives.

This can happen for several reasons:

The UIUserNotificationTypeSound flag is not included when the App registers for Push.

The sound file named in the Push message is incorrect or not in the App bundle or in the wrong place.

The sound file is not one of the supported sound file types. See your platform Push documentation.

Other Possible Problems… These usually happen late at night

Ok… so you’re all the way down here in the late night stupid section. Don’t feel too bad. We added these because we did ALL of this ourselves while building this amazing tool for you….. mwahahhaha!

1. Not getting that Push Message you sent?

R u sure you sent it? See that Push Message on the App’s Push Dashboard… if it’s status is Editing, you thought you sent it but actually you didn’t. Go ahead and hit that Send button. K, R U good now? Awesome, go grab a beer!

2. Still, not getting that Push Message you sent?

Did you set a schedule for a time that has not arrived yet, either in the Time Zone you picked or the one on the device? Also, don’t forget scheduled things still have to be Sent to actually get scheduled by our servers.

3. Is the device currently allowing Push to be sent to the App?

Check it. Settings > Notification Center > Scroll down to the App > Tap it’s row. Verify the settings are right. If you don’t find the App in the list, then you have some other kind of issue, and you should scroll up to the top of this section and check other things.

4. Are you pushing to the App you think you are?

Ahoy mate! Are you doing any of the following:

Sending from a test App to a Production App?

Sending form a Production App to a Test App?

Sending form an entirely different App?

If so, take a break and try again.

Okay… so these are all the crash scenarios our test dummies ran into. And this section was appropriately written late at night so as to be in the proper tone and spirit. But fear not, we’re pretty sure that your test dummies are going to find stuff ours didn’t :)

Here at AskingPoint we do our best to remove all the rough edges and sharp points so that you don’t hurt yourselves too bad! That’s why AskingPoint is by Developers for Developers. Good luck, and enjoy!

Local Notifications

About Local Notifications

Local Notifications (iOS Only) are messages that can be scheduled to appear at a future date and time, regardless of if Apps are being used. For this reason they are great for re-engagement and for incentivizing App users to use Apps again.

Starting with AskingPoint iOS SDK v4.0 they can be created, edited, localized and schedule from the Dashboard, no programming or software releases required! We’ve done the work so that any time you want, you can simply go to your Dashboard and schedule one for delivery.

Note: iOS 8.0 and later requires Apps to Register to schedule Local Notifications. To learn how see the iOS SDK Documentation: Local Notifications.

How They Work

When you create a Local Notification on your App’s Dashboard, AskingPoint servers tell that App to schedule it to appear at a specified number of days and during a time in the future. Each time the App runs, the notification is re-scheduled continually pushing the date and time that the message appears further out. When users stop using the App or hitting the Tag that causes one to be re-scheduled, after the elapsed time indicated in the scheduler passes, the users will see your message.

Example Use Cases

Schedule a Notification at App launch to appear 2 days later. When the user stops using the App for 2 days, the message will appears. This is a great time to offer them an incentive to return to the App.

Schedule a Notification at a place in the App where users make a purchase. When users stop using the App or making additional purchases, the message appears. This is a great time to offer them an incentive to make another purchase.

Creating Local Notifications

Local Notifications are easy to use and send from the Dashboard. Any App built using the AskingPoint SDK (iOS v4.x or later) can use them.

To schedule Local Notifications follow these steps:

Select an App in the list of Apps in the Dashboard sidebar.

Click Settings in the App Menu Bar.

Select the Local Ntftab.

Click the Create Local Notification button and follow the steps outlined on the dialogs.

The first dialog prompts for a name (only used on the Dashboard) and the Scheduling options.

Target App

Local Notifications can be scheduled for a single or multiple Apps. Your options are to:

Schedule For This App Only – useful for Notifications that are relevant to this App only.

Schedule For A Group of Apps – useful for Notifications which are relevant to a group of Apps. When selected, a list of the Apps in your account is shown along with filtering options.

Custom Alert Sounds

If you’ve included custom sounds in your App, they can be played when Local Notifications are displayed. Enter the name of the sound file to use on the create dialog. See your platforms documentation for information about which types of sound files it supports.

Scheduling Options

Each time an App runs and Rules & Tags associated with a Notification match a device, it is scheduled. If it was previously scheduled it will be re-scheduled. These settings determine when it displays on the device:

Show After X Days – The number of days in the future from the time the notification is scheduled or re-scheduled.

Start/End Time (option) – Use this to set a time window when the Notification can be displayed.

When no range is specified, messages are scheduled to show at the time they were scheduled. This will be a time when the user is using the App and is probably a safe time to show Notifications.

All times are specified military style, e.g. 15:00 equals 3pm.

All times are converted to the devices time zone, e.g. 3pm means 3pm for a device wherever in the world it is.

If a start time is provided, an end time must also be provided.

If a time range is provided, notifications are scheduled for a random point during that range.

Localized Message

The next dialog provides an opportunity to enter your message. Add as many languages as you wish to support, AskingPoint delivers the right one for a device.

When devices use a language other than one you’ve provided, they see the Default Language version of the message. If don’t want this then use Rules to indicate which device languages to schedule the Notification for, others will not see it.

Rules

The next dialog ask you to provides Rules that specify which devices will have Notifications scheduled. For example, only schedule the Notification on devices that use English. To learn more about Rules see Dashboard Documentation: Rules & Tags Explained.

Note: At least one rule must be added for Local Notifications to work.

Tags

Tags are optional conditions that target places in App workflow. Use them when you want notifications to be scheduled only when a user does something or visits a specific place in Apps. To learn more about Tags, see Dashboard Documentation: Rules & Tags Explained.

Example: if you Tag the place in an App where a purchase occurs, that Tag can be added to the Notification so that it is only scheduled when users make that purchase.

Tags are added to Local Notifications after they has been created and saved to the Dashboard. To do so:

Payload

About Payload

Payload is a powerful tool that enables the delivery of JSON data to some or all App users based on Rules, Conditions and at Tagged locations in real-time. The data is sent in real-time from the Dashboard or your servers via our serverside API (contact Sales about using the Server Side API).

How It Works

When a Payload’s Rules, Conditions and Tags match a device, the associated JSON payload is delivered to that device. Each Payload can contain up to 32k of valid JSON data. App’s may use this data for configurations, commands, messages, data, etc. Some examples will help:

Example Use Cases

Example 1: If you wanted to experiment with different In-App purchase offerings when users make a high score. You could add a Payload to the Dashboard, set up the Tags and Rules to target users at that point, and use the JSON payload to specify which item is offered. When the Payload fires on a device it will be sent the JSON data specifying what to offer. Your Command Handler(See SDK Documentation: Advanced – Command Handlers)can use the data sent to configure your offering.

Using this approach you could A/B test the best place for a particular offering by changing Tags, or find out which offering attracts the most buyers by changing what you offer, and all without having to push out additional software updates!

Example 2: Send some configuration data to App users based on location, or device type or language.

Payload is an extremely powerful tool that can help you save money, avoid software updates and make your Apps more flexible and responsive to the situations they are used in.

Creating Payload

Payload is simple and easy to use. Any App, built to include SDK v2.2.1 or later can use it.

You provide some descriptive information to help you remember what it does along with a blob of JSON data that makes sense to your App. You can provide up to 32k of it, but we suggest you keep it simple and not too difficult to use on the device. If your not sure what JSON is, then take a look at JSON.org or the Wikipedia article on it.

To get started:

Select an App in the list of Apps in the Dashboard sidebar.

Click Payload in the App Menu Bar.

Click the Add New Payload button.

Enter a Title and Description that help you remember what it does.

Manually enter or paste JSON into the Payload Data field (The editor alerts you when it’s not valid JSON).

Set the Start/Stop Date and Repeat conditions.

You can add Rules and Tags later once it is added to your Payload Dashboard.

For an explanation of Start / Stop Date and Repeat Conditions see the Dashboard Documentation: Rules & Tags Explained.

Once you’ve finished, the Payload is added to your Dashboard in a Paused state. Payloads remain on this panel until deleted.

Rules & Tags Explained

Date Conditions Explained

This discussion applies to all AskingPoint features that can be controlled by Date Conditions.

Date settings control when an AskingPoint feature can show on a device. When a date range is set the associated feature does NOT show before the start date, or after the stop date, regardless of if other conditions match.

Start / Stop Date settings work as follows:

Start / Stop Dates are NOT Required, and can be left blank.

If NO values are provided: the associated feature appears the first time other Rule and Conditions match a running device.

If values ARE provided: the associated feature only appears after the Start Date and before the Stop Date. Stop dates are NOT required.

Date / Times use YOUR browser LOCAL Time Zone:

Dates are for midnight, in your browser’s time zone.

Times are local time, in your browser’s time zone.

Start and Stop Dates CAN be changed at any time, and changes take effect immediately. E.g., changing a Stop Date (after the date has passed) to a date in the future causes something to begin showing again on devices matching the other conditions.

Example: Setting a Message Start Date of Aug. 1, 2013 13:00 using a browser in/on a device in the New York Time Zone prevents the Message from showing anywhere in the world, on any device, until after Aug. 1, 2013 13:00 ET.

Repeat Conditions Explained

This discussion applies to all AskingPoint features that can be controlled by Repeat Conditions.

Repeat conditions make it possible to cause something to show on a device more than once and at a specified frequency, if other conditions are also met.

Repeat conditions work as follows:

To cause something to repeat select the YES radio button.

To set the repeat frequency enter a number in the repeats every input. For example, entering 3 causes something to show on a device on the first match of other rules, and then on every subsequent third match of the rules.

To limit the number of times something can repeat, enter a value in the Stops after input.

Repeat conditions CAN be changed at any time, and changes take effect immediately.

Example 1: You could use repeat conditions to show users a Message every time they match your Tag & Rule conditions. To do that set repeats every input to 1 and leave the stops after input empty.

Example 2: If you wanted Example 1 to be less annoying, set repeats every input to 3 and stops after input to 5. These settings will show the Message the 1st, 4th, 7th, etc. times the App was run, until either the fifth time it displayed or the device no longer matches other conditions.

Rules Explained

This discussion applies to all AskingPoint features that can be controlled with Rules.

Rules are groups of Conditions that must be met before the feature being controlled by them can happen. Some of the features that can be controlled by Rules are: Messages, Rating Booster and Payload.

When a feature is controlled by Rules it has a panel like the one shown below on its Dashboard Controls which is used to to Add, Delete and Edit them.

About Rules

Features that use Rules require at least one to be defined in order to work.

All conditions in a Rule must be met for it to trigger its associated feature.

When features have OTHER conditions specific to them, those also must match before a Rule can trigger the feature. For example, Rating Booster Yes, No Conditions or a Message’s Start / Stop Date Conditions.

More than one Rule can be used to control a feature.

When more than one Rule is used, each Rule is independent of the others (like a Logical OR). This makes it possible to use multiple rules to do things like exclude a specific version of an App from being prompted by Rating Booster.

Rules are made up of one or more Conditions. All the conditions in the Rule must be met for the Rule to trigger (like a Logical AND).

Rules are added using the Condition Editor shown below. AskingPoint is constantly adding new metrics and data elements that can be used as criteria in Rules.

Data That Can Be Used In Conditions

Data Type

Explanation

Days Since User Installed App

A number of days since App was first installed on a device.

Days Since User Installed or Upgraded

A number of days since App install or the last update.

Days Since User Last Used App

A number of days since the App was last used on a device.

Sessions Since User Installed or Upgraded

A number of times the App has been used since App install or the last update.

Application Version

One of the versions of your App that has AskingPoint installed.

OS Version

Version of OS running on a device.

Language

Use one of the BCP 47 language codes supported by the device you are targeting (NOT case sensitive).

Country

Use one of the ISO 3166-1 alpha-2 language codes supported by the device you are targeting (NOT case sensitive).

Device Family

iPhone, iPad, iPod Touch, iOS Simulator

Device Model

Select one of the model types the system has seen from the drop down.

App (IS / IS NOT) Installed

Useful for cross promoting YOUR Apps. Can be used to target devices that
AskingPoint sees with the specified App INSTALLED or NOT INSTALLED. For example App A might want to
show a cross promotion message for App B when it is on a device that does not have App B installed.
This conditions Value dropdown lists all your Apps currently added to your AskingPoint account.

Installed App Count

Can be used to create conditions that target users of your Apps by the number
of those Apps AskingPoint currently sees installed on a device.

Tags Explained

This discussion applies to all AskingPoint features that can be controlled with Tags.

For an explanation of how to Tag locations in Apps, see SDK Documentation: Tags.

Tags can be used to control where AskingPoint features should pop-up in App workflow. If something can be controlled by Tags, a Tag Editor looking something like the one shown below, will be on the feature’s control panel in Settings.

When Tagged items are used, the App asks AskingPoint if the device matches the other rules and conditions associated with the Tagged feature. Matching devices are instructed to display that feature.

How to set Tags:

Tags are optional. If NOT used, the feature is displayed when Apps start or come into the foreground.

To Add or Edit tags, push the Edit button on the Editor. Push it again to finish.

Tags are case sensitive and must exactly match the Tag strings set in the App via the SDK.

More than one Tag can be entered. When more than one Tag is entered, the first one hit is the one that fires.

Adding or removing Tags takes effect in real-time.

The same Tag can be added to different features, e.g. Rating Booster and a Message.

Example: If a game App is tagged with level_1_done and level_2_done, then adding those Tags to Rating Booster will cause it to prompt users matching other conditions to Rate the App when the level_1_done Tag is hit, and then again when they level_2_1 Tag is hit.

Special Considerations For Messages Sent To Groups Of Apps

Tags work the same for messages sent to groups of Apps, as for messages delivered to individual Apps. However, keep in mind that the Tags used must exist in an App for the message to be delivered. There are several strategies you can adopt to facilitate delivery of messages to groups of Apps:

Don’t use any Tags on messages sent to groups of Apps. This causes messages to display at App start or when returning to the foreground.

Use the same Tag in all Apps where you might want a Cross Promote message to appear.

Add the Tags which mark the spot you want messages to appear in each of the target Apps. You can use Tags from different Apps on the same message.

How Tags Interact With Rules And Conditions

Tags determine where things controlled by them (your or ours) pop-up in App workflow. Tags work together with Rules & in the following manner:

Rules & Conditions are evaluated first, to determine if a device matches and should be instructed to show whatever is controlled by them.

If Tags ARE NOT being used, devices matching Rules are instructed to display things controlled by them at App Startup or when it comes into the foreground.

If Tags ARE used, devices matching Rules are instructed to display things controlled by them only after the App requests one of the Tags added to the feature.

More than one Tag can be targeted by a feature. Apps matching Rules will be instructed to display the feature the first time one of its associated Tags is requested.

Viewing Custom Data

If an App is sending Custom Events with additional data in a NSDictionary object, that data can be viewed and exported from the ‘Custom Data’ section of the Dashboard.

Adding Charts To Display Custom Event Data

Select the App you want to view Custom Data for on the Dashboard sidebar.

Select the Custom Data section on the Dashboard

Click the drop down at the top of that section titled: ‘Add Chart For Custom Event’.

Select the Custom Event name from the list.

Click either Per Device or Total Counts depending on
the type of Custom Data the App is sending:

Per Device – Use this when the type of data is something like a setting that you want to know the percentage of devices choosing one option or another. It only counts that data once per device.

Total Counts – Use this when the type of data is something like an option or activity that you want a total count for. This displays counts for every occurrence regardless of if it happened on the same device or not.

Click the ‘Add’ button.

A chart displaying the data for the selected event will be added to the bottom of the Custom Data page. Charts added in this manner appear in the order added and remain on the page until deleted.

To remove a chart added in this manner, use the Red Delete button in the upper right corner of each chart. Removing a chart does not delete the actual data.

If the data is something that we could not properly interpret for a chart, then after adding the chart use the Export button. You’ll get a .csv file that you can use to get at the information you want.

If you’re having issues seeing data, please contact support via email with a clear explanation of the type of data your sending and we will try to help.

Testing

After you’ve added a Test Device(s) to your Account, use the Dashboard Test control to force features to display in Apps using the AskingPoint SDK.

Testing Features Other Than Surveys

Select the App to test in the Dashboard sidebar. Check that you’ve selected the App actually running on the Test Device.

Click Settings on the App’s Dashboard Menu.

Select the appropriate tab for the thing you want to test.

For Rating Booster the Test button is on its Settings tab.

For other things: In-App & Push Messages, Local Notifications, Payload the test button is
on each individual thing on its respective tab. To see it, open the item panel by clicking it.

Click the Test button to see the following test panel and select a device.

Note 1: When testing Tags, you can fire as many Tests as needed without restarting the App. Simply fire the test and perform the Tagged action.

Note 2: If the widget being tested does not have any Tags set on its Dashboard, then it will appear at App startup. This requires a full restart of the App after each test. Make sure it is NOT running in the background.

Testing Surveys

The procedure for testing surveys follows the same pattern as outlined above. But be aware that you can only test Published Surveys.

To test a Published Survey follow these steps:

Go to the Survey Tab on the Dashboard.

Select the Published Survey the Dashboard sidebar.

Make sure the App you’ve Published the Survey to, is running on the test device.

Search

Use the search input at the top of the App list to filter the list by name. To clear the filter backspace out your entry, or refresh the page. You can search by:

App Name

App Store App Id

Favorites

Apps marked as Favorite are moved to the top of the list (after a page refresh) and sorted alphabetically as a group.

To toggle the Favorite status of an App, click the star. Colored stars are marked as Favorites.

Favorite Usage

Favorite Usage charts show key Usage metrics for all Apps marked as favorites. This is to help App owners and developers quickly notice if any extraordinary increases or drops in App usage occurred and which might merit attention.