Implementing in Native Apps
Last updated
Was this helpful?
Last updated
Was this helpful?
The mobile app uses webview for many of its screens
The app primarily uses native components (vs webview)
You want to leverage CSS for formatting or styling your surveys
You want to use native-only survey triggers such as number of launches and days since install
You want to leverage browser-based events, such as scrolling or
tapping specific elements, to trigger survey/poll triggers
You want to use URL-based targeting
You want to use JavaScript callbacks to customize the functionality and provide client-side integrations
You want to use web-specific capabilities such as All At Once (e.g., Feedback forms).
A single Pulse Insights survey or poll is designed to work across browser-based and Native SDK-based experiences. For example, you can configure a single survey to deliver across both native mobile and browser-based channels. Many targeting criteria are also inherently cross-channel:
Of course, Pulse Insights also supports creating channel-specific surveys. For example, if you want the native mobile survey to include an invitation but want web-based surveys to appear directly within the page (without invitation), you might opt to create two channel-specific surveys instead of one shared survey.
While there are many similarities and shared features across web and native apps, there are key differences in how the channels work. The following list, although not comprehensive, aims to convey the most important differences that should be considered when managing cross-channel campaigns.
The majority of features are compatible across web and native SDK channels including:
Survey invitations and text
Question types (open-ended, single choice, multiple choice)
Question branching
Polls (the ability to show results to end-users)
Web-based executions enable some features that rely on browser constructs such as:
Custom Content cards, which use HTML to display links or other content, usually at the end of a survey
Using images for answers
All-At-Once mode, which displays multiple questions at a time
Many targeting features are shared or managed centrally in the Console across web and native SDK channels including:
Eligible dates
Device Type eligibility
Page/URL/View conditions
Previous answer targeting
CRM targeting (based on Context or Device Data pushed to Pulse Insights)
Sample Rate
Behavior (e.g., whether to show again if the user closes the survey)
Global Frequency caps
Some web targeting features rely on browser-specific technologies including:
Browser-based event listeners, such as click, scroll, and content in view triggers
Browser-based visit counters and session depth counters
Browser-based executions leverage CSS and DOM manipulation to seamlessly insert surveys into the user experience using a number of widget formats:
Full screen overlay
Bottom bar
Inline (managed in the Pulse Insights Console via CSS selectors)
Docked widget
Top bar
Web-based executions use CSS which can be served dynamically at runtime from the Pulse Insights Console.
Accounts can have one or more shared themes – CSS that formats surveys for various question types, widget types, and device types. Additionally, web supports overriding the theme at a survey-level.
Pulse Insights pushes data to CRMs and Enterprise Data Lakes via back-end callbacks and file-based integrations. These integrations work universally, regardless of the channel that collected the data.
In addition to the back-end integrations mentioned above, web-based executions also enable client-side JavaScript callbacks. These are often used to integrate web analytics, A/B testing integrations, and other client-side technologies.
Channel-specific methods exist to ingest user information in Pulse Insights such as:
Device Data
Context Data
Pseudo-anonymous CRM key
Data from browser-based, native mobile, and API-based channels all flow into the same reporting. Some reporting fields are specific to the channel such as:
Browser
Browser Version
Completion URL
