Standard Attributes

The following attributes come "out-of-the-box" with Userflow. Use attributes in auto-start conditions, targeting/segmentation, and event tracking.

Where your attributes come from

Attributes reach Userflow two ways, and you don't have to choose between them.

Sent from your app. Any attribute you pass in userflow.identify(), userflow.group() or the API is created automatically the first time Userflow sees it. You don't need to create it first, and there's no list to add it to. Send plan_tier today and it's there today, ready to use in conditions and segments.

Created by hand. You can also create an attribute up front in Settings → Attributes, before anything has been sent. This is useful when you want the display name, description and data type set correctly from the start rather than inferred, or when you're building a segment against an attribute your app doesn't send yet.

If an attribute is already in your list, it's already been created. Seeing it there means Userflow has received it. You don't need to create it again, and creating a second one with the same name won't do anything useful.

Creating an attribute by hand

1. Select Settings > Attributes from the sidebar.

2. Click New attribute.

3. Complete the details, and click Create attribute.

You can change an attribute's display name and description at any time. The field key can't be changed once the attribute exists, so if you need a different key, send or create a new attribute and migrate to it.

Userflow Attributes

Can I see a user's operating system, browser or device?

Not as a standard attribute. Userflow does not collect the operating system, browser or device type, so there is nothing to target on or report against out of the box. The only values Userflow records about the user's environment are viewport_width and viewport_height, both event attributes.

Viewport width is often enough for the thing people are actually after. If you want a Flow to behave differently on a narrow screen, target on viewport_width rather than on device type.

If you need the operating system or browser itself, send it from your app as a custom attribute on identify(). It will appear in Userflow automatically, the same as any other attribute you send.

How date attributes populate

• First Seen / Last Seen (first_seen_at / last_seen_at) are set automatically by Userflow. First Seen is stamped the first time a user is identified; Last Seen updates on each later identify/interaction. You don't send these.

• Signed Up (signed_up_at) is supplied by you — pass it in your userflow.identify() call as an ISO 8601 datetime string (for example, new Date(...).toISOString()). If you don't send it, it stays empty.

Querying these dates

Use them anywhere attribute conditions appear — segments, auto-start conditions, and analytics filters — with operators like "is before / is after / in the last N days". Example: a segment of users last seen more than 30 days ago (useful for re-engagement) filters on last_seen_at "is before" 30 days ago.

Matching a date that recurs every year

Date operators compare against a fixed point in time, so they work for "signed up before March", not for "today is their birthday". A date of birth sits permanently in the past. Only its month and day matter, and there's no operator that reads just those.

To target a recurring date, send the comparison from your app as its own attribute rather than trying to derive it in Userflow:

• Simplest: send a boolean, for example is_birthday_today, set by your app when it runs its daily job. Then target on is_birthday_today is true. Your app already knows the date, so the logic sits where it's cheapest.

• More flexible: send the month and day as a string, for example birthday_md with a value of 03-14. You can then match a specific day, or a range, without recalculating anything daily.

Either way, remember the flow's frequency settings. An anniversary flow that can only start once will fire the first year and never again, so set it to start on a recurring basis if you want it every year. See Understanding flow dismiss, snooze, and restart.

How many users logged in?

This is the most common thing people use last_seen_at for, so it's worth being precise about what it does and doesn't tell you.

last_seen_at is not a login event. It records the last time Userflow saw the user, which means the last time Userflow.js loaded and userflow.identify() ran. That usually happens when someone logs in, but it also happens on every page load in an existing session, and it won't happen at all on pages where Userflow.js isn't installed. Treat it as "last active" rather than "last logged in".

To count active users:

1. Go to Users in the sidebar.

2. Click Add filter and choose Last Seen.

3. Set it to in the last N days, for example 7.

4. The user count on the filtered list is your answer. Save it as a segment if you want to track it over time.

To break that down by plan, region or any other attribute, build a Usage chart and add a Group By. See Chart Builder — Group By.

If you need actual logins, track them as an event instead. Send userflow.track('logged_in') from your app at sign-in, or set up a no-code event tracker on your login flow. An event gives you a real count of sign-ins, including several by the same person on the same day, which last_seen_at can't distinguish. See No-code event tracking.

Attribute limits

Userflow enforces three hard limits on attributes. They apply to user and company attributes alike.

List attributes are measured as a whole. The 5,000-character limit is the combined length of every item in the list, not the length of each item. A list of 200 codes at 30 characters each comes to 6,000 characters and will hit the limit, even though no single item is anywhere near it.

If you are modelling something that grows over time, such as a per-user entitlements or permissions list, size it against these numbers before you build on it.