Enable logged in signals in the Connect web library

The logged in signal captures when a user successfully authenticates on your website or app. Use this signal to identify active contacts at the moment of login, trigger re-engagement or loyalty journeys, and track authentication patterns across your audience.

Typical use cases across business domains:

Retail: Post-login redirect to account dashboard or homepage
Travel: Return to loyalty account or booking history
Banking/Insurance: Access to secured account portal after authentication

Availability: Pro, Premium and Ultimate

Implementation considerations

Authentication timing challenge

The logged in signal must fire after authentication is confirmed — not when the user submits the login form. For SSO and OAuth flows, the signal cannot fire until after the callback completes and the session is established server-side.

Recommended approach: Fire the signal on the post-authentication redirect or dashboard load. For SSO and OAuth flows, trigger the signal on the page the user lands on after the callback — not during the external provider interaction.

Data collection strategy

Plan your implementation around these stages:

Login form or SSO initiation — Capture the login method (email, password, SSO, passwordless) and SSO provider if applicable.
Authentication confirmation — Confirm successful authentication server-side, then store the captured data in session storage.
Post-login destination 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 login signals.
name: String - Name to differentiate this signal from others (for example, "Logged in from website"). Max length: 256 chars.
signalType (required): String - Valid value: loggedIn.

Signal content fields

loginMethod (required): String - Authentication method used. Examples: email, password, passwordless, sso.
mfaMethod: String - MFA method used when mfaUsed is true. Examples: SMS, email, TOTP, biometric.
mfaUsed: Boolean - Whether MFA was used during login.
ssoProvider: String - SSO provider when loginMethod is "sso". Examples: Google, Microsoft, Facebook.

📘
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

if (window.TLT) {
  TLT.initPremium({
    appKey: "APP_KEY",
    postUrl: "COLLECTOR_URL",
    callback: function() {
      const signal = {
        signalType: "loggedIn",
        name: "Logged in from website",
        category: "Behavior",
        loginMethod: "email",
        effect: "positive",
        audience: {
          "Email": "[email protected]"
        }
      };
      TLT.logSignal(signal);
    }
  });
}

Complete implementation example

This example fires on the post-authentication dashboard page. The login method, SSO provider, MFA status, and email are retrieved from session storage, where they were stored during the authentication flow.

// Store auth data during login or SSO callback
function storeAuthData(method, provider, mfaUsed, mfaMethod, email) {
  sessionStorage.setItem("loginMethod", method);
  if (provider) sessionStorage.setItem("ssoProvider", provider);
  sessionStorage.setItem("mfaUsed", mfaUsed ? "true" : "false");
  if (mfaMethod) sessionStorage.setItem("mfaMethod", mfaMethod);
  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 post-authentication destination page
      const isPostLoginPage =
        window.location.href.includes("/dashboard") ||
        window.location.href.includes("/account") ||
        window.location.href.includes("/home");

      if (isPostLoginPage) {
        const loginMethod = sessionStorage.getItem("loginMethod") || "email";
        const ssoProvider = sessionStorage.getItem("ssoProvider");
        const mfaUsed = sessionStorage.getItem("mfaUsed") === "true";
        const mfaMethod = sessionStorage.getItem("mfaMethod");
        const email = sessionStorage.getItem("userEmail");

        const signal = {
          signalType: "loggedIn",
          name: "Logged in from website",
          category: "Behavior",
          loginMethod: loginMethod,
          mfaUsed: mfaUsed,
          effect: "positive"
        };

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

        // Include MFA method only when MFA was used
        if (mfaUsed && mfaMethod) {
          signal.mfaMethod = mfaMethod;
        }

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

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

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

        // Clean up session storage after sending
        sessionStorage.removeItem("loginMethod");
        sessionStorage.removeItem("ssoProvider");
        sessionStorage.removeItem("mfaUsed");
        sessionStorage.removeItem("mfaMethod");
        sessionStorage.removeItem("userEmail");
      }
    }
  });
}

Best practices

Fire on the post-login destination, not form submit. Firing on form submit risks sending the signal before the server confirms authentication. Always fire on the redirect destination or dashboard load.
Handle SSO and OAuth callbacks correctly. For SSO flows, the login method and provider are only available during the external authentication step. Store them in session storage before the redirect so they are accessible on the post-login page.
Send the signal once per login. Add a check or clean up session storage immediately after sending to prevent duplicate signals if the dashboard page is refreshed.
Use consistent loginMethod values. Standardise values across your implementation (email, password, sso, passwordless) so segmentation and authentication analytics are reliable.
Always include an identifier. Pass the user's email or contact key in the audience object. Login is one of the most reliable moments to confirm a contact's identity — take advantage of it.
Track MFA when applicable. If your platform supports MFA, passing mfaUsed and mfaMethod enables security-based segmentation and helps identify contacts who are using stronger authentication.

Troubleshooting

Signal not firing after login?

Confirm the Connect library is initialized before logSignal is called — signals sent before initialization completes will fail silently.
Verify the signal fires on the post-authentication redirect or dashboard load, not on the login form submit.
For SSO flows, confirm the signal fires after the OAuth callback completes and the session is established.
Check that loginMethod is present — 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 post-login page handler.
Consider adding a sent flag to session storage to prevent duplicate sends.

Auth data missing on post-login page?

Confirm data is being stored to session storage during the login or SSO callback step.
Verify session storage persists across the redirect (check browser settings and private browsing behaviour).
For OAuth flows, confirm the callback handler stores the data before completing the redirect.

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).