Skip to main content
An in-product survey has type: IN_PRODUCT_SURVEY and is presented by a Sprig SDK when a visitor matches its targeting configuration.

1. Create the draft

Choose WEB or MOBILE at creation time. The platform cannot change later.
Save the returned Study id, version, and ETag. studyUrl opens the Study in the Sprig dashboard for authors.

Completion and sampling

Completion can be:
  • FIXED with a total responseLimit.
  • UNTIL_DATE with an ISO 8601 closeAt.
  • ONGOING.
An ongoing Study can sample by a percentage of eligible users or a daily send cap. Omitting sampling on an ongoing Study uses 7 percent. Fixed in-product surveys also use Sprig’s non-configurable daily delivery cap.

Recontact

retakeSurvey controls whether the same respondent may respond again. resurveyWindowSeconds overrides the product-level recontact period; send null to use the product default.

2. Add supported Questions

Create Questions with the Study’s current ETag. The API validates Question kinds and settings against the in-product platform.
Use the Question schema as the source of truth for each request. Blocks can group and organize Questions, but Pages (displayAsPage: true), uploaded assets, and invitations are not supported for in-product surveys through the Study API.

3. Prepare trigger Events

Your SDK must send the code Event or observe the page URL Event that should trigger the Study.
  1. Instrument the Event in the appropriate SDK.
  2. For a new code Event, approve it in Events > Manage Requests.
  3. Call GET /v2/events and save the Event’s public UUID.
The Study API lists existing Event definitions but does not create them.

4. Configure targeting

The first PUT creates the targeting sub-resource. Every later PUT replaces it completely.
PAGE_VIEW_COUNT and DEVICE_TYPE are Web-only conditions. For all platforms, multiple triggers use OR semantics and nested audience groups use their explicit AND or OR operator. See In-product targeting for supported conditions and limits.

5. Validate the complete Study

An in-product survey requires at least one supported Question and one Event trigger. Resolve every validation issue, including platform-specific appearance, replay, Question, and targeting issues.

6. Launch

Read the Study again to obtain its latest ETag, then send a lifecycle-only update:
If the Study changed after validation, launch can still return STUDY_NOT_READY. Resolve the returned issues, read the latest ETag, and retry.

7. Update a running program

Pause the Study before changing authored settings or content:
  1. Update only status to PAUSED.
  2. Read and save the returned ETag.
  3. Change Questions, settings, or targeting.
  4. Validate again.
  5. Update only status to IN_PROGRESS.
Do not combine a lifecycle transition with settings in one PATCH.