How to Use Article Feedback Analytics

SoftwareRoad Knowledge Base can collect simple Yes and No responses from visitors at the end of each article.

The Article Feedback Analytics report brings these responses together so you can see which guides are helping and which may need another look.

Feedback is most useful when it is considered alongside article views, search activity and the actual content of the guide.

Open Article Feedback Analytics

To review article feedback:

1. Sign in to your WordPress dashboard.
2. Open Knowledge Base > Analytics.
3. Select the Article Feedback section.
4. Review the Yes and No totals for each article.
5. Open any article that appears to need attention.

Only articles that have received feedback will have meaningful totals.

What the report can show

Depending on the current plugin version, the report can include:

• Article title
• Yes responses
• No responses
• Total responses
• Helpfulness percentage

For example:

Article	Yes	No	Helpful
How to Install SoftwareRoad Knowledge Base	22	2	92%
Fix Licence Details Not Recognised	6	8	43%
How to Change the Knowledge Base Logo	9	1	90%

The licence troubleshooting article would be the first one worth reviewing.

How the helpfulness percentage is calculated

The helpfulness percentage is based on the number of positive responses compared with the total number of responses.

For example:

• Yes: 8
• No: 2
• Total responses: 10
• Helpfulness: 80%

A higher percentage generally suggests that more visitors found the article useful.

The percentage should not be considered on its own.

Always check the number of responses

An article with one Yes vote and no No votes may show 100% helpful.

That does not provide enough information to confidently judge the article.

Compare:

Article A

• Yes: 1
• No: 0
• Helpful: 100%

Article B

• Yes: 80
• No: 10
• Helpful: 89%

Article B has a lower percentage, but the larger number of responses gives you much stronger evidence that the guide is working well.

Wait for a reasonable number of responses before making major decisions.

Compare feedback with article views

Feedback totals become more useful when compared with article views.

For example:

Article A

• 2,000 views
• 10 No responses

Article B

• 80 views
• 10 No responses

The same number of negative responses means something very different in each case.

Article B may have a much higher proportion of visitors who did not find it useful.

Article A may simply have received more negative responses because it has considerably more traffic.

High views and poor feedback

An article with many views and a large number of No responses should be reviewed first.

This usually means:

• The subject is important
• Visitors are finding the article
• The current guide is not fully answering the question

Check whether:

• The title matches the content
• The main answer appears early enough
• The steps match the current plugin version
• Important errors are covered
• Screenshots are still accurate
• The guide is trying to cover too much
• Visitors may be opening the wrong article

Improving a high-traffic article can help a large number of visitors.

High views and good feedback

A frequently viewed article with strong positive feedback is doing its job well.

You do not need to rewrite it unnecessarily.

Continue checking it for:

• Outdated screenshots
• Changed setting names
• Broken links
• New plugin behaviour
• Old version references
• Missing troubleshooting notes

Successful articles still need occasional maintenance.

Low views and poor feedback

An article with little traffic and poor feedback may have more than one problem.

It could be:

• Difficult to find
• Poorly titled
• Outdated
• Too narrow
• Duplicated elsewhere
• Assigned to the wrong category
• Covering a feature that has changed

Open the article and decide whether it should be:

• Improved
• Renamed
• Combined with another guide
• Replaced
• Redirected
• Removed from normal knowledge base navigation

Do not delete a published article without checking whether other pages or websites link to it.

Low views and good feedback

A low-traffic article with positive feedback may be useful but difficult to discover.

Check whether:

• The title uses wording visitors understand
• It is assigned to the correct category
• Knowledge base search can find it
• Related articles link to it
• An automatic article link would help
• It should appear in Popular Searches
• It has accidentally been marked as unlisted

The content may not need changing at all.

Look for repeated negative patterns

One No vote is not enough to conclude that an article is poor.

Look for repeated patterns such as:

• No responses increasing over several weeks
• Several related articles receiving poor feedback
• The same guide receiving negative feedback after a plugin update
• An article with a much lower helpfulness rate than similar guides
• Negative responses continuing after small improvements

Patterns are more useful than individual votes.

Review the article as a new visitor

When an article receives poor feedback, read it without assuming prior knowledge.

Ask:

• Does the title clearly describe the problem?
• Does the opening paragraph explain what the guide covers?
• Are the steps in the correct order?
• Are button names written exactly as shown in WordPress?
• Are any important steps assumed rather than explained?
• Can the answer be found quickly?
• Does the article explain what should happen after each step?
• Are common errors included?

An instruction that feels obvious to the author may not be obvious to a new customer.

Check whether the title creates the wrong expectation

Visitors may select No because the article did not cover what they expected from the title.

For example:

Licence Help

could mean activation, billing, product keys or licence errors.

A clearer title would be:

