Passing user information BASIC

You might want to pass user information to Ybug to help identify the user who sent feedback. This data can also be used for widget targeting, which lets you control exactly who sees the widget on your website or application.

You can pass any additional user information you need — strictly user-related fields, or other helpful context like an internal application identifier, application build/version, or environment (e.g. DEV, QA, PROD).

window.ybug_settings = {
    id: 'XXXXXXXXX',
    user: {
       id: '112233445566',
       username: 'john-doe',
       plan: 'FREE',
       // any other info you need to add context
    }
};

If you need to change user data later (for example when your user logs in), call Ybug.setUser():

Ybug.setUser({
    id: 'XYZ',
    role: 'admin',
    // ...
});

Logged-in users vs. visitors STARTUP

To correctly identify a user — which is necessary for targeting and segmentation — pass an id property within the user object.

• If the user is logged in, pass a unique ID (e.g. user: { id: 12345 }). We'll consider this a "user."
• If the user is a visitor (not logged in), omit id or pass null. We'll consider this a "visitor."

This lets you segment your audience based on login status (user vs. visitor).

Segment by user data STARTUP

Beyond login status, you can segment your audience using any arbitrary user property you pass.

For example, if you pass role: 'admin' or plan: 'basic', you can later set rules in your Ybug settings like:

• "Show the widget only to users where the user role is admin."
• "Hide the widget from users where the user plan is basic."

This gives you a practical way to manage the widget's visibility for different segments of your user base.

TIP

Even if the widget is hidden by targeting rules, you always have full control via the JavaScript API: call Ybug.show() or Ybug.hide() to programmatically override the visibility status.

Protecting sensitive data

Ybug automatically anonymizes common sensitive content out of the box — password fields, anything that looks like a credit card number, and inputs whose name contains words like password, token, key, secret, card or cvv.

If you need to protect more than that — for example custom token fields, on-page secrets, or anything specific to your app — you can mark elements with the data-ybug-sensitive attribute or list them via the anonymize_elements option. See Sensitive data protection for the full setup.