Back to Blog

Caveman Adoption Tenet: Simple adoption metrics

By Eric Eaton
Updated March 22, 2024

Rulers.png Measuring adoption is an area where a lot of times we overthink things. We track the wrong things (like page hits and unique visitors for a site) and build solutions that are way more complicated than we needed in order to tell our adoption story.

Don’t build the proverbial solar-powered
rocket launcher, with GPS and cup-holders —
when all you really need is a club.

So in the spirit of strategic simplicity, what can we measure easily about adoption for our own purposes and for management? This will vary some from organization to organization, depending on your goals, but there are a couple of things that are at the core of SharePoint and / or Office 365 user adoption that I think everyone should track.

These things:

  • are easy to do
  • are very relevant to how broadly and deeply these platforms are getting embedded into everyday life
  • tell a very intuitive story to management
  • simplify life-cycle governance going forward

If you’re looking for a big dramatic reveal – you’ll be disappointed. These are so simple they seem obvious, but it amazes me how many times organizations either don’t use them at all or opt to do something harder and less helpful.

Little thing 1: The count of total site collections / O365 groups

Assuming you’re allowing people to create sites / O365 groups self-serve (or at least request them through a form), you should track how many you have. This is a REALLY important barometer of how deeply the are taking root in your users' everyday life. As users work more in existing sites, they should begin to want separate groups or sites for different teams and projects.

Little thing 2: The count of unique site owners for those site collections / groups

This shows how broadly SharePoint infection rate is spreading through your user base. As users get more comfortable using someone else’s site, they start to find reasons to request their own sites. If they don’t like using SharePoint – they’ll only go there when someone else forces them to do so.

How do you measure those things?

These two things can be pretty easily tracked together in a SharePoint list. The data typically comes from one of a couple of possible sources.

If you have published a site request form for your users to get new sites or groups (InfoPath or PowerApps, for instance), that form should ultimately post the request into a master sites list – along with the name of the submitter, any other owner(s) they specify in the form, and the date the site was created.

If you’re using the native self-serve features in Office 365, then you’ll have to go about things a little differently. Most admins should be able to create PowerShell scripts that query REST and / or CSOM to find info for existing sites / groups and use it to populate a central list. Even power users can do this kind of thing using Nintex Workflow and its assortment of ‘call a web service’ actions pointed at SharePoint native REST services.

Ideally, once you initially create and populate this list – you start managing the data there rather than overwriting the list every time you run your script. This allows you to use that list to do some simple site life-cycle management tasks that make a big difference. (I’ll cover that scenario a little more in my next article, about Caveman Adoption Tenet 3.) Of course, you then need a way to append new site / group records as those sites get created. You could either adapt your PowerShell script to do incremental updates, or…

The new Site Designs framework released to preview in December, 2017 allows you to create JSON ‘scripts’ that are applied to a specific site type and run after each site is created. One of the actions possible in that script is to run a Flow (which could, of course, add an item to your central site master list). Lots of cool wrinkles with this - don't get me started... I look forward to doing great things with this new feature.

Whatever way you opt to collect this data, once you have it you can create charts that show the growth of sites and site owners over time. Either Excel or Access (or a myriad of other reporting tools) can slice and dice the data to easily filter down to unique owners. Admittedly, these two metrics are not a complete picture of user adoption, but it’s a great start. They tell a pretty clear story even to non-technical people.

Little thing 3: Office 365 built-in adoption stuff

The Office 365 Admin Center has a nice, simple dashboard of usage / adoption charts. This usage report also includes a tile that allows you to enable a more powerful Power BI content pack that retrieves usage data on SharePoint, OneDrive, Exchange, Yammer, Skype and displays powerful visualizations of that data – including drill-down capabilities.

These two options are both easy to get and great for seeing trends at more of a macro level across these 5 primary tools. You’ll find data here that helps you set and / or track your own adoption goals over time (comparisons of total vs active site and files, enabled vs active users, total vs returning users, types of actions per product…). I think it’s perhaps a little overwhelming to share as a whole with someone who isn’t technical and / or familiar with Office 365, but individual charts from here are good fuel that you might share up the management chain to make your point.

There is a little setup to do from the Office 365 Admin Center if you want to use the Power BI part. You have to go to Reports > Usage, and then enable the 'Office 365 Adoption Preview' feature (see the red arrows above). There will be a bit of a waiting period while the system collects the data to make it available to Power BI, but then you can find and add the ‘Office 365 Adoption Preview’ Content Pack from the Power BI home page.

More advanced stuff that also has value

We mentioned the idea of using PowerShell or even workflow to query REST and / or CSOM earlier. This is a very powerful tool to have in the toolbox, and can be used to look for a number of more advanced and detailed types of usage and customization. Microsoft does this kind of thing with PowerShell through their FastTrack program to help organizations prepare for migration of SharePoint to the cloud. A friend of mine, Janet Taylor, previously took this same idea and used Nintex and SharePoint's REST services to create a really cool dashboard about sites and their customizations. We used that for all sorts of analysis regarding everyday adoption and even migration prep. The sky is the limit here, but here are some ideas of things I’ve seen queried and used productively to infer adoption of various features:

  • Customized list forms (InfoPath)
  • Form libraries
  • Data connection libraries
  • No-code workflows
  • External lists / content types
  • Per feature activation instances
  • Large lists
  • Page counts
  • Last update date
  • Overall size

What you want to look for will obviously change depending on what your adoption goals are, and how specifically you want to track them. Beware of the solar-powered rocket launcher here. It’s easy to get addicted to this powerful tool and make things way more complicated than what you really need to measure adoption rates. Pick and choose things that answer important questions you already have, and remember that not every stat needs to be updated regularly. For things that aren't core metrics, a one-off snapshot of where you are currently is helpful and can always be compared with another snapshot later. The more complex you make things - the longer it takes to implement, the harder it is to troubleshoot, the easier it is to get side-tracked, and the more likely you are never going to get it rolling.

What have you found helpful for tracking user adoption in SharePoint and Office 365?




Fuel Employee Success

Boost employee productivity with VisualSP's easy-to-use platform for in-app guidance
Get Started Free
Table of Contents