Page creation rate

Page creation rate is the number of new pages created over a defined period, usually expressed per week or per month. If a documentation team publishes 40 new pages in a month, the page creation rate is 40 pages per month, or about 10 per week. The unit can be raw pages, or pages per active contributor when you want to control for team size.

The metric matters because it is a direct measure of how fast a knowledge base, wiki, or content site is growing. A steady creation rate signals an active, contributing team. A rate that drops can mean the team has gone quiet, the subject is saturated, or the contribution process has become too painful to bother with. A rate that spikes can mean a migration, a content push, or low-quality bulk creation that will need pruning later.

Page creation rate is most useful when read alongside quality and engagement signals, not on its own. Creating many pages that no one reads or maintains is not progress. Tracked together with feature adoption rate and usage, creation rate becomes a measure of healthy growth rather than raw volume.

The calculation divides new pages by the length of the period. The work is in defining what counts as a new page and over what window, because loose definitions inflate the number and make trends unreadable.

1. 1

   New pages created

   The count of genuinely new pages published in the period. Decide whether drafts, templates, and auto-generated stubs count, and exclude them consistently if they do not represent real authored content.

2. 2

   The period

   The window over which you count, such as a week, sprint, or month. Keep the window consistent so week-over-week and month-over-month comparisons remain valid.

3. 3

   Active contributors

   The number of people who created at least one page in the period. Dividing new pages by active contributors gives a per-author rate that controls for team size and headcount changes.

4. 4

   Exclusions

   Migrated pages, duplicates, and machine-generated placeholders. Removing these isolates true creation from bulk events that would otherwise distort the trend.

Worked example: a team publishes 60 new pages in a four-week month, of which 12 are migrated from an old system. The genuine creation count is 48, giving a creation rate of 12 pages per week. If 8 people contributed, the per-author rate is 6 pages per person for the month. Tracking both the raw rate and the per-author rate matters, because a rising raw rate driven by one new hire is a very different story from a rising rate where every contributor is producing more.

A single creation rate tells you the pace but not what sets it. A metric tree decomposes the rate into the factors that drive output, and traces each factor to the team or process that controls it. This turns a volume number into a map of where growth is coming from and what would speed it up.

The first level splits creation rate into contributor activity, the ease of authoring, the demand for new content, and the quality gate that work must pass. Each branch decomposes further. Contributor activity is active authors multiplied by pages per author. Authoring ease covers template availability, tooling friction, and approval delay. Demand reflects open content gaps and inbound requests. The quality gate covers review time and rejection rate, which both slow the published rate even when authors are productive.

This structure lets you diagnose a change in the rate precisely. If creation slows, the tree shows whether fewer authors are active, the tooling got harder, demand dried up, or the review queue backed up. Each diagnosis points to a different owner and a different fix.

There is no universal benchmark for page creation rate, because the expected pace depends on the type of content and the maturity of the knowledge base. A new wiki grows fast, then naturally slows as the obvious pages get written. The ranges below give realistic orientation by stage, but your own trend over time is always the more reliable signal.

Read these ranges in context. A mature, well-covered knowledge base creating two pages a week may be perfectly healthy, while a brand new wiki at the same pace is stalling. The decline from rapid early growth to a steady trickle is normal and expected. What matters is whether the rate matches the stage and whether the team has the demand and tooling to sustain it.

Lifting creation rate sustainably means removing the constraint that is actually limiting output, not just asking people to write more. The metric tree tells you which branch is the bottleneck, and that is where the same effort returns the most new pages.

The metric tree approach starts by finding which branch is holding the rate down, then assigning a clear owner to relieve it. Tooling and the authoring experience sit with the platform team. Contributor growth sits with whoever owns the knowledge base programme. Content demand sits with the teams launching products and features. The quality gate sits with the reviewers and editors.

KPI Tree connects each creation driver to the team and the action that influences it, and pushes an alert to the accountable owner when their branch moves. When the review queue backs up or active authors fall, the person who can act sees their node change rather than discovering a slowing headline rate a month later. The verified impact loop then checks whether a change, such as a new template or a faster review process, actually lifted the rate, so the team learns what works rather than guessing.

1. 1

   Counting volume as value

   A high creation rate means nothing if the pages go unread or duplicate existing content. Always pair the rate with engagement and quality signals so output is not mistaken for progress.

2. 2

   Including migrated and generated pages

   Bulk migrations and machine-generated stubs spike the rate and hide the true pace of authored creation. Exclude them so the trend reflects real contribution.

3. 3

   Ignoring the per-author view

   A rising raw rate can be one prolific new hire rather than a healthier team. Tracking pages per active contributor reveals whether output is broad or concentrated.

4. 4

   Using an inconsistent period

   Switching between weekly and monthly windows, or comparing a four-week month with a five-week one, breaks the trend. Keep the period fixed so comparisons hold.

5. 5

   Tracking the rate without decomposing it

   A headline creation rate shows the pace but not the constraint. Without breaking it into contributors, authoring ease, demand, and the quality gate, every attempt to lift it is a guess.