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
Our user base has several years' experience using RTV. At first walk through using BBR this was the initial show stopper. Summary In order for our users to properly navigate the Events Panel they need to understand first what hit or page the Event is firing on, and have the Event ID exposed by the name (like RTV). Events, with all the report group and value detail, should default to *collapsed* view. What Page am I on?! Showing the page number in the Event Pane alleviates confusion as to where you are in the session, and if you have non visual hits or UI hits with Events they show in the same pane so you need to know where the Event fires. Why is Event ID important? We communicate by Event ID as well as educate our users to reference this in place of a name (that may change). This practice is due to our large number of Events and their optimal maintenance. Currently you open the Event Panel and all Event names are present (no number ID for easier reference and lookup in Event Selector or Event Editor). Who cares about collapsing/opening these? Events are all open / not collapsed. This means in order to see the list of events firing on a hit a user has to collapse each event, every time. This is repetitive and no shortcut command exists. (Carpal tunnel anyone?! Pain-in-my-hand "PIMH") They should default to collapsed as a best practice and a key command should work to toggle both the view and the collapse status. Thank you for your votes! We want to love BBR...
How will this idea be used?
The basic use case we have for replay is to check the user experience and then see what events we have firing on a hit to verify if we are tracking an issue and what report groups, etc. are collecting in current state. This is one of our best practices to maintain an efficient database by educating our users to use the data already collected and check report group values in order to more productively use Events in Report Builder and on Dashboards, as well as in Searches with dimensions and values. This practice is due to our large number of Events and their optimal maintenance.
We would like to use BBR as a primary replay solution with our primarily responsive code sites. In order to do this we need basic functionality of RTV that our users utilize daily included in the product.
|What is your industry?||Electronics|
|What is the idea priority?||High|
|Link to original RFE|