Funnels
One product, two targets — build a funnel once, then serve it on the web or natively inside your app.
A funnel is one product: an ordered list of screens that asks the visitor questions, branches on what they answer, shows them an offer, takes the payment, and hands everything it learned to your app.
It exists because the first run of an app is the worst place to do any of that. A funnel meets the visitor before the install — in an ad's landing page, an email, a link in a bio — and the app starts already knowing who it is talking to.
One product, two targets
Every funnel is created for exactly one target — web or native — and the
target is set at creation: it cannot be changed afterwards. The target
decides what the funnel may contain — store purchase blocks live on native
funnels only, the Stripe checkout action lives on web funnels only — see
Targets for the full capability table.
What does not change between targets is how a funnel is built. Screens, elements, routing, and values work the same everywhere — see Build. Only the delivery path differs.
Two delivery paths
A web funnel is published to a URL. The visitor opens it in a browser at its slug or your own domain, pays with Stripe, and the app later claims the result — see Hosting and Claiming the Result.
A native funnel is served to a placement inside your app. The device fetches the funnel, draws it with the platform SDK, sells through the store, and reports the events — the funnel never has a URL.
The lifecycle
You build a draft: screens and elements, the routing chain on each screen, the values they read — see Screens & Elements, Routing & Branching, and Values. Editing edits the draft, so an unfinished screen is never live.
You publish the draft: it is checked and snapshotted — see Publishing. A session already in flight stays on the version it started with.
Then the funnel goes out along its target's path: a web funnel is served at its URL, where a session records what each visitor answers; a native funnel is served to its placement, where the device draws it and the purchase and lifecycle events flow back into your project.
Everything a session collects — answers, variables, and the values your app
supplied — lives in one key space. That is why {{first_name}} in copy, a
branching condition, and the map your app receives all spell a key the same
way.
Self-Service DSAR API
Let your own backend fulfil GDPR/KVKK subject-access and erasure requests for your end users, without a support ticket to Rovenue — four secret-key endpoints, what each one actually does, and what it doesn't.
Targets
A funnel is built for one target — web or native — and each target forbids what it cannot serve.