Who/Where/When

No, it's not a new rom-com. Who/Where/When are the principles underpinning CommandBar's user targeting system. Targeting refers to making sure the right experience show for the right users at the right time.

Proper targeting is a core principle behind how CommandBar makes user experience non-annoying. Nothing is worse for a user than seeing a pop-up that is completely irrelevant to them and interrupts their flow.

This is one of those philosophical docs (if you've read our docs before you're probably no stranger to these).

Nudge vs Assist

There are two types of experiences in CommandBar:

• Nudge: these experiences show proactively without an explicit user trigger.
• Assist: these experiences respond directly to user intent.

For Nudge experiences, targeting dictates when the experience appears to users.

For Assist experiences, targeting dictates what possible responses a user could see in response to their query (search or chat).

Who

Who refers to which users have access to the experience. The easiest way to define who conditions is via Audiences. You can use the following properties to create Who targeting rules:

Condition	Description	Example use case
User property	Target users based on their associated properties. These properties can be set and updated by calling boot.	Showing a nudge to users who are reaching the end of their trial. For this example, you'd need to pass the 'Trial end date' for each user.
First seen	When CommandBar first saw the user, measured in days relative to present. This is calculated across devices (not just the current browser).	Show a nudge to users who are relatively new in their journey in your product. For example, you might restrict a nudge announcing a “Product Basics” webinar to your new users.
Last seen	When CommandBar last saw the user, measured in days relative to present. This is calculated across devices (not just the current browser).	Users who haven’t been seen in a while are more likely to be disengaged and candidates for churn. You could show users who haven’t showed up in a while a nudge that encourages them to meet with a customer success team member. Or you could show them a Checklist to reintroduce them to your app’s coolest features.
Nudge interactions	Whether a user viewed, completed, or dismissed a specific nudge. In this context, viewed means “was shown”, regardless of whether they completed, dismissed, or didn’t interact with.	Nudge interaction rules are useful when you’re creating a nudge that is related to a nudge you may have shown in the past. Let’s say you want to show off a feature which you believe to be correlated with conversions, but you’ve created nudges related to this feature in the past. Proactively nudging users toward a feature multiple times is annoying. You can avoid doing these by targeting your new nudge only to users who hadn’t seen the old one.
Checklist interactions	Whether a user viewed, completed, or dismissed a specific Checklist. In this context, viewed means “was shown”, regardless of whether they interacted with the Checklist in any way.	Similarly, to nudge interaction conditions, Checklist interaction conditions are useful when you’re creating an experience that is related to another experience. For example, let’s say you want to target your most engaged users with a survey to understand what they love about your product. You could approximate “most engaged” users by targeting only those users who completed your onboarding Checklist.

Where

Where refers to the pages where the experience is relevant. There are two ways to determine where conditions:

By URL

You can target URLs specifically, or construct conditions that could match multiple URLs using different types of rules (”includes”, “does not include”, “starts with”) as well as regular expressions. We recommend using URL rules when possible, because they’re easiest to get right. There are two URL conditions you can use:

• Current URL Path - any part after the domain (app.commandbar.com/nudges/1234)
  • commonly used for targeting pages
• Current Domain - any part of the domain (app.commandbar.com/nudges/1234)
  • often used for targeting products or customers

By element presence

By the presence of an element: sometimes, digital products change “state” without a corresponding change in a URL. For example, says a user opens up a modal and you want to show a product tour that explains the modal. Often, opening up a modal doesn’t trigger a URL change.

To target a tour like this, you can show an experience only when a specific element appears on the page.

When

This is the critical piece that differentiates meh targeting from perfect targeting. Often, showing a nudge experience to a user as soon as who and where conditions are satisfied results in a suboptimal experience. For example, the user might be trying to get something done quickly. As soon as they open up a page to do that thing, they are confronted with a product tour that invites them for a quick tour. How annoying is that?

There are a few ways to configure When conditions.

What triggers are available for nudges?

Out-of-the-box, CommandBar includes several types of triggers: smart, custom, and basic.

Smart Triggers

• Smart delay: show the experience when the user is not actively doing something else in your product. This prevents the experience getting in the user's way, resulting in an immediate close out.
• Rage click: rage clicks capture frustration. This trigger is an especially good time to throw a survey or launch a nudge that redirects the users' frustration to a help article, walkthrough video, or to Copilot or HelpHub.
• User confusion: there are certain behavioral patterns that indicate the user is lost. This trigger is a great time to show walkthrough content or direct the user to an assistance experience.

Custom Triggers

• By event: events are used to tell CommandBar when certain, well, events, happen in the user’s session. For example, you could send an event to CommandBar when the end-user interacts with a specific feature or creates new content. Events can be sent via integrations (Segment is one of the most popular for this person) or manually using the CommandBar SDK.

note

Events sent to CommandBar with the CommandBar SDK are sent one-way to CommandBar only. You'll still want to send the event to your own analytics trackers, as CommandBar will not forward these events, even when you use addEventSubscriber or one of our outbound analytics integrations.

Basic Triggers

• None: why have a None trigger? Does it do nothing? Exactly! The none trigger means this nudge won't trigger on its own. It can be still triggered by other experiences though, like Copilot suggestions, Magic tour links, or even checklists and nudges.
• After time on page: useful for waiting just a little bit of extra time before displaying a nudge
• Immediately: display as soon as the page loads

Start Page

If your nudge experience uses Where targeting and you want to trigger it from another experience, it is strongly recommended to set up a Start Page. Otherwise, your nudge will not show up if the user isn't already on a page that matches the Where targeting. With a start page, we will teleport users to the right place when they trigger the nudge.

There are various ways to trigger a nudge from another experience, including but far from limited to Copilot, the HelpHub additional resources section, and Checklist item CTAs.

Let's take a look at a quick example:

1. I'd like a Product Tour nudge that guides users through our new /shop page, and I know this tour will only work on pages that include /shop in the URL.
2. To make sure the nudge only displays when a user is on pages that include /shop, I've set a Current URL Path condition that includes /shop.
3. I'd also like to display this nudge via a Checklist, but the checklist could be displayed on any page. If a user starts the nudge while on a page that's not in the shop, it won't work!
4. To fix that, I can add a Start Page that will teleport users to the right page before the nudge displays!