Custom attributes

Alongside the details HeyThula collects, your site can send its own — a plan name, a signup date, how many projects someone has. They appear on the contact's profile.

Sending them

Attributes go with the identity details your site already passes to the widget, as name-and-value pairs. They're sent on the same call that identifies a signed-in user — see Identifying logged-in users.

Every value is stored as text and displayed as sent, so format dates and numbers the way you want them read.

What's worth sending

The test is whether it would change how you answer.

Usually worth it: plan or tier, account age, whether they're in a trial, their role in their own organisation, the count of whatever your product counts.

Usually not: internal IDs nobody will read, anything already visible, anything that changes every few minutes.

A profile with five useful attributes gets read. One with thirty gets skimmed past, which makes the five useful ones worse than if they'd been alone.

Don't send anything sensitive

Attributes are visible to everyone on your team. Don't send payment details, passwords, tokens, or anything you wouldn't put in a shared spreadsheet.

They're context for a support conversation, not a data store.

Keeping them current

Attributes update when your site next identifies that person. Someone who upgraded but hasn't returned to your site still shows their old plan, so treat values as "as of their last visit" rather than live.

The Last seen date on the profile tells you how stale that might be.

Anonymous visitors

Attributes need an identified user — there's nobody to attach them to otherwise. Anonymous visitors show only what HeyThula can observe.