You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the function main, for each method invocation, setOrUpdateIntercomSettings is called which pulls settings from window.intercomSettings and overrides any values defined within with the appropriate dataLayer variables from GTM.
var settings = copyFromWindow('intercomSettings') || {};
for (var k in data_attrs) {
settings[k] = data_attrs[k];
}
if (data.custom_attributes) {
var custom_attrs = makeTableMap(data.custom_attributes, 'attr_key', 'attr_value') || {};
for (k in custom_attrs) {
settings[k] = custom_attrs[k];
}
}
setInWindow('intercomSettings', settings, true);
return settings;
}
Following the intercom documentation, it is suggested that the best practice for managing sign-in/sign-out in an SPA is to call invoke shutdown, optionally followed by a bootwithout any settings aside from the app id
However, following the instructions while using this tag will result in the "clean" signed-out boot actually containing all the user details of the prior logged in state.
This is further problematic if you imagine an SPA where on initial boot for sign-up (or sign-in) we populate only a subset of fields (let's say user hash & email), particularly if used in an environment where a single individual manages multiple user accounts, or where individuals share computers.
I sign up as user A, boot with partial data & navigate multiple pages and end up with a complete intercom profile.
I sign out.
I sign up as user B, boot with my new partial data, merged with any fields that remained in window.intercomSettings.
I open intercom to find data from user A, e.g. the greeting.
Currently our workaround is to add a sequential clean-up tag after our Intercom shutdown tag which executes delete window.intercomSettings and only then perform the "clean" sign-out boot.
Most likely, an invocation of boot should not use intercomSettings - only the dataLayer variables supplied to the tag, or more fundamentally, intercomSettings should arguably be deleted on shutdown but that would be beyond the scope of this repository.
The text was updated successfully, but these errors were encountered:
In the function main, for each method invocation, setOrUpdateIntercomSettings is called which pulls settings from
window.intercomSettings
and overrides any values defined within with the appropriate dataLayer variables from GTM.official-gtm-tag/template.tpl
Lines 898 to 907 in 37fb391
official-gtm-tag/template.tpl
Lines 731 to 748 in 37fb391
Following the intercom documentation, it is suggested that the best practice for managing sign-in/sign-out in an SPA is to call invoke
shutdown
, optionally followed by aboot
without any settings aside from the app idHowever, following the instructions while using this tag will result in the "clean" signed-out
boot
actually containing all the user details of the prior logged in state.This is further problematic if you imagine an SPA where on initial boot for sign-up (or sign-in) we populate only a subset of fields (let's say user hash & email), particularly if used in an environment where a single individual manages multiple user accounts, or where individuals share computers.
Currently our workaround is to add a sequential clean-up tag after our Intercom
shutdown
tag which executesdelete window.intercomSettings
and only then perform the "clean" sign-outboot
.Most likely, an invocation of boot should not use intercomSettings - only the dataLayer variables supplied to the tag, or more fundamentally, intercomSettings should arguably be deleted on shutdown but that would be beyond the scope of this repository.
The text was updated successfully, but these errors were encountered: