Dashboard Documentation

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.

Visit your Account tab to turn them on!

Top ▲

Rating Booster

Rating Booster Setup

Rating Booster is part of the AskingPoint SDK. Once you’ve added it to an App and properly initialized, all that remains to be done is to turn it ON. 

When users run your Apps and match your conditions, they’ll be prompted to rate it and taken to the iTunes Ratings page when they agree.

Turn It On And Set Conditions

  1. Select the App you want to configure in the list of Apps on the Dashboard.
  2. Click Settings in the Dashboard toolbar (upper right).
  3. The App settings panel will appear.
  4. If you’ve not already entered a Platform App ID for the App, then you must do that now to be able to use Rating Booster. Use the edit button on the App tab on the panel.
  5. If you don’t have a Platform App ID for the App yet but want to test Rating Booster, enter a temporary one.
  6. If you already provided a Platform App ID, select the Rating Booster.
  7. Use the Edit button in the top panel of the Rating Booster tab to turn Rating Booster on and configure other general behaviors.

Top ▲

Rating Booster Tips

Rating Booster can dramatically help improve the number and quality of Ratings Apps get. For best results we recommend the following:

  1. Always Request feedback (requires iOS SDK 4.0 / Android SDK v2.0). Requesting feedback can quickly improve an App’s Average star rating by 20% or more.
  2. 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.
  3. 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.
  4. Consider asking users that responded YES, to rate again after 60 days.
  5. Consider asking users that respond NO again. 15 days is reasonable given that NO often means I’m busy right now.
  6. 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.
  7. Monitor Feedback and Ratings for user complaints. Address issues quickly and respond to Feedback.


Top ▲

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:

  1. You can turn Rating Booster ON or OFF and adjust settings at any time.
  2. 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.

Rating Booster Tags

To learn more about how to:

  1. Use Tags to Control widgets from the Dashboard, see: Dashboard Documentation – Rules & Tags Explained
  2. 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.

Rating Booster Rule

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:
    1. If a user has not previously rated then all the Conditions in at least one Rule must be met.
    2. 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.

Top ▲


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.

Top ▲

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:

  1. Click Account in the main menu.
  2. Select the user account or organization you want to enable notifications for in the sidebar.
  3. Click Edit to change account settings.
  4. Enter an email address where notifications should be sent in the Feedback & Customer Support Widget Notifications section.
  5. Choose the notification frequency.
  6. Click Done.

Turn Off Feedback Notifications

  1. Click Account in the main menu.
  2. Select the user account or organization you want to disable notifications for in the sidebar.
  3. Click Edit to change account settings.
  4. Remove the email address from the Feedback & Customer Support Widget Notifications section.
  5. Click Done.

Top ▲

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.


Top ▲

Creating In-App Message

All messages for or about an App should be added to that App’s In-App Message panel. To create one:

  1. Select the App in the Dashboard sidebar.
  2. Click Messages in the App Menu Bar.
  3. Click Create New Message and follow the instructions on the dialog.


Target Audience

The first thing to set is the Target Audience (which Apps see it). Your options are to:

  • Display In This App Only – useful for Upselling and Admin notices.
  • Display To A Group Of Apps – useful for Cross Promotion. When this option is selected, a list of all Apps in the same account is shown along with filtering options.

Message Type

Next, set the Message Type. This can be one of two display modalities:

  • Text Message – Delivered via an alert style pop-up and supports localized message and button text. Optional Action Buttons take users to URLs when tapped.
  • 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.

Buttons and Tap Actions

Button and Action configuration depends on the selected Message Type (Text or Ad Creative).

Text Messages:

  • Dismiss Button – Select a pre-translated button appropriate to the message context. AskingPoint provides correct translations for all iOS supported languages.
  • 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.

Start/Stop And Repeat Conditions

See the Dashboard documentation section titled Rules & Tags Explained for an explanation of:

  • Start/Stop Date Conditions
  • Repeat Conditions

Depending on the Message Type (Text or Ad Creative) you may find it useful to review the two help topics that follow this.

When a Message is first created, it is added to the Message panel in the Paused state.

Top ▲

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 TitleMessage 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.

Top ▲

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.

Top ▲

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.


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.

Top ▲

In-App Message Controls

While Messages are on your Message Dashboard, you can do any of the following things to them regardless of if they are live or Paused, and changes take effect in real-time:

    1. Edit them.
    2. Add or remove languages.
    3. Edit Start/Stop Date and Repeat conditions.
    4. Add or remove Tags.
    5. Add Rules, or amend existing ones.
    6. Pause or Resume them.
    7. Use the Test button to force them to display on a registered Test Device. See Dashboard documentation: Test Device Setup.

