Ask users logo
Ask users
BETA
Iniciar

Display rules

Control when and to whom your widgets are shown using powerful targeting rules based on user attributes and behaviors

Visual rule builder

You don't need to write rules manually! Use our visual rule builder to configure targeting conditions, behavioral triggers, and frequency settings using intuitive controls.

✨ Try it:Dashboard → Your Survey/Form → Actions → Display Rules

What are display rules?

Display rules allow you to conditionally show or hide widgets based on user characteristics and behaviors. Instead of showing the same widget to everyone, you can target specific user segments or trigger the widget based on user actions like scrolling, time on page, or exit intent.

Example: Show a satisfaction survey only to premium users who have been on the page for more than 30 seconds, or display a feedback form only to users with a specific account type.

Display rules work by evaluating conditions against user data you provide through targeting attributes, combined with behavioral triggers like page load, scroll depth, or exit intent.

Targeting attributes

Targeting attributes are user-specific data points you provide to the widget system. These can include user properties like account type, subscription plan, user role, or any custom data relevant to your application.

Setting attributes

Set targeting attributes using the setTargetingAttributes method. This should be called before the widget initializes, typically right after loading the widget scripts.

Example: Setting targeting attributes

<!-- Widget HTML -->
<div class="askusers-survey-widget"
     data-survey-id="your-survey-id"
     data-display-mode="popup"
></div>

<!-- Widget scripts -->
<script src="https://askusers.org/widget/widget-common.js"></script>
<script src="https://askusers.org/widget/survey-widget.js?api-key=YOUR_API_KEY"></script>

<!-- Set targeting attributes -->
<script>
  // Replace these with actual user data from your application
  // For example, fetch from your user session, authentication system, or database
  window.AskUsersWidget.setTargetingAttributes({
    userType: "premium",
    plan: "pro",
    accountAge: 365,
    industry: "technology",
    teamSize: "10-50"
  });
</script>

Important: Attribute values are provided by your application and can be any data type (strings, numbers, booleans, arrays, or objects). Make sure to fetch real user data from your authentication system, user session, or database.

Common attribute examples

User account attributes

  • userType - "free", "premium", "enterprise"
  • plan - "basic", "pro", "business"
  • accountAge - days since account creation (number)
  • role - "admin", "user", "guest"

Usage attributes

  • loginCount - number of times user has logged in
  • lastLoginDays - days since last login
  • featureUsage - array of features used
  • isActive - boolean indicating active status

Business attributes

  • industry - "technology", "healthcare", "finance"
  • companySize - "1-10", "11-50", "51-200", "201+"
  • location - country or region code
  • revenue - revenue tier or bracket

Rule builder

The visual rule builder in the preview interface allows you to create complex targeting conditions without writing code. You can combine multiple conditions with AND/OR logic to create sophisticated targeting rules.

Example: Rule configuration

userTypeequals"premium"
AND
accountAgegreater than30

This rule will show the widget only to premium users who have had their account for more than 30 days.

Available operators

String operators

  • equals - exact match
  • notEquals - not equal to
  • contains - string contains value
  • startsWith - starts with value
  • endsWith - ends with value

Numeric operators

  • greaterThan - value > threshold
  • lessThan - value < threshold
  • greaterThanOrEqual - value ≥ threshold
  • lessThanOrEqual - value ≤ threshold

Array operators

  • in - value is in array
  • notIn - value not in array

Boolean operators

  • isTrue - boolean is true
  • isFalse - boolean is false

Behavioral triggers

Behavioral triggers determine when the widget should appear based on user actions. These can be combined with targeting attributes for precise control.

Page load

Show the widget immediately when the page loads (default behavior)

Time delay

Show the widget after a specified number of seconds on the page

Example: Show survey after user has been on page for 30 seconds

Scroll depth

Show the widget when user scrolls to a specific percentage of the page

Example: Show feedback form when user scrolls 75% down the page

Exit intent

Show the widget when user moves cursor toward the browser's close button or back button

Example: Show retention survey when user is about to leave

Idle detection

Show the widget when user has been inactive for a specified duration

Example: Show help form after 60 seconds of inactivity

Frequency control

Control how often users see your widget to avoid survey fatigue and improve response quality.

Always show

Display the widget every time the page is loaded (no frequency limit)

Best for: Critical feedback collection, contact forms, or inline widgets

Once per session

Show the widget only once during each browser session (until browser is closed)

Best for: Quick surveys, feedback requests during active use

Once ever

Show the widget only once to each user (tracked via localStorage)

Best for: One-time surveys, NPS surveys, onboarding feedback

Response tracking

By default, widgets will not be shown again to users who have already responded. This prevents survey fatigue and ensures you collect responses from a wider audience.

Automatic tracking: Once a user submits a response, their response is tracked via localStorage, and the widget will respect frequency control settings even if they return to the page.

Testing display rules

The display rules interface provides tools to test your rules before deploying them to production.

Testing workflow

  1. 1Go to your survey/form and click Actions → Display Rules
  2. 2Configure your targeting rules using the visual rule builder
  3. 3Click Preview to test your widget with the configured rules
  4. 4In preview mode, set test attributes to simulate different user profiles
  5. 5Test different combinations of attributes to ensure your rules work as expected
  6. 6Copy the generated installation code with your configured attributes

Tip: Test edge cases like empty attributes, missing properties, and unexpected values to ensure your rules handle all scenarios gracefully.

Best practices

✓Start with simple rules

Begin with basic targeting rules and add complexity only when needed. Overly complex rules can be difficult to maintain and debug.

✓Use meaningful attribute names

Choose clear, descriptive attribute names that make your rules easy to understand. Use consistent naming conventions across your application.

✓Respect user experience

Use frequency control to avoid survey fatigue. Don't show widgets too often or at inappropriate times. Consider using exit intent for non-critical surveys.

✓Test thoroughly

Always test your display rules with different user profiles and scenarios before deployment. Verify that rules work correctly for both matching and non-matching cases.

✓Handle missing attributes gracefully

Design your rules to handle cases where attributes might be missing or undefined. The system will fail-open (show widget) by default when evaluation fails.

✓Document your targeting strategy

Keep track of which attributes you're using and what they mean. This helps when creating new widgets or troubleshooting issues.

Common use cases

NPS survey for premium users

Goal: Measure satisfaction among paying customers

Targeting: userType = "premium"

Trigger: After 30 seconds on page

Frequency: Once ever

Feature feedback for early adopters

Goal: Get feedback on new features from engaged users

Targeting: accountAge > 90 AND loginCount > 20

Trigger: Page load on feature page

Frequency: Once per session

Exit survey for churning users

Goal: Understand why users are leaving

Targeting: lastLoginDays > 14

Trigger: Exit intent

Frequency: Once per session

Industry-specific survey

Goal: Collect feedback from specific industry segments

Targeting: industry in ["healthcare", "finance"]

Trigger: Scroll to 50%

Frequency: Once ever

Help request for struggling users

Goal: Offer assistance to users who may need help

Targeting: loginCount < 5

Trigger: After 60 seconds of inactivity

Frequency: Once per session

Related documentation

Widget configuration

Learn about display modes, positioning, and styling options

Widget triggers

Configure button, icon, and condition-based triggers

Forms documentation

Learn about creating and managing forms with display rules

Surveys documentation

Learn about creating and managing surveys with display rules