Notion Analytics: How to Measure What Happens in Notion

Your Projects database has 214 entries. Every one has an owner, a status, and a target date, because someone on the ops team spent a weekend setting up the template. Leadership asks a reasonable question: which of these are actually moving, and which have quietly died? You open the database, sort by Last edited time, and realise that half the recent edits are someone dragging a card between board columns without touching the work underneath.

That is the honest starting point for Notion analytics. Notion is excellent at holding structured knowledge and moderately good at counting what is in it. It is not built to tell you whether the thing the page describes is alive. This guide documents exactly what Notion exposes natively across three layers, where each layer stops, and the cross-tool pattern that answers the questions Notion's own views cannot reach.

Plan gating in Notion changes more often than the features themselves. Every capability below is described with its tier as of writing, and you should confirm against Notion's current plan comparison before you build a process on top of it.

What Notion analytics actually means: three separate layers

People say "Notion analytics" and mean at least three different things. They live in different parts of the product, they have different plan requirements, and they answer completely different questions. Conflating them is the reason most Notion reporting projects stall.

The mental model that helps: page and workspace analytics measure attention. Database analytics measures content. Audit logs measure actions. Almost every interesting business question needs two of those three at once, plus something from outside Notion, which is where the native ceiling shows up.

Page analytics: what the Updates and Analytics panel shows

Open any Notion page, click the clock or updates icon in the top right, and you get a panel with two tabs. The first is the edit history feed. The second is analytics.

The analytics tab gives you view counts and a list of people who opened the page, most recent first, with timestamps. That is genuinely useful for a narrow set of questions:

• Did the six people I need to read this spec actually open it?
• Is this onboarding doc getting traffic, or is everyone still asking in chat?
• When was the last time anyone looked at this policy page?

The retention window and the level of viewer detail depend on your plan. On lower tiers you get a shorter history and a coarser view. Paid tiers extend both. Guests and public web visitors are handled differently from workspace members, and public page traffic is not equivalent to the analytics you would get from a real web analytics tool: there is no referrer, no session, no funnel, no bounce.

Three limits matter more than the plan gate:

Views are not reading. A view is a page load. Someone who opens a page, sees a wall of text, and closes it counts identically to someone who reads it end to end. There is no scroll depth and no time on page.

There is no aggregation. Page analytics are per page. If you want to know which of your 40 process docs are dead, you open 40 panels. Nothing in the native product rolls page-level view counts into a single sortable list at the page level.

The API does not expose it. This is the constraint that surprises people building custom Notion reporting. Notion's public API is a content and property API. It reads and writes pages, blocks, databases, and their properties. It does not return view counts or viewer lists. If your reporting plan depends on programmatic access to page analytics, that plan does not work today.

Notion workspace analytics: what the paid plans unlock

Workspace analytics is the aggregation layer that page analytics lacks, and it is the clearest reason teams move to Business or Enterprise. It lives in workspace settings rather than on any individual page.

What it covers, in broad strokes:

• Workspace-wide activity over time, including page views and edits
• Most-viewed and most-edited pages, so you can see what the workspace actually leans on
• Member-level activity, which tells you who is contributing and who has gone quiet
• Search analytics on higher tiers, including what people looked for, which is the single most underrated signal in the whole product

Search analytics deserve a paragraph of their own. Queries with poor results are a direct map of the documentation you are missing. If eleven people searched for "expense policy" this month and the top result was a 2023 draft in someone's private area, that is not an analytics finding, it is a work order. Very few teams with access to notion workspace analytics ever look at this tab.

What workspace analytics does not do:

It does not segment by team the way you want. You can look at members and pages. You generally cannot ask "show me engineering's documentation health versus sales" without doing the grouping yourself outside the product.

It does not connect attention to outcomes. It will tell you the launch checklist got 300 views. It cannot tell you whether launches that used it shipped on time, because ship dates live in your project tool and revenue lives in your billing system.

It is a workspace tool, not a data source. Exports and API access at this layer are limited, and the Enterprise audit log is designed for security review rather than business reporting. If your goal is to blend Notion activity with other systems, this is not the seam to build on.

Notion database analytics: turning properties into measurement

This is the layer with the most room and the least attention. Notion database analytics means using views, calculations, and property design to make a database answer questions about itself.

The primitives, in the order they pay off:

The calculation row. At the bottom of any table column, Notion offers Count all, Count values, Count unique, Count empty, Percent empty, Percent not empty, and for number properties Sum, Average, Median, Min, Max, and Range. Percent empty on a required field is the fastest data quality check in the product. If 40 percent of your Owner column is empty, no downstream reporting is trustworthy, and you have learned that in two clicks.

Group by, with per-group counts. Board and table views both support grouping, and each group header shows its own count. Grouping a projects table by Status gives you an instant distribution. Grouping by Owner gives you load. Sub-grouping gives you a crosstab.

