Prepare to write data-informed documentation

This is post 2 of 5 in the Data-informed documentation series. Start at the beginning: Practicing data-informed documentation.

How you can do data-informed documentation depends on your organization. The data sources available to you, tooling, expertise, support, and time all contribute to the available capacity of your organization to do data analysis, and thus to perform data-informed documentation.

Using data to inform every stage of every project of your documentation practice isn’t the right approach for every writer, or for every documentation team. For some writers, projects, or workflows, it might not make sense to add data.

If you don’t have the analytics capacity, investing in a full data-informed documentation practice might not be worth it right now. I say this not to scare you off, but to set you up for success.

Consider this post the prerequisites for doing data-informed documentation.

Evaluate analytics capacity #

Before you start practicing data-informed documentation, assess the analytics capacity of your organization.

The 2026 State of the Docs survey from Gitbook revealed that of the 1131 writers polled, 24% of them do not track any metrics at all. Company size also has an effect:

The measurement gap scales with company size. Medium companies (51–300 employees) are the worst at measurement — 32% track nothing, and those who track average just 1.7 metrics. Enterprise companies (301+) are the best with only 18% of teams tracking nothing.

If you’re one of those writers, that’s okay. You might be at a giant company but be one of those 18% with minimal-to-no data collected and no capacity for correlation across data sources. You might be at a tiny company with a robust data analytics workflow but very few documentation processes that let you take advantage of what you collect.

Depending on what kind of products you document, and how you provide your documentation to users, your analytics capacity can also be different. A SaaS software startup publishing docs on a website has access to different data than a large hardware company that publishes docs as PDF-formatted files or printed booklets included with the package.

To evaluate your organization’s analytics capacity, consider your resources:

Do you have data? #

If you want to practice data-informed documentation, you need data. What raw materials are you starting with?

Illustration of a stick figure wearing a cowboy hat. Their hand points to their chin and they are standing in front of a pile of gray rocks.

The following data sources provide details about customer and user behavior. For example, some data is submitted directly by customers :

Other data is quantitative and collected when users interact with your product or documentation site :

You might also have access to more ad hoc, qualitative data sources, often acquired through direct research or surveys :

Other sources provide details about your documentation, including how your documentation team is working :

The existence of the data is only part of the picture — you also need to evaluate if and how you can access it.

Do you have the tools? #

To most efficiently and effectively build a data-informed documentation practice, the data needs to be available in tools that make it easy to access, analyze, and correlate data sources. Consider the following:

Illustration of a stick figure in a cowboy hat gesturing toward an unfolded map. The map shows a path to a target, around a landscape dotted with trees and a river.

For example, many documentation-relevant data sources have their own data analysis views, like pre-built reports in Google Analytics or Mixpanel, already-aggregated page feedback and search term data available in a content management system, keyword search term data in Google Search Console, or tables and charts of analytics from your website hosting server.

Without effective data analysis tools, you can easily end up in a nightmare of exported, ad hoc Google Sheet-driven analysis. That can be sufficient for point-in-time analysis, answering a specific question at a specific time, but if you want to increase the analytics capacity of your data-informed practice, you need more effective tools:

Do you have the expertise? #

The existence of data and tooling isn’t enough to practice data-informed documentation effectively. You also need the expertise available to analyze the data and effectively apply it to your work.

Illustration of two stick figures, one with a construction hat and one with a cowboy hat. The construction hat figure has a pencil and is studying a folded paper. The cowboy is frowning with their hands on their hips.

Consider the following:

In addition to considering your level of expertise (and that of your organization) in preparation for data-informed documentation, consider your time.

Do you have the time? #

If you don’t have the time to practice data-informed documentation, access to data, tools, and sufficient expertise doesn’t matter.

Illustration of a stick figure in a cowboy hat working at an open laptop.

Consider the following:

Do you have support? #

Just like with time, if you don’t have organizational support to practice data-informed documentation, the other factors are irrelevant.

Consider the following:

Illustration of a stick figure in a cowboy hat holding the hat on their head and with a shrugging expression.

After considering your access to data and tooling, the existing expertise of yourself and your organization, the available time and support, you can identify the overall analytics capacity of your organization.

Identify your analytics capacity #

Based on your evaluation of your current resources, identify the overall analytics capacity of your organization. I’ve defined the different levels of analytics capacity as follows:

None

None

Basic

Basic

Growing

Growing

Defined

Defined

Mature

Mature

Mythic

Mythic

No analytics capacity #

Your organization collects no data at all, or what data exists is not reviewed or used in any way.

