Data management
Where your user data comes from, how it is shaped, and everywhere Jimo uses it. Nothing you target or personalize is better than the data underneath it.
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.
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.
The SDK, your own values
Your custom attributes: plan, role, anything
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.
The value already lives in a tool Jimo connects to
an integration. Zero code, and it stays in sync on its own.
The value lives in your product, and changes
the SDK. One implementation, then it updates itself.
You have a one-off list, or you are backfilling history
an import. Fast, but frozen: nothing refreshes it.
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.
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 and the full list.
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 and show up in the segment builder under No-Code Events.
Data flows out, too
Data Management is not a one-way street. What Jimo captures can leave:
Exports take a segment's audience out as a CSV or JSON file, on demand
Webhooks push Jimo events to your systems in real time
Events for analytics integrations send Jimo activity back to PostHog, Mixpanel, Amplitude
Server-side events 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.
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.
Attributes or tags?
Two kinds of data, two very different lifecycles. The question comes up constantly, so here is the answer once.
Attributes come from your systems. You define them, your app or an integration sends values, and they update on their own. A user's
planis whatever your data last said it was.Tags come from you. Someone puts a label on a user by hand. Nothing updates it. Nothing removes it.
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"
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, not in a tag.
Where this data comes back out
Everything defined here surfaces in four places. This is the payoff, and the reason the group exists.
Building audiences.
The Users filter and the segment builder read from it. The data type you picked decides which operators you get.
Targeting experiences.
The Who step reads the same picker, organized by the same sources.
Personalizing content.
Variables 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.
Analytics and the Success Tracker let you read results per population instead of in aggregate.
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 page tells you.
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.
In this section
Attributes: define the data points your app and your tools send
Tags: label users by hand
Variables: inject that data into what your users read
Imports: bring users and attributes in from a CSV
Exports: take a segment's audience out as CSV or JSON
Related pages
Audience: what you build with this data
Setup the segmentation: the SDK side
Integrations list: connect a source instead of writing code
Last updated