Targeting & Triggers
Control exactly who sees a survey, on which pages, when it fires, and how often it can reappear — with audience segments, identity restrictions, URL rules, auto, event, and manual triggers, and frequency caps.
Where to find it
Open Surveys
Sidebar → Surveys → open a survey → Targeting
Direct link: https://app.productbridge.io/dashboard/surveys
In-app path: Sidebar → Surveys → open a survey → Targeting section of the editor
Requires: a plan that includes the app_surveys feature. Without it the Surveys item does not appear in the sidebar.
The Eligibility Model
A survey is shown to a visitor only when every condition is satisfied at once: the survey is published, the visitor is in the target audience, the current page matches the location rules, the trigger has fired, and the visitor hasn't already seen it within its frequency window. Getting these right is the difference between a survey that reaches the right people at the right moment and one that never appears — or appears too often.
Audience
Decide who is eligible in the Audience section of the editor.
| Setting | Effect |
|---|---|
| Everyone | Any eligible visitor can see the survey. |
| A user segment | Only members of the chosen user segment are eligible. |
Restrict to identified users
Enable Only show to identified users to hide the survey from anonymous visitors. It will only appear for end-users your app has identified through the SDK's identify() call.
Targeting by segment implicitly requires identity — a segment is defined by user attributes, so anonymous visitors can never match one. Use segment targeting when you want a specific cohort, and the identity restriction when you simply want "any signed-in user."
Location Rules
Use the Location setting to control which pages a survey can appear on.
- All pages — the survey is eligible everywhere.
- Specific pages — the survey appears only where your URL rules say it should.
When you choose specific pages, add one or more rules. Each rule is either a Show on or Hide on rule matched against the current URL, and * acts as a wildcard.
| Pattern | Matches |
|---|---|
/pricing/* | Any page under /pricing/ |
app.example.com/dashboard | The dashboard page on that host |
*/settings/* | Any settings page on any path |
A Hide on match always wins. Otherwise, the page must match at least one Show on rule for the survey to appear. If you add only hide rules, the survey shows everywhere except the hidden paths.
Triggers
The Trigger setting decides when an eligible survey appears.
Auto
Shows on page load, after an optional delay. Best for broad, always-on surveys like a recurring NPS.
Event
Shows when your app fires a named event. Best for moment-based surveys like CSAT after a ticket closes.
Manual
Never shown automatically — appears only when your app calls startSurvey(). Best for a "Give feedback" button or a custom moment in your UI.
Auto trigger
The survey appears automatically once the page loads and the visitor is eligible. Use the Delay (seconds) field to hold it back — for example, wait 10 seconds so it doesn't interrupt someone the instant they arrive. A delay of 0 shows it immediately.
Event trigger
The survey waits for a specific event. Set an Event name in the editor, then fire it from your app when the moment arrives:
// Fires the survey configured with the event name "ticket_closed"
ProductBridgeSurveys.track('ticket_closed');
The Delay (seconds) field still applies — it's the wait after the event fires before the survey shows. See Installation & SDK for the full runtime API.
Manual trigger
The survey is never shown automatically — it appears only when your app explicitly asks for it by ID. Choose Manual in the editor, then call startSurvey() from your own code at the moment you want it:
// Show this specific survey on demand — e.g. from a "Give feedback" button
ProductBridgeSurveys.startSurvey('SURVEY_ID');
Use it for surveys you want to fire from your own UI — a "Give feedback" button, the end of a custom flow, or any moment that isn't a simple page load or a named event. Find the survey's ID in the editor's Survey ID section (or next to Share by link in a survey's analytics).
A manual survey still honors every other eligibility rule — audience, the identified-users restriction, location, and frequency caps all apply. startSurvey() only opens the door; it doesn't bypass targeting. The Delay (seconds) field is the wait after startSurvey() is called before the card appears.
See Installation & SDK for the full runtime API, including identify() and reset().
Frequency
Frequency caps stop a survey from pestering the same person. Set them in the Behavior section:
- If the user responds — never show again, or show again after N days.
- If the user closes — never show again, or show again after N days.
A recurring window (for example, "show again after 90 days") is what turns a one-off NPS into an ongoing pulse.
Frequency is enforced for identified users only. To reliably cap how often someone sees a survey, identify your users with the SDK — otherwise ProductBridge has no stable identity to track "already seen" against.
Putting It Together
Set the audience
Choose everyone or a segment, and decide whether to restrict to identified users.
Scope the pages
Leave it on all pages, or add show/hide URL rules for specific parts of your app.
Choose the trigger
Auto for always-on surveys, event for moment-based ones, or manual to fire it yourself with startSurvey() — with a delay if needed.
Cap the frequency
Decide what happens after a user responds or closes, so nobody is over-surveyed.