Resources

Identifying users

Why Reveal needs to know who a visitor is, what it will use that for, and what to plan on sending.

Reveal can target a guide at New users, Returning users, or All users without knowing anything about the person beyond what the pixel can see in the browser. Anything more specific than that, showing a guide only to admins on the Pro plan for instance, needs your app to tell Reveal who the visitor is.

That is what identifying users is for. The Audience setting on a guide's Behavior tab already points at it: the Custom segment… option is described in the app as "Filter by user properties from your identify call."

Coming soon. The identify integration and Custom segment… targeting are still rolling out. The exact call, its name, and its arguments are not settled, so treat this page as what to plan for rather than an API contract. Confirm the signature with the Reveal team before you build against it, and do not ship code written from the description here.

What Reveal will use it for

Matching audiences. A custom segment is a filter over the properties you send. Without an identify call there is nothing to filter on, which is why audiences today stop at new, returning, and all.

Attributing feedback to a person. Ratings and comments collected on the feedback screen can be tied back to a known user instead of an anonymous session, so Latest feedback tells you who said it.

Masking identity when the audience is anonymous. Sending identity does not mean every part of the product starts showing it. Where a guide's audience is anonymous, Reveal is designed to keep the person's identity out of what it displays, and use the properties only for matching.

What to send when it is ready

Keep it small. The useful shape is a stable identifier plus the handful of traits you would actually build a segment on.

  • A stable user id The same value for the same person across sessions and devices. Your internal user ID is usually right. Something that changes on every login, or an email you might let people edit, is not.

  • Plan The most common segment. Show one onboarding guide to trial users and a different one to paid.

  • Role Admin, member, viewer, whatever your product calls them. Useful when the thing you are explaining is only visible to some of them.

  • Signup date Lets you separate genuinely new accounts from people who have been around for months.

Add a trait when you have a guide you would target with it. A long list of properties nobody segments on is just more data to keep in sync.

Heads up. Do not send anything sensitive. No passwords or tokens, no payment details, no government identifiers, no health information, and nothing you would not want present in a browser payload. Traits sent from the client are visible to anyone who opens devtools on your page.

Segment

If you already identify users through Segment, you will not have to do this twice. Segment is listed under Settings, Integrations with the description "Identify users automatically via your Segment source."

Coming soon. All five integrations, Segment, Mixpanel, Amplitude, HubSpot, and Intercom, are marked Coming soon in the app today. None of them are connected yet.

Until then

You can do useful targeting without identify. New users covers first session on the pixel domain, Returning users covers people who have been before but have not finished this guide, and setting the trigger to Manual only lets your own app decide when a guide is appropriate by starting it from a Reveal button or a dynamic link. Between those, most first onboarding guides land where they should.

Next steps

  • Audience: Who sees a guide, and what each option means today.

  • Triggers: When a guide fires, including manual only.

  • Pixel reference: What the pixel resolves at load time.

  • API keys: The one live key per workspace, and what it is for.