To learn more about setting Tags, Rules and Start/Stop and Repeat Conditions see the Dashboard documentation: Rules & Tags Explained.

Top ▲

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:

  1. On the Message Edit dialog, select Display to a GROUP of Apps radio button.
  2. 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.
  3. 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).

  1. 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.
  2. 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.

Top ▲

About In-App Messaging

In-App Messages are great for promoting your other Apps or Services and for fast, direct communication with App users. They can be sent to one App or a group of Apps in your account.

They pop-up from within Apps while they are being used. They support sophisticated targeting Rules using Tags and Analytic metrics, and have numerous advantages over Push Notifications.

Two Types of In-App Messages

  1. Text Message:
    • Delivered as text via an alert style pop-up.
    • Support localized message and button text.
    • Can have an Action button that take users to any URL you specify.
  2. Ad Creative Message:
    • Works like an Interstitial Ad.
    • Uses Interstitial images from the App’s Ad Creative tab.
    • Supports localized Ad Creative.
    • A Tap Action that sends user to the App’s store page or any URL you specify.

Ways To Use Them

  • Promotion – Tell users about one of your other Apps or services.
  • Up Sell – Explain the benefits of a paid version.
  • Update Notices – Tell users about a new feature.
  • Alerts – When the unfortunate issue arises, tell users you’re on the job.


  • Easy to use.
  • Many uses.
  • Only you can turn them off.
  • Customizable buttons that can take users to any URL including App Store pages.
  • Integrated with Analytics for precise targeting.
  • Can use Tags to target events and activities in Apps.
  • Fully controlled from the Dashboard, no programming needed.
  • Easy to localize into any iOS supported language using the Dashboard message editor.

We think you’ll find AskingPoint In-App Messages to be an invaluable tool for communicating with your App users about all kinds of things.

Top ▲

Mobile Surveys

About Mobile Surveys

Mobile Surveys are one of the best and fastest ways we know to get all kinds of answers and information from App users, in near real-time!

They take just minutes to create and all recent versions of the AskingPoint SDK can show them, so you can start getting answers almost instantly.

Ways To Use Mobile Surveys

To help you think about them and get started, here are some of the many ways they can be used:

  1. Find out what features users want most.
  2. Find out what user like or dislike about your Apps.
  3. Find out where uses heard about your App and why or how they got it.
  4. Use them to find out more about bugs and which users are seeing them.
  5. Use them to get contact information and volunteers to help track down difficult bugs.

To get started and try them out, just click the Survey Tab at the top of the Dashboard.

Top ▲

Publishing Mobile Surveys

After Surveys are created, they have to be Published to a specific App for those App users to see them. You can publish Surveys as often, and to as many Apps, as needed.

To Publish a Survey:

  • Click the Survey tab at the top of the Dashboard.
  • Select a Survey to Publish, in the Sidebar.
  • Click Publish on the selected Surveys Settings menu.

To Edit Settings for a Published Survey:

  • Select a Survey in the sidebar to expand the list and see its Publications.
  • Select a Published Survey from the indented group of Publications.
  • Click Settings its Settings menu.

Publish Settings Explained


  1. Name – Give the Publication a name that helps identify it in the Survey list.
  2. App – Select an App from the dropdown menu to show the Survey in.
  3. Tags – Add Tags if you want Surveys to show only when users reach a specific Tagged spot in App work flow. (See the SDK and Site Documentation if you are not familiar with Tags)
  4. Start / Stop Conditions – Use Start / Stop conditions alone or in combination to determine when Surveys display to App users:
    • If Start / Stop Conditions are not defined, Surveys start showing when Rules and Tags indicate they should and never stop.
    • Start Date – Surveys don’t start showing until after the date.
    • Stop Date – Surveys stop showing after the date, regardless of the number of responses.
    • End After # Responses – Surveys stop showing after the indicated number of responses.
  5. Rules – Add Rules to target specific groups of users. Note: You must add at least ONE rule for any Survey to ever display.

Top ▲

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 all publications 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.

Top ▲

Creating Mobile Surveys

Once the AskingPoint SDK is installed in Apps, Surveys can be shown to users anytime you need answers.

