setUserId()
wf.setUserId(userDomain, userId)
Identify a visitor with a known user ID. This client-side API tells Webflow who the visitor is so that off-site conversions can be attributed to their session.
Call before sending server-side events
You must pass the user ID to Webflow via wf.setUserId() before you can report any related off-site conversion events via the server-side API.
Syntax
Parameters
-
userDomain (required):
string— A label identifying the system where your user data lives (e.g.,salesforce,marketo,applicationId). This helps distinguish between different ID sources. -
userId (required):
string— The unique identifier for the user in your system. This must match theuserIdyou send in the server-side API request.
Example
When to call setUserId
Call wf.setUserId() as soon as you know the visitor’s identity. Common scenarios include:
- After a user logs in
- When a user submits a form with identifying information
- When you can match the visitor to a record in your CRM or database
The user ID must be set before the visitor leaves your site. Once set, Webflow can attribute any subsequent off-site conversions to this visitor’s session. The user ID persists for the duration of the session, which ends after 30 minutes of inactivity or a 24-hour maximum timeout.
Choosing a user ID
The value you use for the ID depends on the system where your user data lives. Common sources include:
- In-house databases
- Salesforce contact IDs
- Marketo lead IDs
- Application or account IDs
Choose an ID that’s available on both the client side (your website) and server side (your backend systems) so you can match conversions correctly.
Protect personally identifiable information
The userId sent to Webflow should not contain personally identifiable information (PII). If your identifiers include any of the following, use a one-way hash (such as SHA-256) before sending:
Do not include information like:
- Names
- Email addresses
- Phone numbers
- Any combination of data that could identify an individual
Your organization is responsible for implementing appropriate hashing before calling this API.
Example: Credit card application
In this example, a visitor fills out a form to apply for a credit card. The actual conversion (approval) happens later, after a review process.
Later, when the application is approved, your backend sends the conversion event using the same userDomain and userId via the server-side API.
Returns
This method doesn’t return a value. The user ID is stored and associated with the visitor’s session.
FAQs
Can I call setUserId multiple times?
Yes, you can call wf.setUserId() multiple times with different userDomain values if you have multiple ID systems. Each call associates the visitor with that specific domain and ID combination.
What if the visitor clears their cookies?
If the visitor clears their cookies or uses a different device, they’ll be treated as a new visitor. You’ll need to call wf.setUserId() again to identify them.