Filters as saved questions. A view is a saved query. Name it like a question and it stops being a layout and starts being a report. "Active, no update in 14 days" is a better view name than "Table 3."

Rollups. A relation plus a rollup lets a parent row summarise its children: count of open tasks, latest edit across linked items, sum of estimates. Rollups are the only native way to aggregate across two databases, and they only work when a relation already exists.

Formula properties. Formulas turn raw properties into indicators. A days-since-last-edit formula built on the built-in Last edited time property, or a slip formula comparing target date to today, converts a column of dates into a column you can sort, filter, and colour.

Chart views. Notion supports chart visualisations on database data, with the usual bar, line, and donut shapes driven by group and aggregate settings. Availability and configurability vary by plan, and the charting is deliberately simple: it is there to visualise one database, not to join several.

The five properties that make a database measurable

Most Notion databases cannot be measured because of how they were built, not because of Notion's limits. Before any notion reporting effort, make sure every operational database carries:

1. Status, as a real Status or Select property, never free text
2. Owner, as a Person property, never a text field with names typed in
3. Created time and Last edited time, the built-in system properties, added as visible columns
4. A date that means something specific, such as target date or due date, defined once so everyone enters the same thing
5. A stable identifier or relation that links the row to the same object in your project tool, so the two systems can be joined later

Point five is the one teams skip and regret. Without it, a Notion row and the Linear or Jira issue it describes are two unrelated strings, and no amount of analytics on either side can connect them.

Building a staleness report natively, step by step

Here is the highest-value report you can build inside Notion with no extra tooling. It answers "what looks alive but is not" using only native features.

1. Open your Projects database and create a new table view. Name it "Quiet but open."
2. Add a filter: Status is one of your active values, such as In progress or Blocked.
3. Add a second filter: Last edited time is before, then choose a relative option such as one week ago or two weeks ago.
4. Sort ascending by Last edited time so the deadest items rise to the top.
5. Group by Owner so each person sees their own list.
6. Add a calculation on the Name column set to Count all, giving you a single headline number.
7. Optionally add a formula property that computes days since last edit, then colour or sort on it.

That view is a real report. It refreshes itself, it costs nothing, and it will find things.

It also has a specific blind spot you must know about: Last edited time updates on any property change. Someone toggling a checkbox, adding a tag, or dragging a card resets the clock without any work happening. In practice, this makes the native staleness report better at finding total abandonment than at finding slow decay. To catch slow decay you need the signal that the work itself has stopped, and that signal is not in Notion.

Where Notion analytics stops

Four hard limits, stated plainly, so you can decide what to buy before you buy it.

No cross-tool joins. Notion can aggregate within a database and across a relation. It cannot join a Notion database to Slack channel activity, GitHub commits, Stripe revenue, or HubSpot deal stages. Rollups do not reach outside the workspace.

No history, only current state. Notion stores the current value of every property. It does not store a time series of those values. You cannot natively ask "how many projects were blocked each week last quarter," because last week's status was overwritten by this week's. Teams work around this with automations that append a row to a snapshot database on a schedule, which works but has to be designed before you need the history, not after.

Attention data is trapped. Page and workspace analytics cannot be pulled through the public API, so they cannot feed anything else. The most interesting question in this whole space, whether the documents people read correlate with the work that succeeds, requires joining attention data to outcome data, and the attention half is not exportable in a usable way.

API shape and rate limits. The public API is fine for reading database rows and properties, and awkward for reading page content, which arrives as nested blocks you have to walk recursively with pagination. Rate limits are modest, on the order of a few requests per second averaged, so a full workspace crawl is a batch job, not an interactive query. Recent API versions also separate databases from their underlying data sources to support multi-source databases, which is worth checking before you write integration code against older examples.

None of that is a criticism. Notion is a workspace, not an analytics platform. The mistake is expecting the last mile from it. The same expectation gap shows up in every vertical tool that grew a reporting tab: it is exactly the pattern described in our guide to real-time insights, where the tool that holds the data is rarely the tool that produces the claim.

The cross-tool pattern: Notion plus Slack plus your project tool

The question leadership actually asked at the top of this article was not "which rows have old timestamps." It was "which documented projects have gone quiet." Answering it needs three sources:

• Notion supplies the inventory: what projects exist, who owns them, what status they claim, when the doc last changed.
• Your project tool supplies the work signal: whether issues moved, whether commits landed, whether anything shipped.
• Slack supplies the human signal: whether the project channel is still talking, and whether the last message was a question nobody answered.

A project is genuinely quiet when all three are quiet. A project with a stale Notion doc but a busy channel and moving tickets is fine, it just has bad documentation hygiene. A project with a freshly edited doc, a silent channel, and no ticket movement in three weeks is the dangerous one, because it looks healthy in every single-tool view.