How to Activate SoftwareRoad Knowledge Base

or:

Fix Licence Details Not Recognised

The more precise the title is, the more likely the right visitor is to open the article.

Move the main answer closer to the top

A visitor may leave negative feedback even when the answer exists further down the page.

Long introductions can make simple answers difficult to find.

For a troubleshooting article, consider starting with:

1. What the error means
2. The most likely fix
3. Clear steps
4. Additional causes
5. Further troubleshooting

Supporting background can appear afterwards.

Use clear headings

Headings help visitors scan the article before reading every paragraph.

Useful troubleshooting headings include:

• Check Your Purchase Email
• Check the Product Key
• Confirm the Correct Subscription
• Test the Licence Connection
• Clear the Saved Licence Details
• Contact Support

Avoid headings such as:

• Other Information
• More Details
• Important
• Next Steps

A visitor should be able to understand the article by quickly scanning the headings.

Add a table of contents

A table of contents can make a longer article easier to use.

It is especially helpful when a guide includes:

• Several possible causes
• Different error messages
• Multiple setup methods
• Desktop and mobile instructions
• Detailed troubleshooting steps

Visitors can jump directly to the section that matches their problem.

Check search wording

Open Search Analytics and look for searches connected to the article.

For example, an article may be titled:

How to Activate Your Licence

but visitors may search for:

• key not working
• activation code error
• licence not recognised
• invalid product key

Include common visitor wording naturally in the article where it is relevant.

This can improve both search results and visitor expectations.

Review searches with no results

A visitor may open the closest available article even when it does not actually cover their problem.

This can lead to negative feedback.

For example, visitors searching for:

move licence to another website

may open the general activation guide because no dedicated migration article exists.

In this case, it may be better to create a new article rather than keep expanding the existing one.

Decide whether the article is too broad

A broad guide may try to answer several different questions.

For example, one article covering all of the following could become difficult to use:

• Installation
• Activation
• Licence checks
• Subscription renewals
• Product key errors
• Website migration

It would usually be clearer to split these into separate guides.

Focused articles are easier to:

• Search
• Scan
• Link to
• Update
• Recommend
• Troubleshoot

Decide whether the article is too short

Some guides receive poor feedback because they only point out where a setting is located.

A useful article may also need to explain:

• What the setting does
• How to change it
• What value to enter
• What the visitor should see afterwards
• Common mistakes
• How to undo the change
• What to do when it does not work

Add information that helps visitors complete the task rather than adding text simply to make the article longer.

Check the instructions against the current plugin

Software changes can quickly make documentation inaccurate.

Review whether the article still uses the correct:

• Menu names
• Tab names
• Button text
• Field labels
• Licence options
• Shortcodes
• URL settings
• Screenshots

Even a small mismatch can make visitors think they are in the wrong place.

Update screenshots

A screenshot can become misleading after the interface changes.

Replace it when:

• A setting has moved
• The layout has changed
• The button wording is different
• New fields have been added
• Old options have been removed
• The screenshot includes an outdated plugin version

Crop screenshots so the important area is easy to see.

Add expected results

After an important step, explain what should happen.

For example:

After selecting Save Changes, open the knowledge base homepage. The new title should appear above the search box.

This helps visitors confirm that they completed the step correctly.

It also makes it easier to identify where something went wrong.

Add common problems

A short troubleshooting section can prevent negative feedback.

For example:

• The setting is not showing
• Changes are not appearing
• The article returns a 404 error
• The licence is not recognised
• The image is not loading
• The website cache still shows the old design

Focus on problems that visitors are genuinely likely to encounter.

Add a useful next step

Sometimes an article cannot cover every possible situation.

Give visitors somewhere useful to go next, such as:

• A related troubleshooting article
• A recommended guide
• The knowledge base search
• A support page
• A contact form
• The help box

A visitor may still select No when their exact problem was not solved, but a clear next step reduces frustration.

Use automatic article links

Automatic links can connect recurring terms to more detailed explanations.

For example, an article mentioning a product key can automatically link to the guide explaining where to find it.

This lets the main article stay focused without repeating the same background information.

Make changes in manageable stages

When an article receives poor feedback, avoid rewriting everything without knowing which part caused the problem.

Start with the most likely improvements:

1. Correct outdated instructions.
2. Improve the title.
3. Move the main answer higher.
4. Add clearer headings.
5. Add common troubleshooting steps.
6. Improve internal links.

Then watch how future responses change.

Make a note of the update date

When you improve an article, record when the change was made.

This helps you separate feedback received before and after the update.

For example:

• Article updated: 1 July 2026
• Review new responses from that date onwards

The dashboard may continue showing lifetime totals, so older responses can still influence the displayed percentage.

Old feedback remains after an update

Updating an article does not normally remove its previous feedback totals.

