MicroSurveys

Contextual in-app micro-surveys — the Stripe of in-app feedback.

MicroSurveys lets you ask the right user the right question at the right moment, directly inside your app. You design surveys and their targeting in a web dashboard; the SDK listens to the analytics events you already send, decides locally when a survey is eligible, and presents it natively — without shipping new app code for each survey.

How it fits together

There are three pieces:

• Dashboard — where you (or your PM) create projects, connect an analytics source, design surveys and question types, and configure triggers, targeting, appearance, and frequency.
• SDK (iOS today) — a small library you embed once. It fetches your published config, watches your events, evaluates eligibility on-device, and renders the survey using your dashboard-configured theme.
• API — the wire contract the SDK talks to: it serves config and ingests impressions and responses.

The flow, end to end:

Dashboard  ──publish──▶  API  ──GET /config──▶  iOS SDK
                                                    │  (matches your events locally)
                                                    ▼
Dashboard  ◀──analytics──  API  ◀──impressions + responses──┘

Why zero per-survey code

Everything about a survey — its questions, when it fires, who sees it, how often, and how it looks — lives in the config the SDK downloads. Publishing a new survey or tweaking targeting is a dashboard change, not an app release. The SDK evaluates the full eligibility order on-device, so it works offline and never blocks on the network to decide whether to show a survey.

Start here

• Getting started — create a project, connect analytics, and get your API key.
• iOS SDK — add the package and wire it up in three lines.
• Concepts — surveys, triggers, targeting, sampling, and caps.
• API reference — the SDK ↔ API contract.