That is the whole argument for cross-tool analysis in one paragraph. No single system holds enough context to be right, and the disagreement between systems is where the signal lives. The same structure applies far outside knowledge work: see how operators combine network, ticketing, and billing signals in telecom analytics solutions, or how fleet teams join telematics to dispatch records in transportation analytics software.

Here is what that check looks like as a scheduled routine rather than a manual audit:

Weekly quiet project check

Monday 07:00

Runs before the leadership standup

Read Notion projects

Status, owner, last edited time, linked channel

Keep active projects

Status is In progress or Blocked

Check channel activity

Days since the last human message

Check tracker movement

Issues moved or closed since the last run

Score each project

Quiet only if all three signals are cold

Write the summary

One line per project, owner named, evidence cited

Post to leads channel

Threaded so owners can reply in place

You can build that yourself with the Notion API, a Slack app, and a scheduled function. Budget a few days for the first version and ongoing maintenance every time a property gets renamed. The build-versus-buy line here is not about capability, it is about who maintains the property mapping in eighteen months.

Where Skopx fits, and where it does not

Skopx is not a dashboard builder and not a BI tool. If what you want is a pixel-perfect Notion dashboard with drill-downs, this is the wrong category and you should look at the warehouse-plus-BI options covered in best business analytics software.

What Skopx does is different. It connects nearly 1,000 tools a company already uses, including Notion, Slack, Gmail, GitHub-style trackers, Stripe, HubSpot, QuickBooks and Google Analytics, and then:

Answers questions in chat with cited data. Instead of building the cross-tool report above, you ask for it: "list active projects in the Notion projects database with no Slack activity and no ticket movement in 14 days." The answer names the projects and cites where each fact came from, so you can check it.

Briefs you every morning. The staleness view you built in Notion only works if someone opens it. A morning brief inverts that: the findings arrive whether or not anyone remembered to look.

Surfaces insights without being asked. The insights engine watches for risks and anomalies across connected tools, which is how you catch the pattern nobody wrote a view for, such as three projects with the same owner all going quiet in the same week.

Runs workflows you describe in chat. The weekly check above is built by describing it, not by writing integration code, and it keeps running on its schedule.

Skopx uses your own AI key for any major model with zero markup, so model spend is billed directly by the provider rather than resold. Plans are Solo at $5 per month and Team at $16 per seat per month, listed on pricing.

What it will not do: it will not give you Notion page view counts, because Notion does not expose those through its API to anyone. It will not reconstruct history that Notion never stored. And it will not replace a warehouse if your real problem is modelling millions of rows.

A practical rollout, in the order that works

Stages one through four are free of new spend and are where most of the value is. Do not skip to stage five with a database whose Owner column is 40 percent empty, because cross-tool analysis on bad inputs produces confident nonsense.

Stage six is the step teams underrate. Reports that require someone to remember to open them decay to zero use within a quarter. Push beats pull for anything that matters, which is the same conclusion reached in real-time analytics platforms and in the retail context in retail intelligence software.

Frequently asked questions

Can I get Notion page view counts through the API?

No. Notion's public API covers content: pages, blocks, databases, data sources, properties, users, and comments. View counts and viewer lists shown in the Updates and Analytics panel are not exposed through it. If a vendor claims to pull Notion page analytics programmatically, ask precisely which endpoint they use before you believe it.

Which plan do I need for Notion workspace analytics?

Workspace-level analytics has historically been a Business and Enterprise feature, with the deepest reporting and audit capability on Enterprise. Page-level analytics is available more broadly, with retention and viewer detail improving as you move up. Notion adjusts plan packaging regularly, so confirm on their current comparison page rather than trusting any article, including this one.

How do I track how a Notion database changed over time?

Build it before you need it. Notion stores current property values, not a history of them, so the standard approach is a scheduled automation or script that writes a dated snapshot row into a separate log database: date, status counts, total open, total blocked. After a quarter you have a trend line. There is no way to reconstruct that history retroactively.

Is Last edited time reliable for finding stale work?

It is reliable for finding total abandonment and unreliable for finding slow decay. Any property change updates it, including a checkbox toggle or a card drag, so a project can look fresh while nothing real has happened. Pair it with an external signal such as tracker movement or channel activity before you treat it as a work signal.

Should I build Notion reporting in Notion or export it somewhere?

Keep it in Notion as long as the question is about one database and its relations, because native views cost nothing to maintain and live where the work happens. Move outside Notion the moment the question involves a second system, needs history Notion did not keep, or has to reach people who never open the workspace.

What is the single highest-value Notion analytics view to build first?

Percent empty on your required properties, on your most important database. It takes two clicks, it is unflattering, and it tells you whether every other report you were planning is worth building yet.