Identify users & attributes

identify gives the SDK a user ID and a set of attributes. The SDK calls them traits; the Mobile app tab calls them user attributes. They do two jobs:

Targeting. Audience rules such as “plan is pro” or “identified users only” are checked against them on the device.
Responses. They fill the form’s hidden fields with the same names, so each response shows who answered.

Identify a user

Call identify when you know who the user is: after login or sign-up, or at app start when a session already exists.

Responsly.shared.identify(userId: "user-123", traits: [
    "plan": "pro",
    "seats": 5,
    "beta": true,
    "signed_up": .date(Date()),
])

Values are of type ResponslyValue. Literals convert automatically. Wrap variables: .string(plan), .number(Double(seats)), .bool(isBeta), .date(signedUpAt). To convert a loosely typed [String: Any] dictionary, use ResponslyValue.traits(from:).

Responsly.identify("user-123", mapOf(
    "plan" to "pro",
    "seats" to 5,
    "beta" to true,
    "signed_up" to Date(),
))

Responsly.identify('user-123', {
  plan: 'pro',
  seats: 5,
  beta: true,
  signed_up: new Date(),
})

Responsly.identify('user-123', traits: {
  'plan': 'pro',
  'seats': 5,
  'beta': true,
  'signed_up': DateTime.now(),
});

ResponslySDK.Identify("user-123", new Dictionary<string, object>
{
    { "plan", "pro" },
    { "level", 12 },
    { "beta", true },
});

What happens:

The user ID is set and the attributes are merged into the ones already stored.
Both are saved on the device and survive app restarts. You do not have to call identify on every launch, and calling it again with the same values is harmless.
The user now counts as identified for the audience rule identified / not identified users.

Use a stable ID from your own system, the same one on every device and platform. Avoid email addresses or other personal data as the ID.

Update attributes

setAttributes merges attributes without touching the user ID. Use it when something changes, or to describe a user who is not logged in. A null value removes an attribute.

Responsly.shared.setAttributes(["plan": "team", "beta": nil])

Responsly.setAttributes(mapOf("plan" to "team", "beta" to null))

Responsly.setAttributes({ plan: 'team', beta: null })

Responsly.setAttributes({'plan': 'team', 'beta': null});

ResponslySDK.SetAttributes(new Dictionary<string, object> { { "plan", "team" }, { "beta", null } });

Attributes set this way are used for targeting even when no user ID is set. The user still counts as not identified until you call identify.

Value types

Type	Example	Notes
String	`"pro"`	”Equals” and “contains” rules ignore case.
Number	`5`, `49.9`	Integers and decimals are the same type.
Boolean	`true`
Date	a platform date object	Stored and compared in UTC with seconds precision, as `2026-11-10T12:00:00Z`.

Per platform, a date is Date wrapped as .date(…) in Swift, java.util.Date in Kotlin, Date in JavaScript and DateTime in Dart. In Unity, pass the date as an ISO 8601 UTC string ("2026-11-10T12:00:00Z"); it compares the same way.

Other types (arrays, nested objects) are not supported. Attribute names are matched exactly, so use the same spelling in the app, in audience rules and in hidden-field names.

How attributes reach the response

When a survey is shown, the SDK hands the user ID and attributes to it. They are saved through the form’s hidden fields:

The form has a hidden field named	It is filled with
`user_id`	The user ID from `identify`
`plan`	The `plan` attribute
any other attribute name	That attribute

A value is stored only when the form has a hidden field with that name. See Hidden fields.

Log out

Call reset when the user logs out. It clears the user ID, attributes and the rest of the SDK’s local state, and closes a visible survey. The SDK stays initialized.

Responsly.shared.reset()

Responsly.reset()

Responsly.reset()

Responsly.reset();

ResponslySDK.Reset();

Because identify merges, switching users without reset would leave the previous user’s attributes in place. Always reset, then identify the next user.

reset also clears event counts and the record of which surveys this device has shown. A survey with frequency once can therefore appear again after a logout. What reset keeps and clears is listed in Privacy & data.

Before `initialize`

identify and setAttributes are safe to call before initialize and from any thread. The calls are remembered and applied, in order, when the SDK starts.