Survey and questionnaire bot for a mobile app

Surveys in a mobile app: where responses get lost

Surveys in a mobile app break more often not at the stage of wording questions, but at the junction of display and saving.

A questionnaire is tied to a specific screen rather than to an event in the scenario: the user receives it in the middle of checkout, minimizes the app — and returns to a different state of the interface. Responses sent from the local queue do not survive process termination and go nowhere.

Drop-off in the middle of a questionnaire is almost always explained not by the length of the survey, but by the absence of intermediate saving and visible progress.

A person answers eight out of twelve questions, loses connection in the subway — and the whole block goes to waste, although most of the responses have already been collected.

In reporting, this looks like "users do not want to answer," and the team draws a conclusion about product quality instead of a conclusion about the display mechanics.

Feedback collection in an app becomes worthless if a response carries no context: app version, platform, cohort, entry point.

Without these fields, you see a steady stream of ratings in which it is impossible to separate the problem of a specific release from the general background. Decisions are made on incomplete data — and the next iteration closes the wrong problem from the one users noticed.

Embedded surveying gives a reliable picture only when display, saving, and export are designed as a single loop with retries and duplicate protection. We break down how this is covered.

What in-product surveying delivers: the effect in metrics

When a questionnaire lives inside the app, it does not need to be taken anywhere: the question appears at the moment when the user has just performed an action and the context is still fresh.

The share of completed questionnaires in such a scenario is many times higher than with an external form, because the gap of "received an email — opened a browser — forgot why I came" disappears.

Time to first response is measured in minutes after release, not in days of correspondence and reminders.

Technically, this is an event-driven scenario: a trigger by action, one question per screen, a progress indicator, and branching based on previous answers. Responses arrive already tagged — with user ID, app version, platform, and the segment they belong to.

Because of this, manual response processing shrinks to reviewing open comments: exports, table merging, and checking "who wrote this and on which build" are no longer needed.

A separate class of failures that usually eats up such studies is eliminated: a question is not delivered, delivered to the wrong audience, or a response is detached from the version it was left on.

We keep delivery on the Firebase notification service with deduplication and frequency capping — the user does not receive the questionnaire twice and does not receive it the next day after contacting support.

In metrics, the effect of surveying is visible at three points: share of completed questionnaires, time to first response, and volume of manual support operations. The first two grow, the third falls, because responses are already tagged and sit next to product events.

The team receives not a post-mortem report, but a continuous data stream on which it can change the interface without guessing.

Response collection formats: comparison of approaches and limitations

The response collection format is chosen not by the beauty of the screen, but by three questions: where data is stored, how often the questionnaire changes, and whether validation is needed during completion.

With poor connectivity, offline mode and draft saving are more important than smooth animations, and for a one-off study it is cheaper to take a ready-made tool than to develop screens.

Each added format means its own validation branch, its own reminder rules, and its own analytics slice.

A workable scheme: one main channel for regular measurements plus a second for rare long questionnaires, with results written to a common storage — otherwise the picture for a user falls apart into incomparable parts.

How we implement: stages of engineering work

Survey implementation starts not with screen mockups, but with a scenario audit: who takes the questionnaire and at what moment, what happens on connection loss, how responses reach the system of record.

The structure of the questionnaire, the display moment, and the set of fields worth asking at all depend on this. Below is the sequence of work, after which the logic is validated on live scenarios rather than ideal test data.

1. Scenario audit — we examine user paths, entry points to the survey, and display rules: whom we ask, how often, what we do with those who have already answered.
2. Data flow diagram — we design how a response goes from the app to the server and then to storage and reporting, where duplicates are possible, and how retries are handled.
3. Access rights — we distinguish roles: who creates and edits questionnaires, who sees only aggregates, who exports responses; every action is logged.
4. Logic setup — branching based on previous answers, completion conditions, attempt limits, offline operation with deferred sending.
5. Logic validation — we run questionnaires on real devices and weak connectivity, deliberately break scenarios: interruption, double response, re-entry, app version change.
6. Documentation and handover — we leave flow diagrams, field descriptions, instructions for questionnaire editors, and the procedure for rolling out updates without stopping the service.

What you keep after handover: a set of settings

We hand over the set at the end of the project, not "sometime later": without it, any edit — from a new question wording to a branching change — requires reverse-engineering the code.

Therefore, what you get is not an archive of files but a working coordinate system by which your team or another contractor continues developing surveys in the mobile app without us.

