No two users are alike. A new sales rep needs a different onboarding flow than a senior engineer, and a free trial user should see different feature guides than a paying enterprise client. Showing everyone the same generic product tour is a surefire way to frustrate users and dilute your onboarding efforts.
The real power of product tours comes when you deliver the *right* tour to the *right* person at the *right* time. This isn't just about showing a tour on a specific URL; it's about understanding *who* is interacting with your application. That's where Beacon's `Beacon.identify()` method comes in. It's your critical link between your application's user data and your personalized tour experiences.
## Why `Beacon.identify()` is Non-Negotiable for Personalization
When you integrate Beacon using our SDK, you're embedding a small JavaScript snippet into your application. By default, Beacon knows very little about the user browsing your site. It can track page views, tour starts, and completions, but it can't tell you *who* is doing what beyond an anonymous session ID. This is fine for public-facing tours where everyone sees the same thing, but it's completely inadequate for targeted onboarding.
`Beacon.identify()` changes that. It allows you to tell Beacon who the current user is and what properties they have. Once identified, Beacon associates all subsequent tour activity (views, completions, feedback) with that specific user and their attributes. This isn't just good for analytics; it's essential for tailoring the tour experience itself.
## How to Use `Beacon.identify()`
The `identify` method is straightforward. You call it once a user is authenticated in your application, typically after they log in or when their session is established. It takes two arguments:
1. `userId` (string, required): A unique identifier for the user in your system. This should be consistent across sessions.
2. `properties` (object, optional): An object containing any custom attributes you want to associate with the user. This is where you'll pass roles, plan types, team IDs, or anything else you need for segmentation.
Here's a basic example:
```javascript
Beacon.identify('user-12345', {
name: 'Alice Smith',
email: 'alice@example.com',
role: 'admin',
plan: 'enterprise',
teamId: 'team-alpha'
});
```
{{IMAGE: A flowchart illustrating the `Beacon.identify()` lifecycle: User authentication -> Application calls `Beacon.identify(userId, { role: 'admin' })` -> Application checks user role -> Conditional `Beacon.startTour('admin_onboarding_tour_id')` or `Beacon.startTour('basic_user_tour_id')`.}}
### The "Why": Connecting Your App to Beacon's Data
When you call `identify`, you're essentially enriching Beacon's understanding of your user base. While Beacon itself doesn't have a built-in "target this tour to users with `role: 'admin'`" feature for *public* tours, this information empowers *your application* to make smart decisions. Your client-side code can now fetch the user's role from your backend (which is likely how `role: 'admin'` gets into the `identify` call in the first place), and then conditionally start specific tours.
## Scenario: Role-Based Onboarding
Let's say you have three main user roles in your SaaS product: `admin`, `manager`, and `member`. Each role has different primary tasks and features they need to learn first. Without `identify`, you'd struggle to ensure the right people see the right guides.
Here's how you'd set it up:
1. **Create Role-Specific Tours in Beacon:**
- `admin_onboarding_tour` (e.g., setting up new users, configuring integrations)
- `manager_onboarding_tour` (e.g., managing team projects, reviewing reports)
- `member_onboarding_tour` (e.g., creating tasks, collaborating on documents)
2. **Integrate** `Beacon.identify()` **in Your App**:When a user logs in, ensure their role is passed to `Beacon.identify()`:
```javascript
// Assume currentUser object comes from your authentication system
const currentUser = {
id: 'user-001',
email: 'john.doe@example.com',
role: 'manager' // This is the crucial part
};
Beacon.identify(currentUser.id, {
name: currentUser.name,
email: currentUser.email,
role: currentUser.role
});
```
3. **Conditionally Start Tours**:Now, with the user identified, your application can use their role to decide which tour to show. You might do this after the user lands on a specific dashboard, or as part of a general onboarding check.
```javascript
function startOnboardingTour(userRole) {
let tourId;
switch (userRole) {
case 'admin':
tourId = 'your_admin_onboarding_tour_id'; // Replace with actual ID from Beacon dashboard
break;
case 'manager':
tourId = 'your_manager_onboarding_tour_id';
break;
case 'member':
tourId = 'your_member_onboarding_tour_id';
break;
default:
console.log('No specific onboarding tour for this role.');
return;
}
// Check if the tour has already been completed or started recently
// Beacon.hasCompleted(tourId) can be useful here
Beacon.startTour(tourId);
}
// Call this function when the user's session is ready
startOnboardingTour(currentUser.role);
```
This approach ensures that an admin doesn't see a tour about creating tasks (which they might delegate), and a member isn't bombarded with setup instructions they can't even access. It’s about minimizing noise and maximizing relevance.
## Beyond Roles: Other Useful Attributes
`role` is just the beginning. Think about what other attributes are important for segmenting your users and personalizing their experience:
- `plan`: `free_trial`, `pro`, `enterprise`. Tailor feature tours based on what their subscription level unlocks.
- `account_id`: For B2B products, associate users with their company account. This can be critical for internal reporting.
- `acquisition_channel`: Did they come from a specific campaign? You might have a targeted welcome tour.
- `has_completed_step_X`: While Beacon tracks tour completion, your own application might have internal flags that can inform which Beacon tours to show next.
- `last_login`: Could be used to trigger 'what's new' tours for returning users.
The key is to pass anything that helps you make informed decisions about the user's journey. Don't go overboard, but be thoughtful about what truly drives differentiation in their product experience.
## A Note on Internal Training & Compliance
While the SDK `identify` is fantastic for segmenting *your product's* users, for internal staff training and compliance, Beacon offers dedicated features. If you're using Beacon to train your sales team on Salesforce or your support team on HubSpot, you can assign tours and courses to specific staff members or groups directly within the Beacon dashboard. This provides immutable audit evidence of completion, which is often a requirement for ISO 27001 or SOC 2. It’s a slightly different use case, but the principle of targeting the right content to the right person remains.
## When to Call `identify()` (and What Not To Do)
- **Call it early:** The best practice is to call `Beacon.identify()` as soon as the user is authenticated and their identity is known. This ensures all subsequent actions are correctly attributed.
- **Call it once per session (or on attribute change):** You typically don't need to call `identify` on every page load unless user attributes can change mid-session (e.g., they upgrade their plan). If attributes change, call it again to update Beacon's record.
- **Don't skip it for internal users:** Even for internal tools where you might think everyone's an 'admin', identifying users is crucial for understanding usage patterns and troubleshooting. Knowing `john.doe@yourcompany.com` completed the 'Q4 Expense Report Submission' tour helps you track adoption.
Failing to identify users means you're flying blind. You'll have tour analytics, but you won't know *who* completed them, or if your personalized logic is actually working for the right segments. It's a foundational step that, once set up, quietly makes all your other product tour efforts far more effective.
Ready to get specific with your product tours? Start building and experimenting with `Beacon.identify()` today.
Build your first personalized tour for free at https://dobeacon.com/signup
Product ToursOnboardingSDKPersonalizationUser Segmentation
Personalizing Product Tours: How to Use Beacon.identify() for Role-Based Onboarding
Stop showing generic product tours. Learn how Beacon.identify() lets you deliver personalized onboarding and feature guides based on user roles, segments, and other attributes, ensuring every user gets the most relevant experience.
Engineering Team·
Try DoBeacon free
Add guided tours to any website in under 5 minutes. No annual contract, no per-MAU pricing.
Get started free →