The surveys created in Zurvey.io are mobile responsive and can be easily viewed on iOS and Android devices.
You can embed surveys inside your iOS or Android mobile apps and achieve a seamless, non-intrusive experience. To cover all embedding cases, we offer multiple solutions based on the varying customization needs and developer resources.
a) Passive in-app feedback via button
Zurvey.io surveys are visualized in WebView as a default solution. Using this method, all branding and design elements (fonts, colors, and logo/imagery) are automatically handled by Zurvey.io, so you only need to focus on triggering the microsurvey from your app. The trigger can be a feedback/interaction button in the application, which loads the survey immediately.
Launch a webview
Use an event in your app (often a button-tap) to launch a webview of your survey URL:
https://s.zurvey.io/inapp?userflowid=1&userid=123&segmentid=premium
Pass context via URL parameters
With URL parameters, you can pass context from the app to the survey, including metadata, identificators, and user attributes. Besides this, URL parameters can trigger hidden questions, which could result in different survey questions for specific user flows, or specific segments.
These URL parameter values can be static, passing the same values each time to be tracked along with the survey, or dynamic, using a bit of extra code to dynamically fill in those fields with a variable.
A static URL parameter can be a user flow to place a button and collect all feedback from the billing screen from the app. A dynamic URL parameter can be a user id or segment id, which you need to retrieve and automatically pass as a parameter value.
https://s.zurvey.io/inapp?userflow=billing&userid=123&segmentid=premium
Redirect user to the app
After the user submits the survey, Zurvey.io shows a “Thank you page”. To redirect the user to your app, you have to listen to the successfulSubmit event. The successfulSubmit event will be sent by the standard message handler so you need to inject a message handler in your app.
- In the case of Android, it is the window.messageHandler in your app.
Using iOS, it is: WKWebView, window.webkit.messageHandlers.callback
Benefits |
Drawbacks |
Survey structure, logic, validation are all handled on Zurvey.io side |
Launching webview should be handled on the application side |
Branding and design can be set up Zurvey.io interface |
Branding and design, set up in Zurvey.io are deterministic in webview |
b) Active in-app feedback via widget
To gather feedback after special events or transactions happening during the user journey, we provide different feedback widgets to embed. Using this method you can gather contextual user insights to improve your application where it matters the most.
Our feedback widgets are HTML widgets, fully customizable on both HTML and CSS level. Different widget options are available, like rating (star, smiley) or scale (NPS®) type questions. Depending on the answer, each answer option will take the user to the full survey in WebView, automatically prefilling the first question, which has already been answered.
The processes and methods of launching the webview and handling URL parameters are the same as described in the Passive in-app feedback via button section, except that in the HTML widget, each answer option has a specific URL, so the parameter values should be applied for each URL.
Benefits |
Drawbacks |
Survey structure, logic, validation are all handled on Zurvey.io side |
Launching webview should be handled on the application side |
Branding and design can be set up Zurvey.io interface |
Branding and design, set up in Zurvey.io are deterministic in webview |
-
Transfer data via standard API
Using our standard API endpoint, any kind of primitive data can be channeled into Zurvey.io whether it comes from feedback forms, simple surveys or just a feedback input in a mobile application. In this case, we do not provide survey structure and assets, so the customization options are limitless, though these developments should be carried out on the client side.
The expected structure of the received data should be defined on the Zurvey.io interface. The system can handle the following datatypes:
- Number
- Text
- Category
- Date
- Unique ID
- NPS®
- CSAT
During the structure definition, you can set Unique IDs for each dimension. These IDs will be needed when sending data. Authentication happens through a bearer token accessible from the interface. Detailed documentation is available here.
Benefits |
Drawbacks |
Customization options are limitless |
Requires more resources on the developer's side |
Display structure does not have to follow the Zurvey.io restrictions |