Confluence Analytics: Find Out Which Pages Nobody Reads

A platform team I worked with was convinced their wiki had a discovery problem. Nobody could find anything, so the fix was obviously better search, better labels, a new information architecture. Then someone turned on Confluence analytics and opened the space report. Of roughly 4,000 pages in the engineering space, a few dozen carried almost all the traffic and the rest sat at zero views for the entire window. It was not a discovery problem. It was a volume problem wearing a discovery problem's clothes, and two years of "improve search" projects had been aimed at the wrong target.

Two honest things follow. Readership data mostly confirms what you already suspect, and its value is turning a suspicion into a number you can act on in a meeting. And page views are a weak proxy for value, so a naive read will have you delete the incident runbook that saves you once a year while keeping meeting notes that fifty people skimmed in one week and never reopened.

This walkthrough covers the three practical routes to readership data: native reporting on paid Cloud tiers, marketplace apps that go deeper, and the REST API for teams that want their own wiki usage reporting. Then it covers the part almost everyone skips, the decommissioning workflow that turns the report into fewer pages.

What confluence analytics can and cannot tell you

Confluence's reporting is a page-hit log with aggregation on top. That gives you four genuinely useful signals and leaves several important questions untouched.

What you can get:

• Views over a time window, per page and per space, usually against a prior period.
• Unique viewers, which matters far more than raw views because it separates one author refreshing their own draft from twenty people actually reading.
• Top and bottom content in a space by traffic, which is how you find the load-bearing pages and the dead weight in one pass.
• Search terms inside Confluence on the tiers that expose them, including searches that returned nothing useful. Failed searches are the most underrated dataset in the product.

What no view counter here can tell you:

• Whether the page was correct. A stale page with high traffic is worse than a stale page with none, because it is actively teaching people wrong things. Traffic amplifies error.
• Whether the reader got what they came for. No scroll depth, no trustworthy time-on-page, no "did this answer your question" unless you add one yourself.
• Whether the page is a duplicate. Analytics has no concept of two pages saying the same thing in different spaces, the most common form of documentation rot past about fifty people.
• Who should have read it and did not. Questions like "has every engineer read the on-call policy" need an acknowledgement mechanism, not a hit counter.

Hold that distinction the whole way through. Readership data tells you what is being consumed and says nothing about what is true. The teams that get burned treat a traffic report as a quality report. For the wider framing on why documentation rots regardless of platform, Knowledge Management Tools: What Teams Actually Use scores the category on maintenance burden rather than features, and the conclusion applies here too: the tool is rarely the problem.

Route one: native confluence analytics on Premium and Enterprise

The built-in reporting costs nothing extra if you are already on a qualifying plan, and it is enough to run a first cleanup.

Availability is the catch. Native readership reporting in Confluence Cloud sits on the Premium and Enterprise tiers. On the Free and Standard plans you will not see it, and no amount of admin poking will conjure it. Recent Confluence Data Center versions have their own equivalent built in. Atlassian moves these boundaries around, so confirm against your own instance rather than against a blog post, including this one.

Page level. Open a page, use the overflow menu in the top right, choose the analytics option. You get views and unique viewers over a selectable window, typically from the last week out to the page's whole life, plus who viewed it where permissions allow.

Space level. The analytics entry in a space sidebar gives you the version that drives decisions: a sortable table of every page with views and viewers, plus user activity and search terms. Sort ascending by views and you are looking at your archive candidates. Export to CSV from here. That CSV is the input to everything in the decommissioning section below.

Site level. Administrators get a cross-space rollup: which spaces are active, which are ghost towns, how many people read versus write. This is the view for a leadership conversation about whether a wiki consolidation is warranted.

Two behaviours to know before you trust the output. History starts when analytics started, so if you upgraded plans last month you do not have a year of data no matter what the date picker offers, and pages will look colder than they are. And restricted pages are only reported to people who can see them, so a space report run without full permissions is not the report an admin sees. Run the inventory as an admin or you will misclassify the restricted material.

