Passing custom data about a visitor

Talkfront knows what your website tells it. Everything an agent needs that only your application knows has to be handed over.

The fields

Some are recognised, because almost everyone has them: name, email, phone, company, role, title, plan, reference, language, address, city, country.

Talkfront('identify', {
  id: 'usr_1042',
  name: 'Marcus Webb',
  email: 'marcus@webbjoinery.co.uk',
  company: 'Webb Joinery',
  plan: 'Trade account',
});

Anything else goes under custom:

Talkfront('set', {
  custom: {
    'Orders this year': '14',
    'Last order': 'HL-40118',
    'Credit terms': '30 days',
  },
});

Custom keys are shown to your agents exactly as you write them, so write them as a label rather than a variable name. Last order reads; last_order_ref does not.

Choose the things that change the answer

The temptation is to send everything. Resist it, for two reasons.

The practical one: a panel with thirty fields is a panel nobody reads, and the one fact that mattered is lost among twenty-nine that did not.

The other one: everything you send is personal data you now hold, that you have to be able to explain, produce on request and delete. A field nobody has ever looked at is pure liability.

A good test is whether it would change what an agent says. Plan, account status and the last order usually do. A user’s internal id usually does not.

Updating it mid-session

set changes details for someone already identified, without starting again. Use it when something changes while they are on the page: they upgrade, or they add an order.

Talkfront('set', { plan: 'Trade account' });

When they sign out

Call reset, or their details stay attached to the next person to use that browser. Identify, set and reset covers which to call when.

Do not put secrets in it

This runs in the browser and the visitor can read every value. Nothing here is hidden from them, so no tokens, no internal notes, and nothing you would not show them on a page.

Last updated 22 September 2026.