Create New Survey

  • Click Survey tab at the top of the Dashboard.
  • Click New Survey.
  • Use the Survey Editor to Add and arrange questions.
  • Enter question and answer text into their respective fields.
  • Hover over questions to access settings for re-arranging, previewing or deleting questions.
  • When done click Save & Finish and you’ll be returned to the list of Surveys where the new Survey will appear.


Edit Existing Survey

  • Click Survey tab at the top of the Dashboard.
  • Click the Survey to edit in the sidebar.
  • Select Edit on its Settings Menu.
  • Use the Survey Editor to make changes.
  • When done click Save & Finish and you’ll be returned to the list of Surveys where the new Survey will appear.

Question Types

There are six Question types that can be added to Surveys. Add them by clicking their associated button in the Editor near the top of the page.

The six types are:

  1. Header – These display header type images and or text and include simple formatting options right on the panel. Use them anywhere in Surveys and as often as you like as dividers.
  2. Multiple Choice – A standard multiple choice question that can be configured to allow one or multiple responses. Type the question in the space provided and as many answers as needed below.
  3. Free Text – A question that accepts a free text response. Enter a question in the space provided.
  4. Rating Scale – A question that includes a Rating or ranking Scale. Enter the number of rating levels you want, and a question.
  5. Text Message – A panel that simply displays a block of text. Can be used for instructions or whatever Simply enter your message.
  6. Image – A panel that simply displays an image. Can be used for whatever. simply upload your image.

Editing Controls

There are Editing controls at the top of the Survey Editor and also question specific controls that appear when a question is hovered over:

  • Save & Finish – Saves new Surveys and edits and exist the editor back to the Survey list.
  • Cancel – Aborts creation of new Surveys or edits to existing Surveys.
  • Preview (at top) – Displays the entire Survey as it will appear on devices.
  • Preview (on question) – Displays that specific question as it will appear on devices.
  • Delete – Deletes a question.
  • ▲ and ▼ – Moves questions up or down.

Top ▲

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.

Push Messages In-App Pull Messages
– Reaches all opted-in users. – Reaches users only when they use an App.
– Should not be used for marketing or cross-promotion on iOS. – Can be used for marketing and cross-promotion on iOS.
– Are only sent once. – Can have programmed repeat conditions.
– Can be turned off by end-users. – Cannot be turned off by end-users.
– Should not be used for frequent communication. – Can be used for frequent communications.

Top ▲

Push Getting Started – iOS

The first thing to do is to upload Apple Push Notification Service (APNS) Security Credentials to the App’s Push Dashboard. Security Credentials are specific to each App and can be one of two types:

  1. Development (APNS_SANDBOX) – Used for test Apps.
  2. Distribution (APNS) – Used for production Apps (Apps downloaded from the App store).

The subject is fully explained in the Apple Documentation titled Local And Push Notification Guide. For those already familiar with the basic procedure, we’ve outlined the steps for your convenience.

1. Create A Certificate Signing Request

Create A Certificate Signing Request (CSR) using the Keychain App on your computer.


2. Upload The CSR To iOS Provisioning Portal And Download Push Certificates

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

  1. Select Identifiers in the iOS Apps section.
  2. 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.)
  3. 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.

  1. Check the box to enable Push.
  2. Use the Create Certificate button to upload the CSR you earlier created to get Certificate(s) for Development or Production.
  3. After the portal generates the Certificate, use the Download button to save it to your desktop.
  4. Double click the downloaded certificate to add it to your KeyChain.


3. Export Push Certificates From Your KeyChain And Upload To AskingPoint

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:

  1. Right click on the Push Certificate you want to upload.
  2. Choose Export.
  3. 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.
  4. Provide a password to lock the file and note it down, the password is required during upload.
  5. 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:

  1. Login to the iOS Developer Portal.
  2. Go to the Certificates, Identifiers & Profiles section.
  3. Select Provisioning Profiles.
  4. 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:

  1. The Profile is listed as either Development or Distribution (when working with Ad Hoc/Production builds).
  2. The App Id section should mention the App your working with.
  3. The Enabled services should include Push Notifications.
  4. 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 :)

Top ▲

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.

Top ▲

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:

  1. Select an App in the list of Apps in the Dashboard sidebar.
  2. Click Settings in the App Menu Bar.
  3. Select the Push tab.
  4. 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:

  1. Immediate – Messages are sent when the Send button is hit and confirmed.
  2. Scheduled, Specified Time – Messages are scheduled for sending at the specified date and time when the Send button is hit and confirmed.
  3. 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:

  1. Message text is required.
  2. 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.
  3. To Add message text for more languages, select it from the language dropdown at the top of the dialog.
  4. At this point you Rules can be added later by clicking the Done, or click Next to add them now.
  5. For an explanation of Rules & Conditions see: Dashboard Documentation: Rules & Tags Explained.