One more product is worth knowing at the Enterprise tier: Atlassian Analytics, which sits over the Atlassian Data Lake and lets you query Confluence, Jira, and other Atlassian data with SQL or a visual query builder, then build dashboards from it. This is what people usually mean by atlassian analytics for confluence at the enterprise end. It is powerful for cross-product questions like "which spaces are linked from Jira tickets that are still open", and overkill if all you want is a list of cold pages. Treat it as the enterprise analytics wiki option rather than the default.

Route two: marketplace apps for deeper confluence page analytics

If the native reports do not cover you, either because of your plan or because you need something more opinionated, the Atlassian Marketplace has a category built specifically for confluence page analytics. Listings and pricing change, so verify current options yourself, but the category splits into three recognisable shapes.

View trackers. These report page and space traffic with more history, more granular filters, and per-user breakdowns than the native reporting. Viewtracker is a long-standing example. Right choice if you know what you want to measure and just need better instrumentation.

Content lifecycle and archiving apps. The more interesting shape for the problem in this article's title. Rather than only reporting traffic, they add expiry dates, ownership fields, review reminders, and bulk archive tooling. Midori's content archiving and analytics app is the well-known example. If your goal is fewer pages rather than prettier charts, a lifecycle app beats a better view counter, because it attaches a decision to the number.

Web analytics bridges. Apps that inject Google Analytics, Matomo, or similar into your pages so readership flows into the platform your marketing site uses. The appeal is a single analytics home and behavioural metrics the native reporting lacks. The costs are real: you inherit consent and tracking-policy questions for an internal tool, and metrics like bounce rate mean much less on a reference page than on a landing page.

Say this part plainly: a richer report does not produce a richer decision. The bottleneck in almost every documentation cleanup is not data quality, it is that nobody owns the outcome. Buying an advanced analytics wiki add-on to avoid appointing an owner is an expensive way to postpone the same conversation.

Route three: the API, for teams that want their own wiki usage reporting

If you want readership data joined to anything else, ticket volume, code ownership, onboarding cohorts, you need the raw data, and that means the REST API. Two endpoint families matter.

Content inventory. The standard content APIs give you every page in a space with its title, ancestors, labels, creator, and last-modified date. CQL, Confluence's query language, is the efficient way in. A query like type = page AND space = ENG AND lastModified < now("-18M") ORDER BY lastModified ASC returns your staleness candidates directly, before you look at a single view count. Paginate properly, because engineering spaces are bigger than people expect.

Analytics. Confluence Cloud exposes endpoints returning view and viewer counts for a given piece of content, with an optional start date. They carry the same plan requirement as the UI: if your tier does not show the reports, the endpoints will not fill the gap. Data Center differs, and some teams there read the app's own tables instead, which works but couples your reporting to a schema nobody promised to keep stable.

The practical build is a small scheduled job. Pull the inventory via CQL. For each page, request view and viewer counts for a fixed window, typically the trailing 12 months. Write both into a table keyed by page ID with a snapshot date, so you can watch trends rather than one still frame. Then join in the context you care about: space owner, team, labels, and inbound link counts if you are willing to parse page bodies.

Rate limits shape the design more than anything else. Per-page analytics for a 4,000-page space is 4,000 calls, so run it as an overnight batch with backoff and refresh monthly rather than continuously. Nobody needs real-time doc decay data.

Where teams go wrong here is the output. A CSV of 4,000 rows lands in a folder and is never opened. The deliverable should be a short ranked list with a recommended action per row, delivered where the owner already works. If your instinct is a spreadsheet and the spreadsheet is groaning, Excel Alternatives for Large Data Sets That Actually Work covers the options once row counts pass the point where a grid is the right container, and Smartsheet Reporting: Build Reports People Actually Read makes the sharper point that a report nobody opens is indistinguishable from one that does not exist.

Comparing the three routes

