A couple of months ago, I wrote about building my first Umbraco extension, ThtaAI. What started as a relatively simple AI button next to a content field eventually turned into a package capable of generating entire Umbraco pages. At the end of that article, I mentioned that I was fairly sure it wouldn't be my last extension. Well, it wasn't.
My second extension is called HuSignal, an open-source package that brings Microsoft Clarity analytics directly into the Umbraco 17 backoffice, accumulates behavioural data over time and uses AI to help turn that information into useful reports and recommendations. The idea is quite different from ThtaAI, but there's a common theme: making existing tools more useful for the people actually managing websites. And, as with the first extension, what initially seemed like a fairly straightforward idea introduced some interesting problems along the way.
Starting with a different problem
With ThtaAI, the starting point was content creation. Could I make it easier for an editor to generate copy without leaving Umbraco? This time, I was thinking about what happens after content has been published.
We spend a lot of time building websites, refining user journeys and making decisions about how content should be presented. But once a page goes live, understanding how people actually interact with it is another challenge entirely. There are plenty of analytics tools available, but the information they provide often sits outside the CMS. An editor might be updating a landing page in Umbraco while the data that could help inform those changes lives somewhere else. That got me thinking.
What if some of that information was available directly inside the Umbraco backoffice?
Not necessarily to replace dedicated analytics platforms, but to give editors and website teams a useful overview of what's happening without constantly switching between applications. I already had Microsoft Clarity in mind. It's a useful tool for understanding visitor behaviour through metrics, heatmaps and session recordings. More importantly for this experiment, it has an API. That gave me somewhere to start.
Getting Microsoft Clarity data into Umbraco
The first part of HuSignal was relatively simple in concept. Connect to the Microsoft Clarity API, retrieve the available analytics data and display it inside Umbraco. Of course, displaying some JSON from an API isn't particularly useful on its own. The information needs to be presented in a way that somebody managing a website can actually understand. HuSignal brings together metrics such as:
Sessions and pages per session
Scroll depth
Dead clicks and rage clicks
Quickbacks and excessive scrolling
Error clicks and script errors
Popular pages and referral sources
Countries, devices, browsers and operating systems
These give website teams a useful starting point for understanding how visitors interact with a site. For example, if a page has a particularly high number of dead clicks, that might be worth investigating. If visitors are repeatedly returning to a previous page, perhaps something about the journey isn't working as expected. But there's an important distinction here. A behavioural metric is not necessarily an explanation. A dead click doesn't automatically mean a broken link, and a quickback doesn't prove that somebody couldn't find what they were looking for. That distinction eventually became one of the most important parts of the extension.
The problem with looking at analytics over time
One of the things I wanted HuSignal to do was make analytics useful beyond a single snapshot. The Microsoft Clarity API provides data that can be retrieved for reporting, but I wanted to build up a longer-term picture within Umbraco itself. So rather than simply requesting data whenever somebody opens the dashboard, HuSignal collects and stores daily snapshots. That introduces a slightly different problem from my first extension.
ThtaAI was primarily about generating something when an editor requested it. HuSignal needs to collect information, store it and make it available for later analysis. The package therefore has a backend responsible for retrieving and persisting analytics data, alongside the backoffice interface used to explore it. This separation is important because the reporting features shouldn't depend entirely on whatever information happens to be available from the API at the moment somebody requests a report. Instead, HuSignal can work with the data it has accumulated for a selected reporting period. It's a relatively straightforward architectural decision, but it makes the extension much more useful.
Making analytics understandable inside the backoffice
One of the lessons I took from building ThtaAI was that getting something working technically is only half the problem. The other half is making it usable. With analytics, that's particularly important. There's a temptation to display every available metric, add a few charts and call it a dashboard. But a screen full of numbers doesn't necessarily help somebody understand what they should do next.
For HuSignal, I wanted the backoffice to bring together the most useful information without expecting editors to understand every detail of Microsoft Clarity. Traffic and engagement information provides an overview of activity. Behavioural metrics highlight potential areas of friction. Popular pages and referral information provide some context about where visitors are going and how they arrive. Device and browser information can help identify patterns that might be worth investigating further. The aim isn't to turn Umbraco into a complete analytics platform. It's to bring relevant information closer to the people making changes to the website. That feels like a sensible role for a CMS extension.
Adding AI: from numbers to useful observations
Once the analytics data was available, the next question was fairly obvious. Could AI help interpret it? This was where the project started to connect back to ThtaAI.
With my first extension, I was using an LLM to generate content that fitted into an existing Umbraco structure. With HuSignal, the task is almost the opposite. I already have structured information, and I want the model to explain what it might mean in plain English. For example, rather than simply showing a collection of metrics, HuSignal can generate a report covering:
Traffic and engagement
Behavioural signals
Popular content
Audience and technology
Referral traffic
Prioritised recommendations
Limitations of the available data
The idea is that somebody can select a reporting period and receive a structured explanation of the information collected. But this introduced a problem that I think is particularly important when using AI for analytics.
LLMs are very good at producing explanations, even when the available evidence doesn't justify them.
And that's not particularly helpful when you're trying to make decisions about a website.
When AI sounds more confident than the data allows
Imagine that Microsoft Clarity reports a number of dead clicks on a page. It's tempting for an AI model to turn that into something like:
"Users are clicking a broken button, causing frustration and preventing conversions."
That sounds like a useful insight. The problem is that the data hasn't established any of those things. We know that dead clicks occurred. We don't necessarily know which element caused them, whether anything is broken or whether those interactions prevented a conversion. The same problem applies to other behavioural metrics. A low scroll depth doesn't automatically mean the content is poor. A quickback doesn't necessarily indicate a navigation problem. And Microsoft Clarity data alone can't tell us which keywords a page ranks for or whether organic search traffic has increased.
This became an important design decision for HuSignal. Rather than asking the model to act like an all-knowing analytics consultant, the reporting system is designed to distinguish between what the data shows and what still needs investigating. A useful recommendation might therefore be:
"Dead clicks were recorded on this page during the reporting period. Review the relevant Microsoft Clarity session recordings and heatmaps to identify which elements visitors were attempting to interact with."
That's considerably more useful than confidently diagnosing a broken button without any supporting evidence. It also gives somebody a practical next step.
Getting the AI to respect the evidence
One of the biggest lessons from ThtaAI was that prompt engineering isn't a substitute for good application design. I ran into that problem when trying to generate entire Umbraco pages. Eventually, I realised that the application needed to handle more of the predictable work itself rather than expecting the LLM to understand everything. The same principle applies here. HuSignal supplies the model with structured analytics information and asks it to generate a report based on that evidence. The reporting instructions deliberately restrict unsupported claims. For example, the model shouldn't invent:
Google rankings or search queries
Conversion rates or revenue figures
Reasons behind visitor behaviour
Search intent
Causes of technical issues that haven't been established
It also needs to acknowledge situations where there isn't enough information to draw a useful conclusion. This might sound like a small detail, but I think it's one of the most important aspects of using AI for reporting. A report that confidently tells you something incorrect can be considerably worse than one that simply says further investigation is needed.
AI should help identify where to look, not pretend it has already found every answer.
Keeping the language model configurable
Another decision I carried over from ThtaAI was not tying the extension to a particular AI provider. During development of my first extension, I'd experimented with running language models locally using Ollama. That experience made me appreciate the benefits of keeping the AI integration configurable.
HuSignal uses a compatible LLM API for report generation, allowing the endpoint and model to be configured rather than hard-coded into the package. That means the reporting functionality can work with locally hosted models or other compatible services. There are several reasons I like this approach. Different models have different capabilities, particularly when it comes to following detailed instructions and producing structured responses. The model that works well for one task might not be the best choice for another. It also means the package doesn't have to depend on a single commercial AI provider.
Of course, running a model locally doesn't automatically guarantee good results. The quality of the reports still depends on the model's ability to follow instructions, interpret the supplied data and produce a valid response. But having that flexibility feels like the right starting point for an open-source extension.
Turning the reports into something shareable
Displaying a report inside Umbraco is useful, but I also wanted the information to be easy to share. Website analytics rarely matter to just one person. A developer might be interested in script errors and unusual interactions. A content editor might want to understand which pages are attracting attention. A project manager or client might simply want to know what has changed and where improvements should be prioritised.
That's why HuSignal also supports generating PDF reports. The idea is to take the structured analysis and turn it into something that can be shared with other members of a team or discussed with stakeholders. This makes the extension useful beyond the backoffice itself. Rather than asking somebody to log into Umbraco or Microsoft Clarity to see the information, the findings can be presented in a more accessible format. And importantly, the report can retain the distinction between observations, possible interpretations and recommended next steps.
Does this replace Microsoft Clarity?
No, and it isn't supposed to. Microsoft Clarity already provides much more detailed tools for investigating individual visitor interactions. Session recordings and heatmaps are particularly valuable when trying to understand why a behavioural metric looks unusual. HuSignal isn't attempting to recreate all of that functionality.
Instead, it sits alongside Clarity. It collects the available analytics data, brings useful information into Umbraco and helps turn that data into reports that are easier to understand. If a report highlights an unusual number of rage clicks or dead clicks, the next step might be to open Microsoft Clarity and investigate the relevant recordings. I think this is a better approach than attempting to make the extension responsible for every stage of the analysis. Use the right tool for the right part of the problem.
What about SEO?
One interesting aspect of HuSignal is that behavioural analytics can also inform conversations about website optimisation. If visitors repeatedly interact with elements that don't respond as expected, or particular pages show unusual engagement patterns, those are potentially useful signals when reviewing a website. But behavioural analytics and SEO performance aren't the same thing. Microsoft Clarity doesn't tell us where a website ranks in Google, which search queries are driving impressions or whether a page is gaining organic visibility. Those questions need appropriate search performance tools.
As we discussed in our article on optimising Umbraco websites for AI search, effective website optimisation involves much more than looking at a single metric. HuSignal can contribute to that process by highlighting how people interact with a website once they arrive. It shouldn't be treated as a replacement for Google Search Console, dedicated SEO tools or a broader analytics strategy. For me, that distinction matters because I want the recommendations to remain credible.
What HuSignal does today
At the time of writing, HuSignal is built for Umbraco 17 and includes several main features.
Microsoft Clarity integration
Connect to a Microsoft Clarity project using an API token and retrieve behavioural analytics information.
Daily data collection
Store daily analytics snapshots so that information can be accumulated and reviewed over longer reporting periods.
Umbraco analytics dashboard
View traffic, engagement, behavioural signals, popular pages, referral information and audience technology data directly inside the backoffice.
AI-assisted reporting
Generate structured reports from the accumulated data, with observations, prioritised recommendations and explanations of what the information can and cannot establish.
PDF report generation
Export reports into a format that can be shared with clients, stakeholders and other members of the team. The package is open source, and the implementation is available on GitHub.
What I learned from building my second extension
Looking back at both projects, I think the biggest difference is how I'm thinking about the role of AI. With ThtaAI, the challenge was getting AI to produce something useful that Umbraco could understand. With HuSignal, the challenge is getting AI to explain something useful without claiming to understand more than the available data allows. Both problems involve working with structured information, but the responsibilities are quite different. I've also become more convinced that a good Umbraco extension should fit naturally into the workflow that already exists. ThtaAI brings content generation into the editing experience. HuSignal brings behavioural insights into the same environment. Neither requires somebody to abandon the tools they're already using.
Another lesson is that it's worth being deliberate about what an extension doesn't do. HuSignal doesn't need to replace Microsoft Clarity. It doesn't need to become a complete SEO platform. And it certainly doesn't need to generate definitive explanations for every metric. It needs to make useful information more accessible and help people decide what to investigate next. That's a much more manageable problem, and hopefully a more useful result.
From creating content to understanding it
There's something quite satisfying about how these two extensions fit together. My first extension was about helping people create content. My second is about helping them understand how visitors interact with that content. One focuses on the process before publishing. The other helps inform decisions after a website is live. And both are built around the same principle: use AI to make people's work easier while keeping the important decisions in human hands.
I'm sure there's plenty more I could do with HuSignal, and as with ThtaAI, I'm expecting the package to evolve as I continue working on it. For now, it's been another useful exercise in understanding the Umbraco 17 extension architecture, integrating external services and finding practical ways to use AI beyond simply generating text.
Try HuSignal or explore the source
HuSignal is open source under the MIT licence, so if you're interested in how it works, feel free to explore the implementation.
GitHub source code and development history:
github.com/dwhalley15/hu-signal
NuGet installation:
The repository documents installation using:
dotnet add package HuSignal
The extension requires Umbraco 17 and a Microsoft Clarity project with an API token. AI-assisted reporting additionally requires access to a compatible LLM API. You can find the installation and configuration instructions in the HuSignal README.
If you're interested in how I got started with Umbraco extensions, you can also read my previous article about building ThtaAI, from a simple AI button to generating entire pages.
Two extensions down. I'm fairly sure there'll be a third.