Send account updated signals (web

The account updated signal captures when a change to an existing account is saved on your website or app. Use this signal to confirm changes with the contact, send security alerts after a password or MFA change, flag unusual identifier changes, and record deletion or deactivation requests.

The contact can make the change themselves, or a customer service agent can make it for them.

Typical use cases across business domains:

• Retail: Updated delivery address or communication preferences
• Travel: Updated passport details or loyalty profile
• Banking/Insurance: Changed contact details, password or MFA settings

Availability: Pro, Premium and Ultimate

Implementation considerations

Save confirmation challenge

The account updated signal must fire after the change is saved — not when the user submits the form. Until the server confirms the update, you cannot be certain the change was applied.

Recommended approach: Fire the signal when your app receives a successful save response, or on the confirmation screen that follows it. If your flow redirects after the save, trigger the signal on page load of that destination.

What triggers the signal

Send an account updated signal when:

• A user edits their profile, contact details, address or preferences
• A customer service agent updates the account on the user's behalf
• A user changes their password or MFA settings
• A user requests to delete or deactivate their account
• An identifier, such as the email address or phone number, changes

Use account registered for the first account creation, and account updated for every change after that.

Data collection strategy

Plan your implementation around these stages:

1. Account form — Capture what changed (updateType), where it changed (updateSource), and whether an identifier changed.
2. Save — Confirm the change server-side. If the confirmation page is a separate page, store the captured data in session storage.
3. Confirmation — 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.

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.
• name: String — Name to differentiate this signal from others (for example, "Account updated from website"). Max length: 256 chars.
• signalType (required): String — Valid value: accountUpdated

Signal content fields

• updateType (required): String — The kind of change. Examples: profile, contactDetails, address, preferences, password-changed, delete.
• confirmationRequired: Boolean — Whether the user needs to confirm the change, for example through a verification email.
• identifierChanged: Boolean — Whether an identifier, such as the email address or phone number, changed.
• mfaEnabled: Boolean — Whether MFA is on after the change.
• reason: String — Why the account was updated. Examples: email address changed, Moved, Too Frequent.
• ssoProvider: String — SSO provider used for the change. Examples: google, okta.
• updateMethod: String — How the change was made. Examples: self, phone, chat.
• updateSource: String — Where the change was made. Examples: profile-information, account-settings, preference-center, address-book, security-center, csr.

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.

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: "accountUpdated",
        updateType: "contactDetails",
        // Optional fields
        category: "Behavior",
        name: "Account updated from website",
        updateSource: "profile-information",
        updateMethod: "self",
        identifierChanged: false,
        confirmationRequired: false,
        effect: "positive",
        // Contact mapping and profile enrichment
        audience: {
          "Email": "[email protected]"
        }
      };
      // Send the signal
      TLT.logSignal(signal);
    }
  });
}

Complete implementation example

This example fires when the account settings form saves successfully. The update type and source come from the form that was submitted.

// Build and send an account updated signal after a successful save
function sendAccountUpdatedSignal(update) {
  if (!window.TLT) return;

  const signal = {
    signalType: "accountUpdated",
    name: "Account updated from website",
    category: "Behavior",
    updateType: update.type,
    updateMethod: "self",
    effect: "positive"
  };

  // Include optional fields only when they're known
  if (update.source) signal.updateSource = update.source;
  if (typeof update.identifierChanged === "boolean") {
    signal.identifierChanged = update.identifierChanged;
  }
  if (typeof update.confirmationRequired === "boolean") {
    signal.confirmationRequired = update.confirmationRequired;
  }
  if (typeof update.mfaEnabled === "boolean") {
    signal.mfaEnabled = update.mfaEnabled;
  }
  if (update.reason) signal.reason = update.reason;

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

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

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

// Initialize the Connect library
if (window.TLT) {
  TLT.initPremium({
    appKey: "APP_KEY",
    postUrl: "COLLECTOR_URL",
    callback: function() {
      const form = document.querySelector("#account-settings-form");
      if (!form) return;

      form.addEventListener("submit", async function(event) {
        event.preventDefault();

        // Save the change first
        const response = await fetch(form.action, {
          method: "POST",
          body: new FormData(form)
        });

        // Fire only after the server confirms the save
        if (response.ok) {
          sendAccountUpdatedSignal({
            type: form.dataset.updateType,      // for example "address"
            source: "account-settings",
            identifierChanged: false,
            confirmationRequired: false,
            email: form.dataset.userEmail
          });
        }
      });
    }
  });
}

Best practices

1. Fire on a successful save, not form submit. Firing on submit risks sending the signal for a change that failed or was rejected.
2. Use consistent updateType and updateSource values. Standardise them across your website, app and customer service tools so segments match every source.
3. Send true or false for Boolean fields. identifierChanged, confirmationRequired and mfaEnabled are Boolean.
4. Set updateSource to csr for agent changes. This separates changes your customer service team makes from changes the user makes.
5. 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.

Troubleshooting

Signal not firing after an update?

• Confirm the Connect library is initialized before logSignal is called — signals sent before initialization completes will fail silently.
• Verify the signal fires after the save response, not on the form submit.
• Check that updateType 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?

• Check that retries, double clicks or SPA route changes aren't calling the send function more than once.
• If you store update data in session storage, remove it immediately after the signal fires.

Segments not matching Boolean fields?

• Send true or false, not strings such as "yes". Connect might accept a string without an error, but segments might not read it as you expect.

Duplicate contact after an email change?

• If the signal's audience contains only the new email, Connect can't match it to the existing contact and creates a new one.

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)