Enable account registered signals in the Connect web library

The account registered signal captures when a user successfully completes account registration on your website or app. Use this signal to identify new contacts at the moment of sign-up, trigger personalised onboarding journeys, and measure registration conversion rates.

Typical use cases across business domains:

Retail: New account creation confirmation
Travel: Loyalty or rewards programme signup
Banking/Insurance: New profile or account creation confirmation

Availability: Pro, Premium and Ultimate

Implementation considerations

Registration confirmation challenge

The account registered signal must fire after registration is confirmed — not when the user submits the form. Until the server confirms the account was created successfully, you cannot be certain the registration completed.

Recommended approach: Fire the signal on the registration confirmation or welcome screen. If your flow redirects after server-side confirmation, trigger the signal on page load of that destination rather than on form submit.

Data collection strategy

Plan your implementation around these stages:

Registration form — Capture the registration method (email, SSO, passwordless), SSO provider if applicable, and registration source (the page or campaign that initiated sign-up).
Confirmation — Confirm success server-side, then store the captured data in session storage.
Confirmation page — Retrieve stored data, build the signal, send it, then clean up session storage.

Contact mapping

Any signal can be mapped to a contact. Use the audience object to provide a customer ID — a contact key or an addressable attribute (email or phone number). You can provide several identification records in the same signal — for example, a contact key and an email address. For details on how Connect processes identification records, see How behavior signals are processed in Connect.

Several sources of identification are available:

User identification stored in browser cookies
Temporary session-based storage
Persistent client-side storage
Data layer (for example, Google Tag Manager dataLayer)
URL parameters passed during navigation
Login API monitoring (capture identifier during successful authentication)

If none of these options are available, work with your development team to make the identifier accessible to the Connect library.

⚠️
Important:
We recommend attaching identifiers to as many signals as possible. However, if an identifier is missing, the system falls back on other signals from the same user session in order to identify the website visitor.

Configuration

Method

TLT.logSignal(signalObject)

Sends the signal to the Acoustic Connect endpoint as a JSON object. The Connect library must be initialized before calling this method.

Signal structure

Top-level fields

audience: Object — Key-value pairs mapping the signal to a contact and optionally updating contact attributes. Keys must match attribute names exactly as they appear in Connect, including capitalization and spacing.
category: String — Valid value: Behavior.
consent: Object — Consent preferences to update for the contact. At least one of the following channel fields is required: email, sms, or whatsapp.
description: String — Description of the signal.
effect: String — Describes the effect of the signal on engagement. Valid values: negative, positive. Use positive for account registrations.
name: String — Name to differentiate this signal from others (for example, "Account registered from website"). Max length: 256 chars.
signalType (required): String — Valid value: accountRegistered

Signal content fields

mfaEnabled: Boolean — Whether MFA was enabled during registration.
registrationMethod (required): String — Method used to register. Examples: email, sso, passwordless.
registrationSource : String — Page or campaign that initiated registration. Examples: homepage, checkout, promotion.
ssoProvider : String — SSO provider when registrationMethod is "sso". Examples: google, facebook, apple.

📘
Note:
If any required field is missing or invalid, the entire signal will be discarded. Optional fields enhance the signal but won't prevent processing if omitted or invalid.

Audience object

Create a flat key-value object where each key is a contact attribute name and each value is the new value for that attribute. Include at least one identifier for contact mapping (recommended) and any number of additional pairs to update other contact attributes.

⚠️
Important:
The audience object must be a flat key-value object — not an array of name/value pairs. If the format doesn't match, the contact will not be created or updated.

Attribute names must match exactly how they appear in Connect — including capitalization and spacing. To look up attribute names, use the Contact attributes query.

Basic example

// Initialize the Connect library
if (window.TLT) {
  TLT.initPremium({
    appKey: "APP_KEY",
    postUrl: "COLLECTOR_URL",
    callback: function() {
      const signal = {
        // Required fields
        signalType: "accountRegistered",
        registrationMethod: "sso",
        // Optional fields
        category: "Behavior",
        name: "accountRegistered from website",
        ssoProvider: "google",
        registrationSource: "checkout",
        mfaEnabled: true,
        effect: "positive",
        // Contact mapping and profile enrichment
        audience: {
          "Email": "[email protected]"
        }
      };
      // Send the signal
      TLT.logSignal(signal);
    }
  });
}