Data might be collected by your marketing team, and not available or shared with the documentation team. It might even exist in a tool that you can access, but can’t be exported and is pre-aggregated and can’t be easily interpreted or correlated.

As far as expertise, you don’t know how to effectively perform data analysis, and you don’t have the support to learn. If your organization employs any data analysts, they’re all too busy to work on documentation-relevant data tasks.

Overall, you don’t have time to do anything except research and write documentation. Getting even a few hours to try using data to inform a small project isn’t something you can prioritize. Maybe you’re an overburdened lone writer just trying to keep up with product releases and falling behind every minute.

You don’t have the bandwidth to review or make use of data, if you are collecting any. You simply don’t have the resources.

Illustration of a seed, representing no analytics capacity

At this level, other process improvements might be higher impact or higher priority than adding data or practicing data-informed documentation. More information isn’t the problem. Instead, you might focus on updating the release process to include clear documentation requirements and time allotments, or enabling internal and external stakeholders to contribute to the documentation so that you are not working alone.

To start building basic analytics capacity, see my post Where to start with analytics for documentation or Bob Watson’s post How you can make sense of your site analytics.

Basic analytics capacity #

Your organization collects basic site analytics data, such as page views and time on page, but doesn’t know how (or does not care) to use them to affect the documentation process.

Maybe your managers look at the data, but they’re only used as observability metrics to make sure that the site is up, or tracked as part of the company web properties overall. You haven’t built any custom views or explorations in Google Analytics, or poked around in Google Search Console.

Other data that you can access is whatever is available in the dashboard of your content management system — top 10 search terms of the last 30 days, thumbs up and thumbs down votes or ratings on specific documentation pages and accompanying comments.

Any expertise that you have in data analysis is self-driven training. There is no data team, no budget, and no time for official training. You’re comfortable looking at dashboards and reviewing trends, but that’s about it.

You take about an hour or two a quarter to make sure the data looks right and there aren’t any surprises, if that, but that’s about it. For the most part, you have some data, some tools, and minimal expertise, but you’re not really sure what to do with it.

Illustration of a flower bud, representing basic analytics capacity

If your organization is at this level, follow the guidance in my post Where to start with analytics for documentation or Bob Watson’s post How you can make sense of your site analytics before you try practicing data-informed documentation with quantitative data sources.

Growing analytics capacity #

Your organization collects quantitative site analytics data and qualitative documentation feedback. You might even correlate the site analytics data with feedback to identify high traffic pages receiving negative feedback.

At this level, you have access to your data, you’re aware of it, and you look at it.

However, your tooling might be limited to ad hoc data exports that you manipulate in Google Sheets with some basic formulas.

As far as expertise, maybe you have done some data analysis before, or someone else that you work with, but nothing complex. Building a data engineering pipeline or a semantic model with documentation-relevant data sources is beyond your capacity.

You have some time to work with analytics data too. Perhaps some dedicated time each week, or each month, to review specific documentation metrics and take action, like a triage rotation where you review page quality feedback for actionable improvements.

Illustration of a yellow flower with a few petals, representing growing analytics capacity

If you have growing analytics capacity, review the different data-informed projects and pick one that makes sense to try. Maybe you have access to detailed search term details, or have been wanting to dig in to the mysterious depths of MCP server usage logs, so you use data to inform a small-sized project to improve the findability of a recently updated page about a core feature.

Defined analytics capacity #

Your organization collects feedback metrics, possibly performs correlation with site analytics data, and also tracks business metrics relevant to documentation, like support chats closed with references to documentation or AI chatbot-driven support chat resolution.

In terms of data sources, you take advantage of the data that you get from site analytics tools and your content management system, and you seek out additional data sources across the company and through direct user research sessions.

Your data analysis tooling likely includes a modern data stack, like a cloud data warehouse to store and analyze data. You might even have access to a dedicated business intelligence tool for data analysis and modeling without needing to write SQL.

At this level, your organization likely employs a data engineer and/or analyst, and either you or a colleague have enough data analysis expertise to build charts and evaluate baselines for various documentation metrics.

You have dedicated time each week or month to review correlations between product releases and metrics for the supporting documentation pages, in addition to reviewing and processing documentation feedback data. You review search term trends in Google Search Console and your documentation site.

If your organization is at this level, you might be asked to define metric-based key performance indicators (KPIs) for your documentation. Your leadership is likely data literate, and you probably are too!

Illustration of a yellow flower with full petals, representing defined analytics capacity

