We’re rolling out a new edition of the NGAGE Analytics platform. And there’s a lot that hasn’t changed.
NGAGE is still the behavioral analytics platform that’s built using the Microsoft BI stack. Meaning SQL Server Integration Services (SSIS) for ETL. SQL Server for the Data Warehouse. SQL Server Analysis Server (SSAS) for the multi-dimensional Cube and, until recently, Microsoft PerformancePoint Services (PPS) for reporting.
And, while there have been some important ‘back end’ architectural changes (e.g. NGAGE is now a standalone Windows/REST Service and no longer a SharePoint Service Application) the core data we capture hasn’t changed much either. Our Cube still maintains the same rich profile of every authenticated user + a complete definition of the topology of the SharePoint farm/the target application + a detailed, time-stamped record of every user interaction with that environment.

And, while there have been some important ‘back end’ architectural changes (e.g. NGAGE is now a standalone Windows/REST Service and no longer a SharePoint Service Application) the core data we capture hasn’t changed much either. Our Cube still maintains the same rich profile of every authenticated user + a complete definition of the topology of the SharePoint farm/the target application + a detailed, time-stamped record of every user interaction with that environment.
This was no migration ... It took months, not weeks.
Without doubt, the biggest change has been the move from PPS to Power BI as its reporting layer.
It seems strange now, but it started off as something we just had to do: Microsoft are investing massively in Power BI; they haven’t invested in PPS since 2013.
Sure, we were a little bit excited because we knew Power BI could make NGAGE a visually much more exciting solution. And it has. But once we started, we realized this was no migration. This would have to be a complete transformation of the user experience; a totally new approach to how we surfaced and provided secondary access to our data. It took months not weeks.
The first challenge was to somehow retain the strengths of the PPS offering.
What was special about our PPS + Cube approach was that you could create insights ‘on the fly’ that could answer even the most obtuse questions very quickly. Meaning the individual PPS reports (grids, bar charts, line graphs) we shipped with were almost never ‘the answer’ – because they didn’t need to be. Because in PPS I can right-click on any metric in any report and go into Drill Down or Decomposition Tree mode. These give me the ability to explore the underlying data without any predetermination. Example? I can start with a total, global SharePoint Page View count for 2017 and, within a few clicks, see (and export) the User Name, Browser Version, IP Address and/or Job Title of any visitor who hit the Home Page of a specific SharePoint Site at around 12 noon last Tuesday. Which is kind of cool. The bad news? If I want to persist that report, I can’t unless I’m a PPS technical specialist. And who is? Every time I want the answer to that question (I know I wouldn’t but…) I have to make those clicks all over again. Personally, as a ‘power user’, I was OK with that. And happy to trade it for the freedom to ask a slightly different question next time. But it was an objection often raised against what is now our ‘legacy’ product.
It seems strange now, but it started off as something we just had to do: Microsoft are investing massively in Power BI; they haven’t invested in PPS since 2013.
Sure, we were a little bit excited because we knew Power BI could make NGAGE a visually much more exciting solution. And it has. But once we started, we realized this was no migration. This would have to be a complete transformation of the user experience; a totally new approach to how we surfaced and provided secondary access to our data. It took months not weeks.
The first challenge was to somehow retain the strengths of the PPS offering.
What was special about our PPS + Cube approach was that you could create insights ‘on the fly’ that could answer even the most obtuse questions very quickly. Meaning the individual PPS reports (grids, bar charts, line graphs) we shipped with were almost never ‘the answer’ – because they didn’t need to be. Because in PPS I can right-click on any metric in any report and go into Drill Down or Decomposition Tree mode. These give me the ability to explore the underlying data without any predetermination. Example? I can start with a total, global SharePoint Page View count for 2017 and, within a few clicks, see (and export) the User Name, Browser Version, IP Address and/or Job Title of any visitor who hit the Home Page of a specific SharePoint Site at around 12 noon last Tuesday. Which is kind of cool. The bad news? If I want to persist that report, I can’t unless I’m a PPS technical specialist. And who is? Every time I want the answer to that question (I know I wouldn’t but…) I have to make those clicks all over again. Personally, as a ‘power user’, I was OK with that. And happy to trade it for the freedom to ask a slightly different question next time. But it was an objection often raised against what is now our ‘legacy’ product.

The mechanics of Power BI are very different. It’s not quite so easy to access all the data in our Cube unless we’ve hardwired that access into a specific report. There is, for example, no ‘freestyle’ Decomposition Tree feature (maybe one day..?). And ‘on demand’ Drill Down (a la PPS) is, as I’ve suggested, limited to what we predetermine within each visualization. The good news? It’s a simple (the on board Guided Learning is brilliant) non-technical process to create custom reports that do persist. And when I say non-technical, I really do mean it. No SQL queries, no DAX, no MDX. In fact, these aren’t even options. Power BI is connecting directly to our Cube so your only options are to select Visualizations from the gallery and then drop NGAGE Dimensions, Attributes, KPIs and Measures onto them. Or, the smarter way, just copy a vaguely appropriate out-of-the-box NGAGE report onto a new Power BI Page – and then just drag in the data fields and filters that give you exactly what you need.
The biggest 'Power BI effect'?
Despite this, we still felt the new Power BI Reporting suite had to cover off the vast majority of use cases without custom reports. The effect? What was 50 reports across 4 Pages of PPS is now 125 reports across 18 Pages of Power BI. That may sound unwieldy, but it isn’t. It did take a while (and lots of customer feedback) to find a structure and a flow that makes sense. But we think we’ve got there. It now supports a strong narrative spanning Governance & Administration, Adoption & Engagement and Risk & Compliance. And, of course, thanks to Power BI it all looks great. You can even have your own color scheme! Which brings me on to what I now regard as the biggest ‘Power BI effect’.
Our PPS offering did include KPIs. But, in visual terms, they looked like an afterthought – a low key combination of traffic lights and numbers. And the individual reports were kind of passive too. To repeat, the ‘wow’ from PPS is in the speed and simplicity with which you can use them as windows on underlying data to answer the most obtuse of questions.
Our PPS offering did include KPIs. But, in visual terms, they looked like an afterthought – a low key combination of traffic lights and numbers. And the individual reports were kind of passive too. To repeat, the ‘wow’ from PPS is in the speed and simplicity with which you can use them as windows on underlying data to answer the most obtuse of questions.

The ‘wow’ from our new Power BI offering is more that it asks the questions. By taking a very visual KPI and Trend driven approach NGAGE proactively challenges Farm, Portal, Site and Application Owners to improve. PPS will always be the better interrogation tool for ad hoc queries. But by taking the time to understand the strengths (and limitations) of Power BI we’ve been able to create something more valuable. Thanks to Power BI, NGAGE now provides an engaging, richly visual commentary on the state and performance of your farm, your portal, your site or your application. And because it’s proactive – because it ‘gives’ - you’re more likely to check in and use it every day and to use it more literally as a ‘dashboard’. Which means you’re more likely to identify a problem, to intervene earlier and to learn what works. And more likely to become measurably more successful.