Dream Big: How Jive Analytics Should Work

Version 4

    Background

    I've been working with the Jive Analytics module since it launched. I have, therefore, acquired a deep understanding of both what it does and what I wish it would do. This document is intended to crowd-source, within this group, what we dream Jive analytics would do. Please contribute! Let's dream big with a positive attitude about what could be possible

    Before Everything Else: Data Integrity

    It should not need to be stated, but my experience tells me it must be explicitly and emphatically noted: all data must be precisely accurate. This means it must be recorded and structured carefully, so that whatever way it is extracted, it will correctly represent what really exists or took place in the Jive instance.

    Where

    I think the first fundamental point to make is that analytics should be embedded into the Jive user experience. There's still a place for a powerful back-end where admins can truly mine the data, but the emphasis should be on surfacing analytics within the system. The argument made in establishing this group, after all, is that analytics should be actionable, and the people who want and need to take action aren't data analysts: they are community managers, line of business managers, and anyone member of the community who feels inspired to help make the community better.

    In Excel

    Let's face it, the most dominant analysis tool business people have available is Excel. As much as possible of the analysis should NOT take place in Excel, but in Jive itself, yet exporting data to Excel is an excellent way to provide flexibile and creative uses of the data that had not yet been considered. In fact, a great way to integrate with Excel would be through an add-in, as Omniture does, for example (but make it work better and more reliably, please!). Allow us to create data blocks in Excel that are linked to the datamart via the add-in so that we can automate the process of pulling in updated data and eliminate the manual step of copying and pasting.

    Places

    Analytics should be an integral part of all Jive places. Each place is potentially a community, and each community needs data to understand how effectively it is operating. There should be an Analytics content type with a tab where all of the reports live for each container.

    Embed Anywhere

    Reports should be as simple to embed in any document, blog, discussion or poll as images are. There should also be flexible, interactive widgets dedicated to reports for overview pages.

    How

    How you view, interact with, publish, share and create reports should be intuitive. The vast majority of reports should be so simple and easy to use that members of the community can quickly and easily understand, explain and act upon them.

     

    Creating new reports should not require SQL knowledge or experience. There should be ways to use SQL and query tools to tap into the data warehouse, as well, but that should not be the primary way that reports get created.

    When

    Time periods for reporting and analytics should utilize timestamps down to the hour. Weekly reports should display the date of the first day of the week, not the week number. It should be simple to at data hourly, daily, weekly, monthly, quarterly and yearly. Reports should be able to be scheduled to update and publish (so that followers are alerted) on any of these time frames (maybe hourly is overkill for that).

    What

    What should be represented is the biggest question, but this is more than just a list of reports.

    Self-Updating

    I should be able to look at a report and always see the latest results if I choose that option (rather than have to launch an update manually).

    Interactive

    I should be able to modify the report easily as an end-user interacting with it, to change the key parameters of it (e.g., time frame, level of detail displayed).

    Surface Every Kind of User Activity

    If an option or activity is important enough for Jive to build into the system, then it's important enough to be reported on. That should be the mindset both in developing analytics and every time features are added or modified in the system. For example, if people can microblog, we should be able to report on microblogging activity. If they can "like," rate and comment on their ratings of content, we should be able to report on all of that activity.

     

    Think about reporting and analytics in everything you do. That's what community managers have to do: they want to encourage behavior, so they need ways to measure how effective their efforts have been. And it's the community managers who will make your customers successful, as you well know, so support them with all of the data that they could ever desire.

    Break-Out Every Which Way

    Every profile field should be a way that data can be broken out. Managers/reporting relationships, too. Every container. For hierarchical container relationships, allow rolling up to any level (e.g., parent spaces and child spaces, projects within a space or group). Content types within containers.

    List of Reports

    All are welcome to add to this, but please be precise. Don't just add the title of a report you have in mind. List exactly what data should be in it and any details about how you think it should be presented, including standard options that should be built-in.

    Activity Segmentation Level Reports

    See elsewhere in this group for details on ASL reports. Functioning version available in UBM's Business Objects account.

    New Member Engagement Report

    Described in Ted's Actionable Analytics presentation. Functioning version available in UBM's Business Objects account.