Complete implementation example

This example fires on the registration confirmation page. The registration method, SSO provider, and email are retrieved from session storage, where they were stored during the registration flow.

// Store registration data during the form flow (on form submit or SSO callback)
function storeRegistrationData(method, provider, source, email) {
  sessionStorage.setItem("registrationMethod", method);
  if (provider) sessionStorage.setItem("ssoProvider", provider);
  if (source) sessionStorage.setItem("registrationSource", source);
  if (email) sessionStorage.setItem("userEmail", email);
}

// Initialize the Connect library
if (window.TLT) {
  TLT.initPremium({
    appKey: "APP_KEY",
    postUrl: "COLLECTOR_URL",
    callback: function() {

      // Fire on registration confirmation or welcome page
      const isConfirmationPage =
        window.location.href.includes("/registration-confirmation") ||
        window.location.href.includes("/welcome");

      if (isConfirmationPage) {
        const registrationMethod = sessionStorage.getItem("registrationMethod") || "email";
        const ssoProvider = sessionStorage.getItem("ssoProvider");
        const registrationSource = sessionStorage.getItem("registrationSource");
        const email = sessionStorage.getItem("userEmail");

        const signal = {
          signalType: "accountRegistered",
          name: "Account registered from website",
          category: "Behavior",
          registrationMethod: registrationMethod,
          effect: "positive"
        };

        // Include SSO provider only when registrationMethod is sso
        if (registrationMethod === "sso" && ssoProvider) {
          signal.ssoProvider = ssoProvider;
        }

        // Include registration source if available
        if (registrationSource) {
          signal.registrationSource = registrationSource;
        }

        // Map signal to contact
        if (email) {
          signal.audience = {
            "Email": email
          };
        }

        // Optional: log for debugging
        console.log("accountRegistered signal:", JSON.stringify(signal, null, 2));

        // Send the signal
        TLT.logSignal(signal);

        // Clean up session storage after sending
        sessionStorage.removeItem("registrationMethod");
        sessionStorage.removeItem("ssoProvider");
        sessionStorage.removeItem("registrationSource");
        sessionStorage.removeItem("userEmail");
      }
    }
  });
}

Best practices

Fire on confirmation, not form submit. Firing on the form submit risks sending the signal before the server confirms the registration was successful. Always fire on the confirmation screen or post-redirect destination.
Store data before the redirect. Registration method, SSO provider, and source are often only available during the form interaction. Store them in session storage before any redirect so they are accessible on the confirmation page.
Send the signal once. Add a check or clean up session storage immediately after sending to prevent duplicate signals if the confirmation page is refreshed.
Use consistent registrationMethod values. Standardise values across your implementation (email, sso, passwordless) so segmentation and reporting are reliable.
Always include an identifier. Pass the user's email in the audience object wherever possible. Without an identifier, the signal cannot be linked to a contact unless other signals in the same session contain one.
Pass registrationSource for attribution. If registrations originate from multiple pages or campaigns, use registrationSource to attribute sign-ups accurately in Connect.

Troubleshooting

Signal not firing after registration?

Confirm the Connect library is initialized before logSignal is called — signals sent before initialization completes will fail silently.
Verify the signal fires on the confirmation or welcome screen, not on the form submit.
Check that registrationMethod is included — it is required. If missing, the entire signal is discarded.
Use console.log() to verify the signal object before sending.

Signal firing multiple times?

Verify session storage is cleaned up immediately after the signal fires.
Check that page refresh or SPA route change logic isn't re-triggering the confirmation page handler.
Consider adding a sent flag to session storage to prevent duplicate sends.

Registration data missing on confirmation page?

Confirm data is being stored to session storage on the form or SSO callback page.
Verify session storage persists across the redirect (check browser settings and private browsing behaviour).
Test that the retrieval logic is reading the correct session storage keys.

Contact not created or updated?

Verify the audience field is a flat key-value object — if the format doesn't match, the contact will not be created or updated
Confirm attribute key names match exactly how they appear in Connect — including capitalization and spacing
Confirm the attribute value type matches the field type defined in Connect (text, number, Boolean, or date)