> 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/data-management.md).

# Data management

***

## Understanding data

Jimo knows almost nothing about your users on its own. It knows when it saw them, interactions with Jimo experiences and that is about it.

Everything else, their plan, their role, their signup date, whether they finished onboarding, comes from you. Data Management is where that data gets a name, a type and a shape.

<figure><img src="/files/UkGEFAVaJMSN8tCVLA0L" alt=""><figcaption></figcaption></figure>

**It is the layer that decides what you are able to say about a user.** Segments, targeting, personalization and measurement all read from it, and none of them can be sharper than it is.

### Where user data comes from

Six inlets, and knowing which one you are using tells you where to go when something looks wrong.

<figure><img src="/files/lzjCGVYSOj5soGY2vuwX" alt=""><figcaption></figcaption></figure>

| Source                       | What it brings                                | Where it is set up                                                                                                                                                                |
| ---------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **The Jimo SDK, natively**   | Identity, first seen, last activity, sessions | Automatic, once [the snippet runs](/docs/getting-started/installing-jimo.md)                                                                                                      |
| **The SDK, your own values** | Your custom attributes: plan, role, anything  | [Attributes](/docs/analyze/users-and-segments/data-management/attributes.md) + [Setup the segmentation](/docs/for-developers/for-developers/sdk-guides/setup-the-segmentation.md) |
| **Integrations**             | Fields synced from your CRM or analytics tool | [Integrations](/docs/integrations/integrations-list.md)                                                                                                                           |
| **CSV import**               | Users and custom attributes, in bulk          | [Imports](/docs/analyze/users-and-segments/data-management/imports.md)                                                                                                            |
| **Events**                   | What users actually did                       | [Success Tracker > Events](/docs/analyze/success-tracker/events.md)                                                                                                               |
| **Your team, by hand**       | Judgments no system holds                     | [Tags](/docs/analyze/users-and-segments/data-management/tags.md)                                                                                                                  |

#### Which inlet should you use?

Three of them can bring the same attribute in. Picking the wrong one is not fatal, but it costs maintenance.

| Situation                                               | Use                                                                                                                              |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| The value already lives in a tool Jimo connects to      | an [integration](/docs/integrations/integrations-list.md). Zero code, and it stays in sync on its own.                           |
| The value lives in your product, and changes            | the [SDK](/docs/for-developers/for-developers/sdk-guides/setup-the-segmentation.md). One implementation, then it updates itself. |
| You have a one-off list, or you are backfilling history | an [import](/docs/analyze/users-and-segments/data-management/imports.md). Fast, but frozen: nothing refreshes it.                |

{% hint style="warning" %}
**An import is a snapshot, not a sync.** Values land once and stay as they are. If the data behind them keeps changing, you will be re-importing forever. That is the signal you needed an integration or an SDK push instead.
{% endhint %}

#### Integrations are the shortcut most people miss

If your source of truth is already HubSpot, Salesforce, Segment.io, Amplitude, Mixpanel, PostHog or Heap, you do not need to write SDK calls for that data. Connect the tool and the fields arrive on their own, with the integration's logo in the **Source** column so you always know where a value came from.

See [Integration Setup](/docs/integrations/integration-setup.md) and the [full list](/docs/integrations/integrations-list.md).

#### Events are data too

An attribute says what a user **is**. An event says what a user **did**. Both are filterable, and behavioral rules are usually the ones worth building: *completed checkout at least 3 times in the last 30 days* is a better audience than *plan is Pro*.

Events live in the [Success Tracker](/docs/analyze/success-tracker.md) and show up in the segment builder under **No-Code Events**.

#### Data flows out, too

<figure><img src="/files/8imRWuclTpalg6Y5pQ9v" alt=""><figcaption></figcaption></figure>

Data Management is not a one-way street. What Jimo captures can leave:

* [**Exports**](/docs/analyze/users-and-segments/data-management/exports.md) take a segment's audience out as a CSV or JSON file, on demand
* [**Webhooks**](/docs/integrations/webhooks.md) push Jimo events to your systems in real time
* [**Events for analytics integrations**](/docs/integrations/events-for-analytics-integrations.md) send Jimo activity back to PostHog, Mixpanel, Amplitude
* [**Server-side events**](/docs/integrations/server-side-events.md) let your backend push events in