The honest default is the first column. Run the native space report, export the CSV, do the cleanup, and see whether you still have a problem. A surprising number of tool purchases in this space are attempts to buy motivation.

Where confluence analytics stops and judgment starts

Here is what separates a useful cleanup from a destructive one. Do not rank pages by confluence page views and delete from the bottom. Classify on two axes: traffic and freshness.

Almost every cleanup starts in the bottom right because it feels productive and the numbers are big. The damage lives in the top right. A three-year-old deployment runbook that 200 people opened last quarter does more harm than 2,000 forgotten pages combined, because those 2,000 pages are not teaching anyone anything.

Three more judgment calls the data will not make for you.

Reference-once pages are not failures. A disaster recovery procedure viewed four times a year is correctly sized for its job. Before archiving on low traffic alone, check whether the page is an emergency artefact, an audit record, or a decision record whose value is that it exists when someone asks "why did we do it that way". If a meaningful share of your wiki is records rather than prose, you have a document management problem inside a wiki, and Open Source Document Management Systems Worth Running explains what changes when the artefact needs version control and retention rules.

Failed searches beat view counts. The search-terms report tells you what people wanted and did not get. A term searched repeatedly with no successful click is a missing page, and missing pages are usually more expensive than stale ones. No view report surfaces that, because a page that does not exist has no row.

Some zero-view pages were never meant to be shared. Many dead pages are personal working notes written in a team space because that is where the cursor happened to be. Giving people a proper individual system cuts the shared page count more than any cleanup does, and Personal Knowledge Management System: A Setup That Lasts covers what that looks like without becoming another abandoned tool.

The decommissioning workflow most teams skip

Everything above is measurement. This is the part that changes the page count, and where most documentation initiatives quietly stop. The workflow is not complicated. It is just nobody's job.

1. Freeze an inventory. Export the space report to CSV: one row per page with views, unique viewers, last modified date, creator, labels, and parent. Date the snapshot, because you will compare against it next quarter.

2. Classify into the four quadrants. Mechanical rules, no debate. Trailing 12 months of views against 12 months since last edit is a reasonable starting threshold for most engineering and operations spaces.

3. Assign owners by space, not by page. Per-page ownership is fiction at any scale. Per-space ownership is a real conversation with a person who can approve a batch.

4. Announce a deadline with a default. The sentence that makes this work: "These 340 pages will be archived on the 15th unless someone claims them." Opt-out beats opt-in by an enormous margin, because claiming a page takes ten seconds and reviewing 340 pages is a project nobody will start.

5. Archive, do not delete. Confluence's archive keeps pages out of search and the page tree while leaving them recoverable. Deletion creates anxiety, and anxiety kills cleanup projects. Reversible decisions get made fast.

6. Fix the dangerous quadrant properly. High-traffic stale pages get a human review, not a bulk action. Assign each to someone who knows the subject, with a short deadline. This is the only step that costs real time, and it is the step that pays.

7. Set review dates on the survivors. A label, a date field, an app-managed expiry, whatever your setup supports. Without this you are back here in eighteen months.

8. Re-run quarterly. It should take an afternoon the second time. If it does not, your inventory step is too manual, which is the argument for the API route.

This gets skipped not because it is hard but because it never reaches the top of anyone's queue. No deadline, no customer, no visible failure until someone follows a wrong page into an outage. The fix is a recurring slot with a named owner, the treatment you give dependency upgrades. Team Productivity Tools That Remove Work Instead of Adding It makes the general case: the highest-leverage tooling deletes recurring work rather than adding another surface to check.

Where Skopx fits, and where it is not a confluence analytics tool

Straight answer first. Skopx is not a Confluence analytics plugin. It does not install into your instance, it does not count page views, and it does not build readership dashboards. If you want a chart of confluence page views by month, everything you need is in the three routes above.

