Content Analytics System
Making self-service measurable.
Help center decisions ran on intuition because usage, support and login data lived in tools that didn't talk to each other. I built a measurement framework that connects them, so three teams now judge self-service on the same evidence, and it has run every month since January 2025 without an engineer.
20 months
UNBROKEN MONTHLY REPORTING
ROLE
Content Strategist & Analytics Lead
TIMELINE
2025, live since January 2025
TEAM
Enablement, CX, Support
TOOLS
GA4, Zendesk Explore, Google Sheets, Tableau, Django
01
The challenge
We could see traffic. We couldn't tell whether self-service worked.
The migration gave both help centers a new structure. Nobody could yet tell whether it was working.
Reporting stopped at activity. As our Business Systems manager put it: "Other than total views, content metrics are not gathered or inform any sort of content strategy."
The data that could answer the real question was split three ways. GA4 knew about users and sessions but nothing about tickets. Zendesk knew about views, searches and tickets but couldn't count unique users. Only the products knew who had actually logged in. Zendesk couldn't even produce a ticket-to-search ratio, because tickets weren't submitted through the help centers.
So content decisions ran on intuition. A popular article might be solving problems, or sending people straight to a ticket. A drop in traffic could mean less demand, a findability problem or internal teams working somewhere else. Without connecting the signals, there was no way to tell which.
02
The insight
Traffic isn't the same as success.
The default dashboards answered questions about activity, not effectiveness. Pageviews told us people arrived. Search volume told us people were looking. Neither told us whether they found what they needed.
I changed the measurement question from "How much is our content being used?" to "Is our content helping users solve problems without contacting Support?"
Answering that meant three things: combining usage with ticket escalation data, tracking it over time, and knowing whose behaviour each number represented. Staff and customers used the same help centers, and a busy week for internal teams could look exactly like customers helping themselves.
The key decision was to build a shared measurement framework, not another dashboard of disconnected metrics.
“Traffic tells you people showed up. It doesn't tell you whether they left with an answer.”
03
The system
One measurement framework connecting usage to support demand.
I built one reporting workbook per help center, with three layers:
Data entry. About 20 raw inputs each month, every one labelled with its source: GA4, Zendesk, Tableau or Django.
Dashboards. KPIs calculated automatically and grouped into engagement, self-service success and content effectiveness. Each month sits next to the same month last year, with flags on the biggest movements.
A metric dictionary. For every metric: what it means, how it's calculated, step-by-step instructions for sourcing it, what to read alongside it, and what to pull when something looks off. This is what lets the teams run it without me.
At the centre is the Self-Service Score: engaged help center sessions divided by the users who escalated to a support ticket. It only improves when self-service grows faster than escalation.
Two more choices made the numbers trustworthy. Usage Rate measures help center visitors against real user populations: Studio's active users from Tableau and Da Vinci's active licences from Django. And because Zendesk couldn't link tickets to searches, the framework filters ticket forms down to help center issues and calculates the ratios itself.
04
Key Decisions
Build a system people could trust and maintain.
01
Connect activity to support demand.
I rejected pageviews and search volume as standalone success measures. They show demand for content, not whether that demand gets resolved. The Self-Service Score combines usage and escalation into one trend line. It's a decision signal, not proof that a specific article prevented a specific ticket.
02
Segment before drawing conclusions.
The headline score is deliberately blended across everyone, because it's there to show direction. The metrics used to investigate are split between staff and customers: article views, searches, failed searches, click-through and tickets. When the score moves, the split shows whose behaviour moved it. A metric is only useful when you know whose behaviour it represents.
03
Prioritize trends over isolated numbers.
A single month can move for reasons unrelated to content quality. Comparing each month with the same month last year filters out seasonality, and the flags point people toward where to look. They don't replace the looking.
04
Design around the tools we already had.
There was no engineering support, so I built the framework on GA4, Zendesk Explore and Google Sheets, with exports from Tableau and Django. That constraint shaped the result: a transparent system the teams can read, audit and maintain themselves. A useful measurement system doesn't require a new platform.
05
The Transformation
From reporting numbers to investigating problems.
Reporting used to mean pulling views, searches and ticket totals, then interpreting each one separately with no shared definition of success.
Now there's a repeatable loop. Teams watch the Self-Service Score, spot a change against last year, drill into the segmented metrics to see what moved and whose behaviour moved it, then decide what to fix.
That loop reaches individual articles. When one section of an article draws more views than the rest of it, that section becomes its own article. When articles get few views, they're merged into related ones or archived. The data now shapes the structure of the library, not just a monthly report about it.
BEFORE
Pull pageviews
Review searches
Count tickets
Interpret each one separately
AFTER
Monitor the score against last year
Drill into segmented signals
Split high-traffic sections into new articles
Merge or archive what nobody reads
06
the outcome
A shared evidence base for three teams.
The framework gave Enablement, Customer Experience and Support one shared source of truth for help center performance. Instead of requesting one-off numbers or relying on gut feel, they pull from the same reporting system every month. It has now run for 20 months without a break.
It also answered the question the migration had left open. The data showed the new IA and templates were working: on Da Vinci, customer article views more than doubled year over year.
And it prevented at least one wrong conclusion. Staff article views dropped, which on an unsegmented dashboard would have looked like the help center losing its audience. The split showed what had actually happened: internal teams had started reading the same content in Guru, where none of that activity was tracked.
07
What I Actually Designed
The measurement system behind the dashboard.
The visible output was a pair of reporting dashboards. The underlying work was designing how the organization measures self-service.
I defined the metrics and the Self-Service Score, connecting usage with support demand.
I set up the integrations: GA4 on both help centers, tuned Zendesk Explore reports, and Tableau and Django data for real user populations.
I established the audience segmentation that keeps diagnostic comparisons meaningful.
I designed the reporting cadence: monthly, compared year over year, with flags on the movements worth investigating.
I wrote the metric dictionary that makes the framework maintainable by the teams who use it.
The value wasn't another dashboard. It was a system that turned fragmented data into a shared basis for decisions.
08
The bigger idea
Measurement should change what happens next.
Analytics only becomes useful when it changes a decision.
Here it closes a loop. The migration built the structure: shared IA, topic types and templates. The measurement framework shows where that structure is working and where it isn't. The answers feed back into the structure as new articles, merged articles and archived ones.
It gives teams a consistent starting point for better questions: Where is self-service improving? Where is it struggling? Whose behaviour are we actually looking at?
The goal wasn't to report more numbers. It was to make the numbers useful.
09
Reflection
A useful metric needs context, not just a formula.
The hardest part wasn't connecting GA4 and Zendesk. It was deciding what the combined data could honestly tell us, and what it couldn't.
The Guru moment made that concrete. The numbers said staff engagement was falling. Read without context, that's a content problem. Read with segmentation, it was a behaviour change in a tool none of our analytics could see. The data was accurate the whole time. The conclusion would have been wrong.
That's the lesson I carry forward: measurement design is part of content strategy. A metric without a definition of whose behaviour it represents will eventually tell a confident, wrong story. If teams don't share a definition of success, more dashboards won't create alignment.
Want to know how the Self-Service Score is actually weighted, or what almost got measured instead? Reach out and I can go into the details!