Once Push Message creation is finished, the message is added to the App’s Push Message panel.

Please Note: regardless of delivery options, NO Push Messages are Sent Or Scheduled for sending until you hit the Send button and confirm.

Top ▲

Push Message Controls

When Push Messages are on the Dashboard and in and Editing Message State the operations listed below can be carried out on them.


Editing State

When messages are in the Editing state, any of the following things can be done to them:

  1. Edit the delivery schedule.
  2. Edit message or View button text.
  3. Add or remove languages.
  4. Add new Rules, or amend existing ones.
  5. Send or Schedule messages for delivery by hitting and confirming the Send button.
  6. Test them on registered Test Device (See Dashboard Documentation: Test Device Setup):
    • Schedules cannot be tested.
    • Messages are ONLY sent to test devices.
    • Testing does NOT schedule a message for sending.

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.

Top ▲

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’re device ID changed. Here are some of the ways that can happen:
    • You wipe the device and do not restore from backup.
    • You went into device Settings > Privacy > Advertising > Reset Advertising ID and reset.
    • 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!

Top ▲

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

  1. 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.
  2. 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.

Top ▲

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:

  1. Select an App in the list of Apps in the Dashboard sidebar.
  2. Click Settings in the App Menu Bar.
  3. Select the Local Ntf tab.
  4. 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:

  1. Show After X Days – The number of days in the future from the time the notification is scheduled or re-scheduled.
  2. 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.local-notification-text


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

  • Open the Local Notification by clicking it.
  • Scroll down to the Tag Editor.
  • Click Edit and add a Tag.

Top ▲


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.

Top ▲

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:

  1. Select an App in the list of Apps in the Dashboard sidebar.
  2. Click Payload in the App Menu Bar.
  3. Click the Add New Payload button.
  4. Enter a Title and Description that help you remember what it does.
  5. Manually enter or paste JSON into the Payload Data field (The editor alerts you when it’s not valid JSON).
  6. Set the Start/Stop Date and Repeat conditions.
  7. 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.

Top ▲

Using Payload

While Payload are on your Dashboard, you can do any of the following at any time, and regardless of if they are live or Paused. Changes take effect in real-time:

  1. Edit Start/Stop Date and Repeat conditions.
  2. Edit the JSON Data.
  3. Add or remove Tags.
  4. Add or edit Rules.
  5. Pause and Resume them.
  6. Use the Test button to test them on registered Test Devices (See Dashboard Documentation: Test Device Setup).

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

Top ▲

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.

Top ▲

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:

  1. To cause something to repeat select the YES radio button.
  2. 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.
  3. To limit the number of times something can repeat, enter a value in the Stops after input.
  4. 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.

Top ▲

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.

Top ▲

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.

Rating Booster Tags

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:

  1. Rules & Conditions are evaluated first, to determine if a device matches and should be instructed to show whatever is controlled by them.
  2. 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.
  3. 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.
  4. 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.

Top ▲

Custom Event Data

Data Export

Data can be exported for all App analytics charts as well as your Poll and Survey data.

Export Analytics

  1. Use the Export button in the upper right of each chart to export that chart’s data.
  2. The data that is visible on the chart is the data that is exported.
  3. Data is exported in standard csv format.

Export Survey Data

  1. Select one of your published surveys in the sidebar on the left.
  2. Use the Export button in the menu above the displayed Survey results.
  3. Data that is exported is data for the selected published survey. If the top level of a survey is selected then all data for all publications of that survey are exported.
  4. Data is exported in standard csv format using UTF-8.
  5. The first row is always the header row.
  6. Column order is:
    • Entry – An arbitrary but unique ID for the answering device. All answers from the same device have the same entry Id.
    • Date – Date/Time respondent answered.
    • Question – The text of the question.
    • Option – The multiple choice answer the user selected.
    • Value – The free text answer the user supplied.

Top ▲

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

  1. Select the App you want to view Custom Data for on the Dashboard sidebar.
  2. Select the Custom Data section on the Dashboard
  3. Click the drop down at the top of that section titled: ‘Add Chart For Custom Event’.
  4. Select the Custom Event name from the list.
  5. 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.
  6. 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.

Top ▲

Test Devices & Testing

Test Device Setup