If you have defined analytics capacity, plan to apply data-informed documentation to your next medium and large projects that make sense. It might be easiest to start with a large project (counterintuitively) due to the intensive planning often involved with a large project like a content restructure or product deprecation.

Mature analytics capacity #

At this level, you have access to multiple types of documentation-relevant data. Beyond what you get from website analytics and your content management system, you have access to product telemetry data, customer reviews, support chat transcripts, AI-powered conversations with an MCP server and a chatbot.

You have a robust data engineering pipeline, and probably a team managing it for you, along with effective tooling and modeling to make sense of the different data sources. On your own or with the support of a data analysis team, you can perform complex analyses like support case deflection and model user lifecycle activity across the product and documentation.

Each week, you have dedicated time to review unresolved AI chatbot conversations for documentation update opportunities, or have built out dedicated automation to do that reporting and categorization for you.

At this level, your data practice is fully developed. You’ve been instrumenting, monitoring, and analyzing different aspects of a well-defined customer journey for a long time.

With a mature analytics capacity level, you might even be done innovating on the product and instead innovating on the process to deliver product updates as efficiently as possible.

Illustration of a flower with petals in multiple shades of yellow, representing mature analytics capacity.

If your organization is at this level, you might be doing data-informed documentation in some cases already without calling it that. In reviewing the data-informed documentation framework, you might find opportunities to formalize or extend some existing data practices in your documentation processes, or otherwise identify gaps in time commitments or reporting that can help improve customer success with your content.

Mythic analytics capacity #

At this mythical level, your organization is able to write the perfect documentation for your users and provide exactly what they need. Your site displays only the relevant information to them based on the product configuration that they pay for.

You have access to every data source you can imagine, and probably some that don’t even exist yet. Your tooling is agent-driven automation that runs itself.

You have infinite resources to design and run analyses about anything you can imagine. You actually have someone on the team whose entire job it is to apply data to documentation-relevant challenges and do documentation analytics.

Illustration of a flower with every color of the rainbow in its petals, representing mythic analytics capacity.

At this level, the only documentation feedback you receive from your customers is requests for more examples.

Grow your analytics capacity #

After you identify the analytics capacity of your organization, start practicing data-informed documentation from where you are.

Whatever your current capacity, consider whether increasing your capacity or practicing data-informed documentation helps address your ultimate goal: Help customers successfully use the product.

If you have other priorities that can help you reach that goal more quickly, or with higher impact, then do those first.

This framework can offer you something no matter what analytics capacity your organization has: A guide as you mature your documentation processes, or incentive to collect different data sources.

You don't need to measure everything

Despite this being a post about preparing to practice data-informed documentation, I want to be extremely clear that the path to increased analytics capacity is not infinite data collection. It’s sometimes not worth the trouble to measure certain things.

In a post from quantitative user researcher Randy Au, Sometimes, stuff’s not worth measuring, he has some points very relevant to those of us doing more amateur analysis with limited data:

Seasoned researchers know that they’re making a complex trade between the richness of data being collected, the overall cost to do the data collection, the time needed to complete the work, the extent and confidence that results could be stated, the availability of willing study subjects, the technical feasibility of the data collection, the reliability and repeatability of the data collection. That’s not even a complete list, and on top of it all there’s potentially ethical, social, legal, and political concerns related to collecting data and doing the research.

If you have no analytics capacity, or very basic capacity, focus on starting somewhere relevant. Documentation feedback is an excellent example here. If you don’t have the time, or a plan or process to triage and act on documentation feedback, is it worth it to collect it at all?

The data isn’t everything. You can still write good documentation without data. You can still write bad documentation with tons of data.

We all have limited resources — focus your time and effort where it counts.

It’s also worth noting that as your organization grows its analytics capacity, such as by collecting more data sources, your starting level of expertise might not keep pace. Keep in mind your own professional development and seek out continued education, mentorship, or advocate for hiring a dedicated data analyst to help you continue delivering a high-quality data-informed documentation practice.

Start practicing data-informed documentation #

If you’re ready to start practicing data-informed documentation, pick a project:

Large project

For example, refocus a documentation set to split the content by audience and create an administrator guide, deprecate a major feature, or update dozens of pages for a UI redesign.

Medium project

For example, write content about a new interactive workflow to review and assign tickets to specific users, or a new type of widget that you can add to a dashboard.

Small project

For example, add a note that data displayed on a dashboard can have latency of up to 3 days, or update the privileges required to turn on a setting.

This post is part of the Data-informed documentation series.