Hi all,

I am quite sure that you already have heard about our Post Field Analysis feature, or at least have seen the menu item in your control environment. Most likely you have not used this feature yet, because it might look too complicated or you do not see the benefit of it. Or you never tried it out because the list of post fields is empty, simply because nobody ever added a post field. :)

This article is meant to help you understanding why Post Field Analysis are actually extremely powerful. This feature is capable to revolutionize the way you do your reports: If you decide to use it, you will see that you can create better reports in less time. But maybe we should start with the beginning...

What are post fields?

Think of a post field like a pre-defined, hidden list of tags. But unlike public tags, which can only be assigned to a topic, a post field is being assigned to a single comment. You can find the post field button under every comment on your community:
 

Once a Moderator visits that topic, he/she then can define (for example) what the post is about:

However, as post fields can be defined and structured according to your wishes, you can add whatever you find relevant to remember. Here are some of the post fields which are often use to track feedback:

- Sentiment
- Product type / Software version
- Type of comment (e.g. Review, Bug report, Question, Feature request, Support feedback)
- Type of request (e.g. a specific list of frequently requested features)
- Quality of the post (if a post is written nicely or if it is hard to understand)
- Report (e.g. to flag a comment to be included in a weekly report)

What is the advantage compared to "normal" tags?

The advantage of using them is that you can run reports on (combinations of) post fields in order to track your user activity extremely accurate.

For example, you want to know how often a certain issue has been reported in the past month. Usually you now would have to remember/find where this issue has been reported, and manually count the amount of users that reported it within this months.

With post fields, you can simply filter for all Bug reports which include this specific bug - in a matter of seconds. This enables you to create high-quality reports within a short amount of time, instead of manually sending / saving links to topics or comments which are relevant.

By applying an additional filter, you could even list only the reports of that specific bug which are written in a very nice manner (by adding the post field "comment quality"):

Once you have made your selection, you will see a list of all the comments where the combination of selected post fields have been found. You can then export this data and use it for your reporting.

Isn't it too much work to assign all these post fields to every comment on the community?

You don't have to assign all post fields to all comments on your community. You can also decide to only apply post fields to the most relevant comments. After a while you will have a good feeling of when a post needs to be logged in the post fields, and when not. You can chose to track certain post fields for every comment (e.g. sentiment), but that is all up to you.

I personally have made the experience that adding post fields usually only takes a few seconds per comment. Furthermore, I have saved a lot of time for the creation of reports: I now have a list of all relevant comments at hand, so I do not need to invest time time to "hunt" for good quality comments on my community...

How can I define my own post fields?

For a technical reference, please visit our How-to topic.

I recommend that you think carefully about what you want to track before you set up your post fields: Try to find what characteristics you want to share across the entire community, and which items are rather specific to a certain subforum. Especially when you are having a diverse product and service portfolio, this will make your life (and the life of your colleagues) a lot easier.

An example: A company is selling iPhones and Android Smartphones. Rather than having seperate post fields for issues on each model ("Bugs iphone" and "Bugs Android"), add one post field that defines the product ("Product type) and another one which lists potential issues ("Bug type").

Some last things that you might want to know

• Deleted is deleted: Never delete a post field if it has been used. Once you delete a post field, you will also not be able to use it in your analytics. Rather hide it from all subforums to be displayed.
• Watch the order: Post fields are following a strict alphabetical order. Use numbers or letters to adjust the order to your liking. Most frequently used post fields should be located in the top row.
• Leave space for exceptions: Use a mix of post field lists (e.g. "feature request" for more frequently requested improvements) and free-text fields for more uncommon requests or reports.
• Update when necessary: When you see a certain report coming back more often, update your post field and add that bug/request to your pre-defined list. This will save time in the long run and make your feedback more accurate.

In case you want to learn more about this, you can find the complete whitepaper of this feature here: http://bit.ly/2wZbFYm

I hope that this article will help some of you on the way to start using this feature. There are many more ways how post fields can be used... It would be great to hear from you in case you are doing something completely different with it, also in case you have any questions or concerns around this!

Cheers,

Julian