• Screen map — all questionnaire steps, transition conditions, states of "question skipped" and "session interrupted," and the binding of each screen to an analytics block.
• Flow diagrams — the path of a response from device to storage: what happens on connection loss, how retry works, where the response is de-identified, and at what stage it reaches reporting.
• Data model description — response fields, types, requiredness, questionnaire version flag, so that responses from the old and new revisions do not mix in one sample.
• Question texts and branching logic in editable form — wording changes without releasing a new app build and without re-passing moderation in app stores.
• Access policies and role matrix — who sees aggregated slices, who sees personal responses, how separation is configured, and what goes into the action log.
• Update procedure — the order of releasing a new questionnaire version, rollback rules, and what to do with unclosed user sessions at the moment of publication.
• Documentation set — local launch instructions, environment diagram, acceptance check list, and the procedure for transferring rights to the repository, app stores, and analytics.

We separately record the owner of each artifact: diagrams and procedures live in your repository, not in chat, so a discrepancy between documentation and the app's actual behavior is visible at the validation stage, not six months after launch.

Case study: feedback collection at a critical payment step

What it was before intervention

In the mobile app of a delivery service, more than half of users abandoned checkout at the payment step. The "payment started" event was recorded in product analytics Amplitude, and then there was a drop-off — the reason could not be reconstructed from the numbers.

Hypotheses within the team diverged: the payment method selection gets in the way, the bank confirmation code fails, or the long address form has an effect.

What we did

A full questionnaire at the critical step would itself have caused churn, so we showed one question — "What prevented you from completing payment?" — with four options and a free field.

Display condition: the user spent more than 20 seconds on the payment screen and left without a purchase, and the window does not pop up again within one visit.

The response was tied to a segment — payment method, device model, OS version — so the output was a distribution of reasons by group, not a stream of complaints.

Metrics before and after

The response rate was 34% of those who saw the question, versus the usual 5–8% for emails. In 6 out of 10 responses, one reason repeated: the default payment method was not supported by some banks.

After reordering the methods by the actual share of successful transactions, drop-off at this step fell from 47% to 31%, and the time from opening the screen to successful payment decreased from 40 to 27 seconds. Support requests on payment became about three times less frequent.

How do embedded surveys differ from external services?

An embedded survey is a screen of the app itself: display is controlled by code, and responses go into the same profile as other events. An external service is a separate questionnaire where the user goes via a link.

The difference is in display control. An embedded module is triggered after a specific action, for a selected group, and once per user. An external link lives on its own: it can be sent out, but you cannot guarantee who will open it and at what step.

The second difference is the link to the profile. Responses inside the app sit next to purchase history and in-app behavior. External services, including SurveyMonkey, return a de-identified set of rows that is matched manually.

The comparison is rounded out by the speed of changes: editing a question in an embedded module means releasing a new version, and some users will remain on the previous build. An external service changes on the fly but does not use native elements.

That is why a hybrid is often chosen: the app renders the questions, and an external platform handles collection and reports.

Technical doubts before starting: we answer point by point

Doubts usually surface not at the scenario stage, but when it comes to operations: how much work each new survey will require, what will happen to a questionnaire that was closed in the middle, and who inside the company will see the responses. We break down the four questions that most often slow down the decision.

What happens to a questionnaire that was interrupted in the middle?

Responses are saved as a draft on the device, and upon return the questionnaire opens at the step where the person stopped.

Data goes to the server either entirely upon completion or in portions during completion — the choice depends on the sensitivity of the responses and on whether partial statistics on those who did not finish are needed.

How is question branching structured?

Transitions are described as rules depending on previous answers, not as separate questionnaires for each scenario.

The schema remains single, so the logic is visible as a whole, and edits do not sprawl across copies: you change a condition in one place — and everyone who has not yet started the survey gets the new route.

How are responses protected, and who sees them?

Data is encrypted in transit and at rest, and access is separated by roles: an analyst receives summaries without personal data, while the person responsible for the survey receives detail.

Exports are de-identified, and access to responses is written to a log — you can see who exported what and when.

Let's discuss the task: what is needed for an estimate and plan

To come back with an estimate and work plan rather than general wording, we need a minimum of product inputs. Usually one conversation and access to current documentation or app code are enough — we clarify the rest as we discuss the task.

• Survey scenarios: which forms are needed, branching and transition logic, question types — single and multiple choice, scales, free text.
• Audiences and access: who takes the survey, required completion, guest mode, authorization, roles in the admin panel.
• Data schema and reporting: where responses are stored, which slices are needed, export formats.
• Integrations: what already exists in the app, where to send results — system of record, analytics, mailing.
• Load: how many users and surveys at peak, mailing waves, behavior on weak network and unfinished sessions.
• Personal data: which fields we collect, how consents are recorded, retention periods, and hosting region.
• Platforms and design: target platforms, mockups or references, compliance with app store rules.

If some answers are not ready yet, it does not block: for key points we will propose options and show how the solution will behave as it scales. Describe the task — we will come back with an estimate, work plan, and team composition.