Mobile apps
You can collect feedback inside a native or hybrid mobile app without a special SDK. e-satisfaction doesn't ship a native mobile SDK — instead, you open a survey's public link inside a web view, and the survey runs exactly as it would in a browser. This keeps the integration light: there's no library to embed, nothing to keep updated, and the survey content stays fully controlled from the dashboard.
This page shows how to open a survey in your app and pass in-app context along with it.
How it works
Every survey can be reached through a public link — a plain URL that renders the full questionnaire. To put that survey in your app, you load the link inside an embedded web view: a WKWebView on iOS, a WebView on Android, or any embedded browser component in your cross-platform framework. The survey renders inside that view like any web page.
The link format is:
https://collection.e-satisfaction.com/q/pub/{questionnaire_id}/{locale}
Replace {questionnaire_id} with your survey's ID and {locale} with the language you want, for example en or el. You can generate and customize this link — including its appearance and behavior — from Public links.
Passing in-app context
To tag responses with what the user was doing, append metadata as query parameters on the public link. Each parameter becomes context attached to the response:
https://collection.e-satisfaction.com/q/pub/{questionnaire_id}/en?order_id=67890&customer_id=12345
Build the URL in your app code with whatever values you have at that moment — an order ID at the end of a checkout flow, a customer ID for a logged-in user, a store or screen name. Use the same field names you've defined in the dashboard so the values are stored and usable in segments and routing, just like metadata pushed from a website.
Define your fields first
As with any metadata, the query-parameter names you pass must match fields you've already defined in the dashboard (Admin → Data & AI). Names that aren't defined won't be stored.
Opening the survey in your app
Get the public link
Generate the survey's public link from Public links and note its {questionnaire_id}. Customize its appearance there if you want it to match your app.
Build the URL with context
In your app, assemble the link and append any metadata you have as query parameters — for example ?order_id=67890&customer_id=12345.
Open it in a web view
Load the URL into a WKWebView (iOS), a WebView (Android), or your framework's embedded browser. Give the view full width and height so the survey has room to render.
Allow redirects
Make sure the web view follows redirects — the survey relies on them, so don't block navigation within the view.
Handle closing yourself
Provide your own way to dismiss the view — listen for survey completion or show a close control — so the user can return to the app cleanly once they're done.
Practical tips
- Trigger at a natural moment. Open the survey at the end of an order flow, behind a visible "Give feedback" button, or on a custom event — not the instant the app launches.
- Give it room. A survey rendered in a cramped view is hard to complete. Let the web view fill the available space.
- Allow redirects. The survey navigates internally; blocking redirects can leave it stuck on a blank or partial screen.
- Own the close behavior. Because this is your web view, dismissing it is your responsibility — wire up a close control or react to completion so the user isn't trapped.
One link, many contexts
You don't need a separate survey per screen. Reuse the same public link and vary the query parameters to capture where in the app the feedback came from — then split the results later with segments.
Related articles
Public links
Generate, customize, and share the link you'll load inside your app's web view.
Pushing metadata
Understand responder vs questionnaire context and how field names must match.
Segments
Slice in-app responses by the context you passed as query parameters.
Web integration
Configure on-site surveys for the web side of your experience.