Skip to main content
Without identification, a response records the answers but not the person who gave them. When your page passes its signed-in user to Usertick.identify(), every response from that person carries your user ID. The inbox then shows who answered, responses link to your contacts, and integrations name the same person in your other tools.

​
Identify the signed-in user

After your page knows who is signed in, call identify() on every page load. With the script tag, Usertick exists once the Usertick code has loaded, so the call waits for the page’s load event when it isn’t there yet.
The widget uses the identity in two places:
  • On the page, the sign-in state and trait rules and the variant conditions read it, and every survey on the page is checked again right away.
  • When the visitor submits a response, the response carries the user ID, the traits, the hash and an anonymous ID for this browser. Page views and surveys that only open carry none of it, and nothing is sent before Submit.
The traits email, name and company become the person’s email, name and company in the inbox. The anonymous ID is a random ID the widget creates for each browser. It is kept in a first-party cookie, or in localStorage when cookies are blocked. The user ID, the traits and the hash are kept in localStorage until logout() or reset(). A response that couldn’t be sent yet waits in the browser for up to 7 days with the identity it had. Cookies and consent lists every key the widget stores. The widget drops anything past these limits and logs a warning in the browser console. It also logs a warning and ignores the value when the user ID isn’t a string, when the hash is passed as the third argument itself instead of as { hash }, and when a new hash isn’t 64 hex characters, in which case the stored hash stays. Later calls with the same ID merge their traits into the stored ones and keep the hash, so Usertick.identify("user_123", { seats: 15 }) updates one trait. A call with a different user’s ID starts with no traits and no hash, so one person’s traits never carry over to the next.

​
Sign the user out

When the user signs out, call logout():
logout() forgets the ID, the traits and the hash, and identify(null) does the same. The next response is anonymous and carries a new anonymous ID, so on a shared computer the next person’s answers are never tied to this user. Integrations never name a person by the anonymous ID. Analytics tools such as Segment, Mixpanel and Amplitude receive only responses that carry your user ID from identify(), so an anonymous response never reaches them. The list of surveys this browser has seen is kept, so a survey that was already answered doesn’t come back. While nobody is signed in, logout() keeps the anonymous ID, so the call is safe on every anonymous page load.

​
Reset for testing

reset() forgets everything the widget remembers in this browser: the surveys it has seen, the visit counters, the anonymous ID and the identify() record with its hash. Responses waiting to be sent are kept. The method is meant for testing; to sign someone out, use logout().

​
Turn it off

Identity is sent by default, and two switches turn it off:
  • Send user identity with responses, on each site in Settings → Sites. When it is off, no response from that site’s widget carries a user ID, traits, a hash or an anonymous ID, whatever the page passes to identify(), and Usertick drops any identity that reaches it from that site anyway. The sign-in state and trait rules on the page keep working. Link, QR and email surveys have no site, so this switch doesn’t affect them.
  • Anonymous responses, on each survey, under Privacy on the Settings tab of the editor’s Survey step. When it is on, the survey’s responses carry no user ID, traits or anonymous ID, on your website and on the survey’s link, QR and email pages.
Answers to a Contact question are kept with either switch, because they are answers. An email send gives each person their own link, so a response from it stays tied to the contact it was sent to.

​
What the inbox shows

A response opened in the inbox shows who answered:
  • the user ID, name, email and company,
  • a mark when a hash proved the identity,
  • the traits, marked when they didn’t come signed,
  • what the person entered in a Contact question,
  • the contact the response is linked to.
The email shown follows one order: the contact an email send went to, then an email from identify() that a hash proved, then the email entered in a Contact question, then an email from identify() without a valid hash. An answer to any other question is never taken as the person’s email, even when it is an email address. The inbox also filters by who answered (Identified, Verified, Not verified or Anonymous), by one user ID, by trait values such as plan is pro (up to 10, all of which must match), and by whether the response is linked to a contact. Grouped by who answered, the list uses the same words. Exports carry a Verified column next to the email. Usertick links each new response to a contact in Email → Contacts when it can, and the first match wins:
  1. The contact an email send went to.
  2. A verified user ID that matches a contact’s External ID.
  3. A verified email from identify() that matches a contact’s email. When that contact has no external ID yet, it gets the user ID.
  4. The email entered in a Contact question that matches a contact’s email.
When nothing matches, Usertick creates the contact:
  • A verified identity with an email creates a contact with that email, the name and the user ID as its external ID.
  • Otherwise, an email entered in a Contact question creates a contact with that email and name.
  • An identity without a valid hash never creates or changes a contact.
A name only fills a contact’s empty name and never replaces one. Answers someone gave anonymously before signing in aren’t merged into the contact. Each contact shows its external ID and every response linked to it, from the website, links and email, with the reason for the link. An external ID can also be set by hand, and one external ID belongs to one contact.

​
Verify who the visitor is

Anyone can call identify() from the browser console with any ID. To prove that the ID is genuine, your server computes a hash of the user ID with a secret key, and the page passes it as the third argument:
The hash is computed once per user and never expires. Verification is optional and available on every plan. Verify your users explains when you need it, how to compute the hash in seven languages, the verification modes and how to rotate the key. A link survey takes the same identity from its address. When your system builds the link for a person, add uid=user_123&uh=HASH, with the hash your server computes for that user ID. The page reads both, removes them from the address bar, and sends them with the response, and a reload of the same tab keeps them. A link carries no traits, and uid without uh arrives unverified. Without them, the page sends only its own anonymous ID, and a survey with Anonymous responses on sends neither. See Verify link survey readers.

​
Integrations

Tools that track people receive your user ID, the email or both, and never the anonymous ID. Mixpanel, Amplitude and Segment need your user ID, Klaviyo and Mailchimp need the email, and Customer.io, Braze, Iterable and Intercom take either. A response without what the tool needs is skipped, and the workflow’s Activity gives the reason. In Monitor and Enforced, an email that came without a valid hash never reaches a CRM, a mailing list or an event tool. See how a tool knows who answered. Google Analytics, FullStory and UXCam get no identity at all. Their event carries the survey ID, the response ID and the score. See Google Analytics, FullStory and UXCam. A workflow can also check who answered in its conditions: identified or not, verified, linked to a contact, the user ID, the email or a trait. Its messages can show the same values.

​
Privacy

  • Only with a response. The user ID, the traits and the hash leave the page only when the visitor submits a response, and never when either switch is off.
  • A guard against personal data in the wrong place. The email trait must be one email address, or it is dropped. The name and every other trait value are dropped when they hold an email address, a card number, an IBAN or a phone number written as one (with a leading +, parentheses or three or more groups). Plain digit strings, dates and IPv4 addresses are kept, so IDs and timestamps pass. The user ID isn’t checked, because many sites use the email as the ID.
  • The AI never sees who answered. The AI that reads responses gets no user ID, traits, email or name. From a Contact question it gets only the message, never the name, email, phone or company.
  • Erase a person. To delete everything one person sent, call the API with their email or your user ID. See Erase personal data.