What Skopx does is sit alongside those tools. It is an AI workspace connecting nearly 1,000 tools a company already uses, Confluence among them, plus Slack, Gmail, Jira, Google Analytics, HubSpot and the rest. Three parts of it touch this problem.

Chat with citations. With Confluence connected next to your other systems, you can ask about documentation in plain language and get answers that cite the pages they came from. "What does our on-call escalation doc say, and when was it last edited?" becomes a chat question rather than a search-and-scroll exercise. That is retrieval, not analytics, and its value is that the citation names the exact page a claim came from, which is often how you discover that two pages disagree.

Morning brief. Cleanup never happens because it never gets scheduled. A recurring brief carrying a short doc decay item, the pages crossing your staleness threshold or the high-traffic pages nobody has touched in a year, puts the work in front of a person on a normal Monday instead of after an incident. The numbers still come from Confluence. The scheduling and the nudge are what gets added.

Workflows. Automations are built by describing them in chat rather than wiring nodes, so a quarterly loop that pulls an inventory, classifies it, and posts archive candidates to the owning team's Slack channel is a conversation rather than a project. The workflows page shows the shape of that.

Where it does not fit, just as plainly: it is not a BI tool, not a data warehouse, not an ETL pipeline, and not a CRM. It will not model three years of page-view history or produce the enterprise analytics wiki dashboard a compliance team might ask for. Atlassian Analytics on Enterprise or your own warehouse is the answer there. Skopx uses your own AI key with zero markup, which matters when you point it at a large corpus, and pricing is Solo at $5 per month and Team at $16 per seat per month on the pricing page.

The recurring loop described above, in workflow form:

Quarterly documentation decay review

First Monday of the quarter

Recurring trigger so the review has a date instead of good intentions.

Pull page inventory

Every page in the spaces in scope, with last-modified date, owner, and labels.

Fetch view counts

Trailing twelve months of views and unique viewers per page.

Classify into four quadrants

Traffic against freshness. High traffic plus stale is the priority queue.

Post archive list to space owners

Opt-out deadline: archived on the 15th unless claimed.

Add stale high-traffic pages to the brief

The dangerous quadrant reaches a human on a normal morning.

Frequently asked questions

Is Confluence analytics available on the free plan?

No. Readership reporting in Confluence Cloud sits on Premium and Enterprise, and on Free and Standard the page and space analytics entries do not appear at all. Recent Data Center versions include their own equivalent. If upgrading a whole site purely for reporting is not justifiable, a marketplace view tracker or a scripted inventory based on last-modified dates alone gets you most of the way to a first cleanup, since staleness is often the stronger signal anyway.

How far back does the data go?

Only as far back as analytics has been running. The date picker may offer a year, but if the feature was enabled two months ago you have two months, and every page will look colder than it is. Take a CSV snapshot now and keep taking them: six quarterly snapshots beat one deep query, because a page falling from 400 views to 40 says far more than a page sitting at 40.

Can it tell me which pages are duplicates?

No, and this is the biggest gap. Readership reporting has no semantic understanding of content, so two pages describing the same deployment process in different spaces both look legitimate. Detection is indirect: near-identical titles, one search term returning multiple competing results, and chat questions that surface two cited pages saying different things. Duplicate hunting remains human work, best done space by space by someone who knows the subject.

Should I delete low-traffic pages?

Archive them instead. Archiving removes pages from search and the page tree while keeping them recoverable, which makes every decision reversible and therefore fast. Deletion invites debate, and debate stalls cleanup projects. Check for reference-once pages before you act: disaster recovery procedures, audit records, and decision records are supposed to have low traffic.

What is the difference between this and Atlassian Analytics?

The built-in reporting answers "who read this page". Atlassian Analytics is a separate Enterprise-tier product over the Atlassian Data Lake that queries Confluence and Jira data with SQL or a visual builder and builds dashboards from it. It is right for cross-product questions and considerable overkill if you want a ranked list of cold pages. Start with the native space report and move up only when you have a question the CSV cannot answer.