Prepare to write data-informed documentation

Tue, 27 Oct 2026 10:27:00 +0000

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?

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

Support conversations. For example, transcripts of support chats in tools like Intercom or case descriptions and comments in tools like Zendesk or ServiceNow.
Search data. For example, search terms used on Google that lead to your documentation site available from Google Search Console or Bing Webmaster Tools, or search terms, result ranks, and clicked result data that you might have available in logs from your documentation site search.
Documentation feedback. For example, votes or ratings, comments, or discussions about specific pages, collected by your content management system or a homegrown solution.
Community forum questions and answers. For example, questions, comments, and feature requests (and the answers) posted on a community forum such as Discourse, or a chat tool like Discord or Slack.
MCP server interactions. For example, keywords used by AI agents to query your documentation on behalf of a user, collected by logging MCP server interactions on the server side.
AI chat conversations. For example, questions asked of an AI chatbot that has access to the documentation (through semantic search or retrieval-augmented generation (RAG)), and the generated responses.

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

Product telemetry data. For example, for a software product, click activity and session behavior for users in your product, collected by tools like Mixpanel, Heap, Pendo, Amplitude, or a homegrown solution.
Website analytics. For example, page views, referrer links, session and user IDs, and click activity, such as those collected by tools like Google Analytics or PostHog. If you distribute PDF-formatted files as documentation, determine if you collect download or access metrics for the files.

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

User research reports. For example, the results of research conducted about what users do when they get stuck in the product, the ease of navigating the documentation site, the clarity of the printed booklet, or other documentation-relevant research, collected by a qualified user researcher.
Customer satisfaction surveys. For example, net promoter score (NPS) surveys that include questions about or are specifically targeted to the documentation content, collected by a third-party survey company.
Product reviews. For example, standardized product reviews that might mention documentation, such as those collected by G2 reviews.

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

Content metadata. For example: last updated date, creation date, title, category, topic length, published version history, and more, collected by your content management system or git.
Documentation content. For example, the content of each topic, including the markup for each piece of content, collected by your content management system or git.
Ticket tracking data. For example, titles, descriptions, and metadata like closed date, created date, issue type, labels, affected customers, and more, collected by a ticket tracking tool like Jira, Linear, or Zendesk.

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:

What tools store the different data sources?
Do you have a data analytics tool?
Can you use that tool to easily process the data?
Is the data in the tool accessible to AI agents, such as through an MCP server?

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:

If you have a data analytics team, identify if they use a cloud data platform like Snowflake, Databricks, BigQuery, or Redshift to collect and analyze data.
Determine if you have access to a business intelligence tool that makes performing data analysis simpler for non-specialists, such as Sigma, Looker, Tableau, PowerBI, or others.

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.

Consider the following:

Do you know how to perform data analysis?
What types of analysis have you performed before?
Do you have access to a data engineer (or team) that can help collect and model data?
Do you have access to a data analyst (or team) that can help design and perform analysis?
Do you have access to mentors, training courses, books, or other resources to help you learn data analysis skills?

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.

Consider the following:

Do you have time to do anything besides write?
What kind of time do you have available for data tasks?
Do you have time to try data-informed documentation on one or more projects?
Do you have time to teach your colleagues about what you’ve learned?

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:

How likely is your manager, director, or higher-level leadership to invest in data access for a technical writer? What about tooling and training?
Is your leadership likely to support a time investment focused on delivering data-informed documentation, or more likely to wish that you’d spend your time elsewhere?
What metrics does your organization track, if any?
How data-literate is your management chain?
Are you frequently asked for a single metric that can be used to measure the success of documentation?

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

Basic

Growing

Defined

Mature

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.

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.

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.

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!

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.

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.

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.

analytics maturity model on This is important

Prepare to write data-informed documentation

Evaluate analytics capacity

Do you have data?

Do you have the tools?

Do you have the expertise?

Do you have the time?

Do you have support?

Identify your analytics capacity

None

Basic

Growing

Defined

Mature

Mythic

No analytics capacity

Basic analytics capacity

Growing analytics capacity

Defined analytics capacity

Mature analytics capacity

Mythic analytics capacity

Grow your analytics capacity

Start practicing data-informed documentation

Large project

Medium project

Small project