Expand my Community achievements bar.

Join us for the next Community Q&A Coffee Break on Tuesday April 23, 2024 with Eric Matisoff, Principal Evangelist, Analytics & Data Science, who will join us to discuss all the big news and announcements from Summit 2024!

ActivityMap - Report Suite Selection


Level 2


Hello ActivityMap developers!


When I use the ActivityMap plugin on a given page, it only lets me select the report suite(s) currently populated in s.account variable on the page.  I understand the logic behind this probably has something to do with ensuring users only select the correct report suite(s) for a given page, and it seemed easiest to ensure this by referencing s.account on a given page.

However, In practice, this does not work in practice for a lot of our clients. A lot of our clients dynamically populate s.account based on a variety of things, such as logged in user type, or IP address.  So for example visitors on their network (employees) will pop an internal rsid instead of the normal visitor rsid.  But since ActivityMap only allows you to select what s.account pops with, many of our clients are unable to make use of it for the data they actually want to look at 99% of the time - visitor activity (vs. activity for their own internal rsid).

One "workaround" to this is before activating ActivityMap, open up the js console and assign the desired rsid to s.account. Then open run ActivityMap, and it will allow to select the desired rsid.  But this is not a good solution for several reasons.  First, it is a process that has to be repeated on every page view: exit ActivityMap, update s.account, log back into ActivityMap. Second and more importantly, setting s.account to another rsid affects data collection on the page.  Anything that triggers an AA call on the page (e.g. a link click) would send data to that rsid instead of where it normally goes (internal rsid).


So, my suggestion is to have ActivityMap list all available rsids for a given account.  You can have ActivityMap flag/highlight/whatever which rsid(s) are currently in s.account to make it easier for people who benefit from how it currently works.  But also allow for ActivityMap to select any rsid so that users with scenarios such as the above can actually use ActivityMap without shady workarounds.