Watson Marketing Ideas

Submit new product ideas for Campaign, Interact, Marketing Operations, Marketing Platform, Campaign Managed Hosted, interact Managed Hosted, Marketing Operations Managed Hosted, Digital Analytics, Tealeaf, Universal Behavior Exchange, Watson Customer Experience Analytics, Watson Marketing Insights, Watson Content Hub, Web Content Manager and WebSphere Portal solutions. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed.

Connect with your peers and IBM experts on the Watson Marketing and Commerce Community

Submit ideas for other Watson Customer Engagement Products:

•  Watson Campaign Automation
Watson Commerce
Watson Supply Chain

Shared Sessions - Long Term User Storage Archive

This is a proposal to have a User session storage network (USSN, as compared to LSSN). When a user is replaying a session, they can have a longer term session storage, similar to "Export as TLA". This is where they are able to COPY a session from LSSN over to their LSSN, where they can give it a name, and share it with other users (to make it private or public). Links to this session will NO LONGER EXPIRE as the normal Canister Trim, and can be used for problem tickets, etc, legal and more.

SECURE: As the sessions are still stored in the Tealeaf system, they are still SECURE for authentication. They can even share the same on demand privacy rules by users, for proper data redaction or decryption.

EASY: Much easier than extracting a TLA. It can be stored in a user's storage section, where they can give the sessions names, tags, or other info so they can organize them.

MANAGEABLE: On saving them, they MUST give the sessions an expiration date, so the sessions will be cleaned up. Systems administration can have a report on USSN storage size, trending, and see how old the oldest sessions are and who has them. They can initiate cleanup processes if users have too much stored - or ask those users to clean up their storage.

VALUE: Admins can see how much data those people are storing, and if they are actively being used for replay. If they ARE then easy to use that as a value add metric for people using this in the system.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Mar 12 2018
  • Uncommitted Candidate
How will this idea be used?

Almost every user will use this to create a "bank" of these sessions.

What is your industry? Banking
What is the idea priority? High
DeveloperWorks ID
RTC ID
Link to original RFE
  • Attach files
  • Admin
    Rob Hain commented
    02 Aug 20:13

    Question: How should this feature be user-managed? Do individuals / groups need specific permission to perform this type of storing/archiving? Alternatively, if a user has permission to view a session, they can have the ability to store/archive?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    12 Aug 22:11

    I would suggest having a new user group, much like Event Admin where if they are added to that group, then they have permissions to save sessions.  This will help for Reveal customers so they might not want to give CustOps that access.  I'd have to think what user group name might be contextually sound.

    SECOND: I would recommend adding the USSN archive capability to the cxConnect API that fetches a replay link.  The easiest way would be to add parameters that say "archiveSession=true&archiveExpireDate=2019-08-20".  This would give internal tools the capability to auto-archive sessions, like a triage ticketing system.  Use case is someone reports a customer X had an issue on date Y - script can auto ping Tealeaf with that session attribute parameter (login_id) and tell it to archive that session and get it's link to attach it to the issue ticket it creates.

    No, just because a user can view a session does not mean they can archive it.  Plus if we have the ability above in the API, we can use other ticketing systems to centrally manage this (triage system) so the script itself can save sessions with tickets, or people granted access in the TL Portal can manually do it (issue investigators).

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    12 Aug 22:14

    I would attach some level of meta-data to the sessions if possible.  That would make for valuable TL_STATISTICS usage data:

    1. Ticket # if a JIRA or other ticket number was assigned.

    2. Who saved it

    3. Expiration Date requested

    4. Storage amount of session + index size (so we can SUM and monitor total storage)

    5. Access/Replay stats of these sessions including "Last Time Viewed", "Total Views".   Admins will use this to determine what sessions should be trimmed, and we can pull the user IDs to notify them their sessions will be deleted.