SDK stands for Software Development Kit, which is typically a set of software development tools that allows for the creation of applications. The Mobile SDK is primarily used to provide measurements within Mobile App Measures.
General Information
The SDK code controls the following:
Sampling Parameters
Survey Definitions
Survey Invitations
Client Logo on Invite
ForeSee Logo on Invite
CPPs
Languages
Once the code has been downloaded, any changes are the responsibility of the client, apart from the sampling percentage, which is ours.
If a respondent receives an invite/survey and then an app update is pushed, this data is stored in the app storage so we will not invite again.
ForeSee cannot host SDK codes. The only exception to this is Hybrid apps, though it is rare so check with Mobile SME prior to presenting this as an option.
ForeSee® SDKs only support iOS and Android operating systems. ForeSee does not support PhoneGap (Cordova) style applications. Clients can instrument their PhoneGap application on the platforms we support using native SDK.
ForeSee does not offer custom configurations for our SDKs, though the client is free to do custom configurations on their end.
An example of this would be configuring a time variable, such as somebody must be on the app for 30 seconds before receiving an invitation.
App Replay is delivered within an SDK instead of a code package. It utilizes a series of screen captures (up to 80MB) to recreate the experience the user had on the app.
In the ON_EXIT invitation mode, the user is assumed to have completed the survey as soon as they accept the invitation since there is no way for the SDK to know if they follow the link they have been sent.
ForeSee has the ability to interact with a number of third-party analytics services to provide integrations and data sharing between those services and our SDK. The following services are currently supported:
Adobe Marketing Cloud
Web Trends
Google Universal Analytics
By default, the SDK automatically captures and sends the following device related CPPs with the survey:
Model name (iPhone, iPad)
Brand name (Apple)
Browser (the version of Safari)
Operating System (iOS)
Operating System Version (7.1.2)
Is_tablet (true if the device is an iPad)
Resolution Width (screen width in pixels)
Resolution Height (screen height in pixels)
Screen Width (screen width in mm)
Screen Height (screen height in mm)
Locale (the device’s locale)
SDK supports three invitation modes:
Immediate - This is the default invitation mode. The survey is displayed immediately when the user accepts the invitation. The survey is displayed in a UIWebView by a custom UIViewController. It is automatically dismissed when the survey is completed or the user abandons the survey by pressing the Close button.
On-Exit - This invitation mode asks the user for an email address or a mobile number. After submitting the information to the ForeSee servers, the invitation is dismissed and the user is sent back into the app. No survey presents in this mode. Instead, after a period of time, the user is sent an email or an SMS text message with a link to the survey.
Client surveys must be configured on the ForeSee servers for this option to work properly. The client can enable it in their configuration file, but a survey link won’t be delivered unless properly configured remotely as well.
Local - In this mode, when the user accepts the survey invitation a local system notification is queued. Once the user exits the app, they see a local system notification informing them that they can take a survey. For further technical requirements surrounding iOS local invites, please click here.
Immediate - This is the default invitation mode. When Trigger is configured for this mode, the survey is displayed at the point where the user accepts the invitation. The survey is displayed in a WebView. It is automatically dismissed when the survey is completed or the user abandons the survey by pressing the Back button.
On-Exit - This invitation mode asks the user for an email address or a mobile number. After submitting the information to the ForeSee servers, the invitation is dismissed and the user is sent back into the app. No survey presents in this mode. Instead, after a period of time, the user is sent an email or an SMS text message with a link to the survey.
The client’s surveys must be configured on the ForeSee servers for this option to work properly. On-Exit may be enabled in the configuration file, but a survey link won’t be delivered unless properly configured remotely as well.
Local - In this mode, when the user accepts the survey invitation a local system notification is queued. Once the user exits the app, they see a local system notification informing them that they can take a survey. For local notifications, in addition to setting the mode in the configuration file, a layout for the notification, as well as an icon to be displayed in the notification bar, are recommended.
ForeSee has the ability to interact with a number of third-party analytics services to provide integrations and data sharing between those services and our SDK. The following services are currently supported:
Adobe Marketing Cloud
Web Trends
Google Universal Analytics
It may also be possible to add other integrations if the required data is available from within your app code.
By Default, the SDK automatically captures and sends the following device related CPPs with the survey:
Model name (e.g., GT-S7560M)
Brand name (e.g., Samsung)
Browser (e.g., Android WebKit)
Operating System (e.g., Android)
Operating System Version (Android 4.4)
Is_tablet (true if the device is a tablet)
Resolution Width (screen width in pixels)
Resolution Height (screen height in pixels)
Screen Width (screen width in mm)
Screen Height (screen height in mm)
On-Exit Contact Information Handling
How long do we store email and mobile phone numbers captured through the Mobile On-Exit invite process? - There is a daily job that runs everyday to remove all contact information (email or phone number) every 24 hours. If a client has a reminder policy set up, then the contact information is saved in our system until the reminder date is met and then removed within 24 hours.
Support Guidelines
When an issue has arisen with a client's in-app implementation, the best first step is to gather information about what happened. Some good initial questions to ask are:
When did the issue start? Was there some change you made in your app code?
This will allow you to determine if the issue arose because of something the client has done, or some external issue.
Does the issue persist if you uninstall and reinstall the app?
Clients often forget that the SDK has a state. Uninstalling and reinstalling the app is a quick and easy way to see if the state is causing the confusion. If the problem is solved after this resetting of state, you should mention to the client that once one invite is shown, the repeatDays threshold must be met before a new invite is shown.
What version of our SDK are you using?
This allows us to be able to mirror the client's setup by stepping back to the version they are using.
Is there a problem with the configuration?
Ask the client to send you their configuration JSON. From this you can often tell where things might be going wrong.
What platform is this happening on? iOS, Android, or both?
This is useful for the same reason as understanding the version, but if the issue is happening on both, it's more likely to be something external to both the client's code and our SDK code since it's unlikely the same issue would crop up in two different implementations. Of course, that's not a guarantee, as we've seen with previous clients.
What notification type are you using?
On iOS, local notifications can cause confusion because the user may have previously declined local notifications and therefore the invitation does not show. Because this setting is hard to reset, this confusion can extend even after the app is uninstalled.
Are you using a cross-platform development language?
Cross platform frameworks such as Xamarin, Cordova (PhoneGap), Appcelerator, etc. can all cause problems with our SDK. Although we do not officially support these platforms, there are possible ways to implement with them and some support can be given.
Exclusions
For web based SDK, page exclusions can be based on things such as specific URLs, referring domains, browsers, cookies, etc. These are not applicable to in-app SDK. In-app SDK depends on a command to show the invitation. This command must be placed in any place the invitation is required to show.
Because of this, it is also impossible to execute global exclusions based on IP address (this is usually done when trying to exclude internal IP addresses).
Cookies
Cookies do not really exist as such in apps. Although ForeSee does store a state and keep a count of the measurement criteria, it's done with persistent storage rather than cookies.
Sampling Parameters
Sampling percentage works in a similar way to web measures: Once the eligibility criteria has been met (launch count, significant events, etc), the user is sampled according to a percentage set on our servers. If they pass, they are shown an invitation. If they fail, they are resampled next time they open the app.
IS sets sampling percentages for in-app measures.
The concept of loyalty factor as it applies to web-based trigger code (number of pages into a session) is not applicable to in-app SDK. Since a loyalty factor does not exist, there is no place in the code to set it.
Unlike web-based trigger code, where setting sampling parameters to 0 effectively “turns off” the code, setting any criteria to 0 within the in-app SDK means that the invitation launches immediately (after 0 launches, for example). If the client wants to ignore a criteria, that line should be removed from the configuration.
Event Triggers
Our SDKs have the following built in events for triggering survey invitations:
Number of times the app has been launched:
The client can select this value themselves via the configuration file included within the SDK.
Number of days since the app was launched and installed:
The client can select this value themselves via the configuration file included within the SDK.
Significant client owned events:
e.g., click a specific button, reach a specific page on the app, complete a purchase.
These events can be anything the client decides. They are incremented using a command called on the SDK.
Lifetime Page views:
The number of Activity resumes (Android) or ViewController appearances (iOS) in the app.
After triggering this event based on the count determined by the client, the survey won’t show for another 90 days. The next time the visitor opens up the app after the 90 days are up, the counter resets.