This means a greatly improved article may still show a low historical percentage for a while.

Look at:

• New responses after the update
• Whether No votes are slowing down
• Whether support questions decrease
• Whether search results improve

A long-term total can take time to reflect the rewritten article.

Should feedback be reset?

Resetting feedback can give you a clean starting point after a complete rewrite, but it also removes useful history.

Before clearing anything, consider:

• Whether the article changed substantially
• Whether you need the old totals for comparison
• Whether a website backup exists
• Whether only test responses are being removed
• Whether the plugin version provides a suitable reset option

Do not clear live feedback simply because one article has a poor score.

The data is useful because it draws attention to possible problems.

Use feedback to prioritise your time

You may not be able to update every guide at once.

A practical order is:

1. High-view articles with poor feedback
2. Articles with repeated No responses
3. Articles linked to frequent no-result searches
4. Important setup and licence guides
5. Outdated articles with moderate traffic
6. Low-traffic specialist articles

This focuses your work where it can help the most visitors.

Compare similar articles

Compare articles covering similar types of tasks.

For example:

• Installation guides
• Licence guides
• Design settings
• Analytics articles
• Troubleshooting guides

If most setup guides receive strong feedback but one performs poorly, review what is different about that article.

It may have:

• Fewer screenshots
• A vague title
• Missing steps
• Outdated wording
• A more complex task
• Poor category placement

Do not compare unrelated subjects too closely

A short article explaining one simple setting may naturally receive different feedback from a complicated troubleshooting guide.

Some subjects are harder to resolve because the problem can have several causes.

Use feedback to improve the article, but do not expect every guide to have identical results.

Feedback does not explain why

The Yes and No buttons provide a quick result, but they do not tell you exactly why someone responded negatively.

Use other information to investigate:

• Search terms
• Article views
• Support emails
• Common customer questions
• Plugin changes
• Broken links
• Your own testing

Feedback is a signal that an article may need attention, not a complete diagnosis.

Test the article after making changes

After updating an article:

1. Open it while signed out of WordPress.
2. Read it from the beginning.
3. Follow the steps exactly.
4. Test every link.
5. Check the table of contents.
6. Check images on desktop and mobile.
7. Make sure the feedback buttons still work.
8. Clear the website cache.

Do not assume the article works correctly simply because it looks right in the editor.

Feedback Analytics is empty

The report will remain empty until visitors respond to the article feedback question.

Check that:

• Helpful Article Feedback is enabled
• The prompt appears on published articles
• Yes and No buttons work
• Your licence is active
• Visitors can access the articles
• JavaScript is working

Run one test while signed out if needed.

Responses are not updating

If a new vote does not appear:

1. Refresh the Analytics page.
2. Clear the WordPress cache.
3. Test while signed out.
4. Check that the button displayed a confirmation.
5. Test another browser.
6. Check for JavaScript errors.
7. Confirm that the licence is active.

Avoid submitting many test responses because they can distort the real totals.

The percentage appears incorrect

Calculate the result using:

Yes responses ÷ Total responses × 100

For example:

7 ÷ 10 × 100 = 70%

Small differences may be caused by rounding.

Make sure you are comparing the Yes total with all responses, not only the No total.

One article has an unusually high number of responses

This may happen because:

• It receives more traffic
• It is linked from a popular page
• It covers a common problem
• It was shared in an email or support reply
• Visitors are more motivated to respond
• It is being repeatedly tested

Compare its feedback with its view total before drawing conclusions.

Feedback Analytics and privacy

Helpful feedback is designed to record Yes and No totals without requiring visitors to enter names or email addresses.

Your privacy policy should still mention the feature when it is enabled.

Explain that responses are used to understand whether documentation is useful and to improve articles.

Only trusted WordPress users should have access to the Analytics dashboard.

A practical feedback review routine

A simple monthly review could include:

1. Find articles with the most No responses.
2. Compare them with article views.
3. Check recent searches connected to those topics.
4. Open the three articles needing the most attention.
5. Correct outdated instructions.
6. Add missing troubleshooting information.
7. Record when each article was updated.
8. Review the new responses during the following month.

Small regular improvements are easier to manage than rewriting the whole knowledge base at once.

Article feedback checklist

Before finishing your review, check that:

• The total number of responses has been considered
• Feedback has been compared with article views
• Repeated patterns have been prioritised
• Search wording has been reviewed
• Titles match visitor expectations
• Instructions match the current plugin
• Main answers are easy to find
• Screenshots are accurate
• Common problems are covered
• Visitors have a useful next step
• Changes have been tested while signed out
• The update date has been noted
• Privacy information reflects the feedback feature

Article Feedback Analytics can now help you focus your documentation work on the guides where improvements are most likely to benefit visitors.