> For the complete documentation index, see [llms.txt](https://help.usejimo.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.usejimo.com/docs/analyze/users-and-segments/audience.md). # Audience Every experience you publish asks the same question before it appears: **should this person see this?** Audience is where that question gets an answer. It is not a feature you use once, it is the layer that sits underneath everything Jimo shows to anyone. ## User, audience, segment
Three words that get used interchangeably, and should not be. | Term | What it means | | ------------ | ------------------------------------------------------------------------------------- | | **User** | One person Jimo has detected. Anonymous until your app identifies them. | | **Audience** | The set of people a given experience will show to. Computed at runtime, never stored. | | **Segment** | A saved, named, reusable set of rules. A building block for audiences. | The distinction that matters most: **a segment is a definition, not a list.** It holds rules, not people. Jimo re-evaluates it continuously, so a user who stops matching leaves on their own, with nothing to update by hand. That is why a segment's count moves without anyone touching it. The segment is not broken. Your users changed. {% hint style="info" %} **One exception.** A segment created from a [CSV import](/docs/analyze/users-and-segments/data-management/imports.md) starts from a fixed list of users. It behaves like a list, not like a rule, and it does not update itself. {% endhint %} ## Where your audiences actually get used
A segment on its own does nothing. It becomes useful the moment something points at it. That happens in more places than most people realize. ### Targeting an experience The obvious one. Every experience has a **Who** step where you pick who sees it. See [Target right people (Who)](/docs/publish/target-right-people-who.md). This covers every type: tours, modals, surveys, banners, hints, checklists, the Resource Center, the Agent. ### Making hints appear and disappear [Hints](/docs/experiences/hints.md) have no trigger and no recurrence: they show as long as the user matches. Which means **their audience is their only on/off switch**. A hint that should stop showing once someone has done the thing is a hint whose audience excludes people who did the thing. Audience is not just who sees a hint. It is the whole lifecycle of a hint. ### Targeting changelog posts The [Changelog](/docs/experiences/changelog.md) frame itself is global: it is there on every page where the snippet runs. What you target is **each post inside it**. Same segments, different granularity. ### Splitting an audience for a test An [A/B test](/docs/analyze/a-b-test.md) splits the audience of a tour between versions. The audience defines the population, the test divides it. ### Measuring [Analytics](/docs/analyze/analytics.md) and the [Success Tracker](/docs/analyze/success-tracker.md) let you read results for a population rather than for everyone. A segment is what makes "did this work for our Pro users" a question you can answer. ### Personalizing what people see Inside the [Resource Center](/docs/experiences/resource-center.md), action blocks can be filtered by segment or by attribute. So the same Resource Center shows a different set of shortcuts depending on who opens it: your admins get the settings links, your trial users get the upgrade path, and neither sees the other's. This is the one place where an audience does not decide **whether** something appears, but **what it contains**. Worth knowing, because it is easy to build five Resource Centers targeted at five segments when one filtered Resource Center would do. ## Two ways to build one **From** [**Users**](/docs/analyze/users-and-segments/audience/users.md)**.** You filter the list to explore, you see who matches, and you save the filter as a segment if it deserves to exist. This is the path when you are still figuring out who you are looking for. **From** [**Segments**](/docs/analyze/users-and-segments/audience/segments.md)**.** You go straight to the builder because you already know. This is the path when you are setting up something you will reuse. Both end in the same object. The second is just the first without the exploration. ### On-the-fly segments You can also skip the library and define rules that live inside one experience only. Useful once, awkward twice. If you find yourself rebuilding the same on-the-fly rules across experiences, that is a segment asking to be born. Save it: the next person will find it, and you will not have four slightly different definitions of "power users" scattered across your workspace. ## What audiences are made of Rules are built on [attributes](/docs/analyze/users-and-segments/data-management/attributes.md), [tags](/docs/analyze/users-and-segments/data-management/tags.md), events and experience history. All of that is defined one level up, in [Data Management](/docs/analyze/users-and-segments/data-management.md). The relationship is simple and worth internalizing: **Data Management decides what you can say. Audience decides what you say with it.** ### In this section * [**Users**](/docs/analyze/users-and-segments/audience/users.md): browse, filter and inspect every user Jimo detected * [**Segments**](/docs/analyze/users-and-segments/audience/segments.md): build, find and manage reusable audiences ### Related pages * [Data Management](/docs/analyze/users-and-segments/data-management.md): the data your rules are built on * [Target right people (Who)](/docs/publish/target-right-people-who.md): where audiences are applied * [Identify users](/docs/for-developers/for-developers/sdk-guides/identify-users.md): the prerequisite to targeting anyone by your own data