After adding Test Devices to your account, you can force AskingPoint widgets and Surveys to display in Apps using the AskingPoint SDK, on command.

To add Test Devices go to: Accounts > Test Devices, or click this link and go there now: Add Test Device

Test devices are associated with personal User accounts and are not available to other members of any Organization account you belong to.

Note: iOS Device Id changes when you start or stop using Ad Support Framework. If you added Test Devices before you made the change you will have to add the new device ID.

Adding Test Devices

  1. Go to Account > Test Devices.
  2. To quickly find your Device ID, run any App using the AskingPoint SDK iOS v2.1, Android v1.0 or later in your IDE.
  3. Examine the first 3 or 4 lines of console output for something that looks like the line underlined in the image below. Use the value displayed after DeviceID.
  4. Enter a Name for each device. Names can be anything and are to help you distinguish devices.


Top ▲


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

  1. Select the App to test in the Dashboard sidebar. Check that you’ve selected the App actually running on the Test Device.
  2. Click Settings on the App’s Dashboard Menu.
  3. Select the appropriate tab for the thing you want to test.
  4. For Rating Booster the Test button is on its Settings tab.
  5. 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.
  6. 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:

  1. Go to the Survey Tab on the Dashboard.
  2. Select the Published Survey the Dashboard sidebar.
  3. Make sure the App you’ve Published the Survey to, is running on the test device.
  4. Click Test in the Published Survey’s dashboard menu.
  5. Select a device to test the Survey on.

Top ▲

Account Management

Multi-User (Org) Accounts

Organization (multi-user) Accounts allow more than one user to see analytics and to control Apps. Organization accounts get billed independently and support granting users different access privileges.

Organization accounts make it possible to use a single login to manage Apps in multiple accounts: your user account, plus all Organization Accounts you are a member of.

Each person should Sign Up for their own AskingPoint account and then be added as Members to the Organization account owning the Apps they require access to.

To Create An Organization Account:

  1. Login to your own account.
  2. Select Account on the top menu bar or from the drop down in the upper right of your Dashboard.
  3. Select the Organization Tab.

The Organization tab is where you create and manage Organization accounts and see Organizations you are a member of.

Organization Rules & Information:

  • Creators of an Organization have Administrator privileges by default.
  • Administrators can:
    • Add and Remove users.
    • Manage Organization App Analytics.
    • Delete Organizations.
    • Administrators can not remove themselves from an Organization. If you are an Organization Admin and need to leave, ask another Administrator to remove you. If no other Admin exists, appoint one.
  • Members of an Organization with Analytics privileges:
    • Can use the Dashboard to see App Analytics for Apps belonging the Organization.
    • Can use the AskingPoint App to see App Analytics for Apps belonging to the Organization.

Top ▲

Moving Apps

You can move Apps between User or Organization accounts when the need arises. All associated Analytic data, Polls and results, and Rating Booster settings are also moved.

To move an App the following conditions must be true:

  • To move it to another User account you must know an email address associated with that account.
  • To move it to an Organization account you must be an Admin of that Organization.

How To Move An App

Apps are moved from an App’s Settings Panel. To move an App follow these steps:

  1. Select the App you want to move in the sidebar list of Apps.
  2. Click Settings in the Dashboard menu.
  3. Click the Move This App button.
  4. When the Move App dialog appears select the type of move.
  5. Provide either the email of the account you’re moving it to, or select one of the Organizations you are a member of.
  6. Double check you are moving the right App and click the Move This App button.

Top ▲

Organize, Sort & Search Apps

There are a few Dashboard features to help accounts organize and find Apps.


  1. Sorting Apps – Apps are sorted alphabetically in the App List.
  2. Searching Apps – The search box does a Begins With search of App Names or App Ids.
  3. Scrolling Apps– The list of Apps is limited to displaying approximately 50 Apps. To see Apps further down the list, move the mouse over the list and scroll.
  4. Favorite Apps – Apps marked as favorites are sorted alphabetically to the top of the list.
  5. Favorite Usage – 3 charts showing grouped usage for all Apps marked as Favorite.


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


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.

Top ▲

Contact Support

Contact Support

We’re here when you need us, and we DO want to hear from you. Please feel free to contact us anytime with technical questions regarding:

  • Issues you’re having with the SDK, Dashboard or the website.
  • New Features or enhancements you’d like to see added.
  • Any custom integrations you want to speak with us about.
  • Billing issues.

Send your questions to: support@AskingPoint.com

We’ll do our best to get it sorted ASAP!


Top ▲