So the loop closes: your tools feed Jimo, Jimo feeds them back what happened.

#### Imports create attributes too

A CSV import does not only bring users in. Any column you map to a new field **creates the custom attribute**, without going through [Create a custom attribute](/docs/analyze/users-and-segments/data-management/attributes/create-a-custom-attribute.md).

Two doors to the same room. The difference is intent: the form is how you define an attribute you will keep feeding; the import is how you bring in data you already have. See [Imports](/docs/analyze/users-and-segments/data-management/imports.md).

### Attributes or tags?

<figure><img src="/files/aJtgB5fIjmFeU3nobiq7" alt=""><figcaption></figcaption></figure>

Two kinds of data, two very different lifecycles. The question comes up constantly, so here is the answer once.

* [**Attributes**](/docs/analyze/users-and-segments/data-management/attributes.md) **come from your systems.** You define them, your app or an integration sends values, and they update on their own. A user's `plan` is whatever your data last said it was.
* [**Tags**](/docs/analyze/users-and-segments/data-management/tags.md) **come from you.** Someone puts a label on a user by hand. Nothing updates it. Nothing removes it.

| Use an attribute when                  | Use a tag when                            |
| -------------------------------------- | ----------------------------------------- |
| The value lives in your product or CRM | The value lives in someone's head         |
| It changes on its own                  | It reflects a human judgment              |
| You need it on every user              | You need it on a handful                  |
| `plan`, `signup_date`, `role`          | "Beta tester", "Do not disturb", "Review" |

{% hint style="warning" %}
**Tags do not scale.** They are applied one user at a time and nothing keeps them fresh. If you are tagging dozens of users on a rule you could describe in a sentence, that rule belongs in a [segment](/docs/analyze/users-and-segments/audience/segments.md), not in a tag.
{% endhint %}

### Where this data comes back out

Everything defined here surfaces in four places. This is the payoff, and the reason the group exists.

<figure><img src="/files/NbALSwVuAEDCllxwtEXv" alt=""><figcaption></figcaption></figure>

* **Building audiences.**&#x20;

  The [Users filter](/docs/analyze/users-and-segments/audience/users/filter-users.md) and the [segment builder](/docs/analyze/users-and-segments/audience/segments/create-a-segment.md) read from it. The data type you picked decides which operators you get.
* **Targeting experiences.**&#x20;

  The [Who](/docs/publish/target-right-people-who.md) step reads the same picker, organized by the same sources.
* **Personalizing content.**&#x20;

  [Variables](/docs/analyze/users-and-segments/data-management/variables.md) inject real values into what users read: `Hello {firstName}`. Same data, different job. An attribute that exists but is empty for a user produces an empty variable, which is why coverage matters as much as definition.
* **Measuring.**&#x20;

  [Analytics](/docs/analyze/analytics.md) and the [Success Tracker](/docs/analyze/success-tracker.md) let you read results per population instead of in aggregate.

{% hint style="info" %}
**An attribute that never received a value is usable nowhere.** Not in filters, not in Who, not in variables. That is exactly what the **Pending** state on the [Attributes](/docs/analyze/users-and-segments/data-management/attributes.md) page tells you.
{% endhint %}

### The prerequisite behind all of it

Data attaches to a user. No identification, no persistent user, nothing to attach to. Anonymous visitors carry no attributes, no tags, and cannot be targeted by any of them.

If your data looks empty everywhere, start there: [Identify users](/docs/for-developers/for-developers/sdk-guides/identify-users.md).

### In this section

* [**Attributes**](/docs/analyze/users-and-segments/data-management/attributes.md): define the data points your app and your tools send
* [**Tags**](/docs/analyze/users-and-segments/data-management/tags.md): label users by hand
* [**Variables**](/docs/analyze/users-and-segments/data-management/variables.md): inject that data into what your users read
* [**Imports**](/docs/analyze/users-and-segments/data-management/imports.md): bring users and attributes in from a CSV
* [**Exports**](/docs/analyze/users-and-segments/data-management/exports.md): take a segment's audience out as CSV or JSON

### Related pages

* [Audience](/docs/analyze/users-and-segments/audience.md): what you build with this data
* [Setup the segmentation](/docs/for-developers/for-developers/sdk-guides/setup-the-segmentation.md): the SDK side
* [Integrations list](/docs/integrations/integrations-list.md): connect a source instead of writing code