You use Ascribe™ Rule Sets to modify the output of the text analytics engine, introduce your own findings to the text analytics results, and to modify comments as they are loaded into Ascribe.  You can also use Rule Sets with the Ascribe Coder API to modify responses as they are loaded to Ascribe.

Rule Set Workflow

The diagram below shows the execution workflow for a Rule Set:

When you load data into CX Inspector the entire workflow is executed.  When you apply a Rule Set after data are loaded into an Inspection execution begins with the stored responses and findings, and the Modify Response on Load rules are not executed.  When you use a Rule Set with the Ascribe Coder API only the Modify Response on Load rules are executed.

Rules Operating on Responses

Modify Response on Load rules and Add Finding from Response rules operate on responses.  They are not passed any of the output from linguistic analysis.

Modify Response on Load Rules

Ascribe executes Modify Response on Load rules only when you load data.  You can modify the responses as they are loaded, and the modified responses will be stored in Ascribe.  You can also veto responses, causing them to be ignored and not loaded in Ascribe.

Ascribe executes these rules in the order they are defined in the Rule Set.  The output of each rule is passed to the next, and the output of the last rule is stored in Ascribe.  If any rule vetoes a response the response is discarded, and any remaining rules are not executed for that response.

Add Finding from Response Rules

Ascribe executes Add Finding from Response rules both when you load data, and when you apply a Rule Set to an Inspection after loading data.

These rules contribute findings to the analysis, just like the linguistic processing engine does.  You use these rules to supplement the analysis with findings you create in your rules.  Ascribe sends all the responses for the variables you have selected for analysis through these rules.   Therefore, you can add findings to the analysis even for responses that produced no findings from linguistic analysis.  Contrast this with Add Finding from Finding rules, which operate on the findings from the linguistic analysis.

When you add findings to an analysis with these rules, those added findings are not passed through the rules operating on findings.

Rules Operating on Findings

Modify Finding, Veto Finding, and Add Findings from Finding rules operate on findings from linguistic analysis.  They work as a pipeline, where each finding is passed through all the enabled rules for each of these Rule types:

Modify Finding ⇒ Veto Finding ⇒ Add Finding from Finding

CX Inspector stores the findings emitted from this pipeline, plus the findings contributed by Add Finding from Response rules, as the processed findings.  CX Inspector displays the processed findings in its user interface.

Modify Finding Rules

Ascribe executes Modify Finding rules in the order they are defined in the Rule Set.  Each rule can modify the finding or pass it along unchanged.  The output of each rule passes to the next, and the output of the last rule passes to the Veto Finding rules.

Veto Finding Rules

Veto Finding rules cannot modify the finding.  The rule can veto the finding or allow it to continue through the pipeline.  If the finding is vetoed the finding is discarded and the remaining rules in the pipeline are short circuited for that finding.

Add Finding from Finding

You can add new findings to the analysis based on the results of linguistic processing with Add Finding from Finding rules.  These rules cannot modify the finding they are given, but they can add one or more new findings.  Because these rules have access to the finding from linguistic analysis they can make decisions using these results.

Although the rule has access to the response text, it should not add findings based on inspection of response alone.  First, the rule will not receive responses unless the linguistic engine produced a finding for the response.  Second, the rule will likely receive findings for the same response multiple times, because many responses generate multiple findings during linguistic analysis.

Next Steps

You can best harness the power of Rule Sets by understanding their execution workflow.  See Authoring Ascribe Rule Sets for information about how to create rules, and Rule Set Examples for sample code.

The Ascribe™ Coder API allows your company to send survey responses to Ascribe and retrieve back the codebooks and coded responses. Using the Ascribe Coder API you can create a study, create questions in the study, load responses to be coded to the question, and get the results of the coding.Before you can interact with the Ascribe Coder API you must authenticate. See this post for details.The API interactions for this workflow are:

1. POST /StudiesCreate a new study. Its key is returned.
2. POST /Questions/{StudyKey}Create a new question in the study. Its key is returned.
3. POST /Responses/{QuestionKey}Put responses to be coded into the question.
4. Humans code the responses, creating a codebook as they code.
5. GET /Studies/{StudyKey}Query for completion of the coding work. Repeat at intervals until coding is complete.
6. GET /Codebooks/Question/{QuestionKey}Get the codebook constructed by the coders.
7. GET /Responses/{QuestionKey}Get the coding results.

Let’s go through each of these operations a step at a time.

Create a Study with the Ascribe Coder API

Assuming that we want to create a new study in Ascribe we POST to the /Studies resource. The body of the request looks like this:{
"id": "S458-3"
}This creates a new study with the ID S458-3. The ID can be any text. The API responds with:{
"key": 544,
"id": "S458-3",
"status": "p"
}The status of "p" means that coding is in progress. This is an indication to the coding team that this job needs to be coded. The key returned is important. That is how we will refer to the study in subsequent interactions with the API.If we don’t want to create a study, but would rather add a new question to an existing study, we can query the /Studies resource to find the study key given the study ID.

Create a Question with the Ascribe Coder API

Armed with our study key, 544 in the example above, we can create a question in the study. To create the question, we POST to the /Questions/{StudyKey} resource, so in our case we POST to /Questions/544. The body of the request looks like this:{
"id": "Q1",
"type": "o",
"text": "What did you like about the product?"
}This creates a new Open question ("type": "o"), with ID “Q1”. The response has this form:{
"key": 3487,
"id": "Q1",
"type": "o",
"text": "What did you like about the product?"
}Now we have the key for the newly created question, and we are ready to load it with responses to be coded.

Load Responses to Code with the Ascribe Coder API

To load responses, we POST to the /Responses/{QuestionKey} resource, so for the example above we would POST to /Responses/3487. The body of the request would look like this:{
"responses": [
{
"rid": "34-22907",
"verbatim": "I do not like the red color"
},
{
"rid": "34-22988",
"verbatim": "This is a fantastic product"
}
]
}And the response:{
"responsesAdded": 2,
"existingResponsesUnchanged": 0
}Each response in the array of responses sent to the API must have the rid (respondent ID) and verbatim properties set to strings of one character or more. The rid values must be unique within the array of responses. If the rid value for a given response is already present in the question in Ascribe the response will be ignored. If we do exactly the same POST again to the API, the response would be:{
"responsesAdded": 0,
"existingResponsesUnchanged": 2
}This is because the respondent ID’s are already present in the question.You should limit the number of responses sent in a single POST to 1000 or so. If you have more responses to load into the question than that, send them in separate POST operations.

Human Coding

The coding team can now get to work on the question. As the coders do their work they will add codes to the codebook for the question. Once coding of all the questions in the study is complete the coding team will set the status of the study to Completed.When the coding team has set the status of the study to Completed it is the signal that the coding results are available for retrieval via the API.

Polling for Completion of Coding with the Ascribe Coder API

You can test for completion of the coding work with a GET to the /Studies/{StudyKey} resource. Our study key is 544, so we need to GET from /Studies/544. The response looks like this:{
"key": 544,
"id": "S458-3",
"status": "p"
}Whoops! The coding is not yet complete, because the status is "p", meaning coding in progress. Wait for a while and try again, until the status is "c", meaning completed. Now we can get the coding results.

Retrieving a Codebook with the Ascribe Coder API

We need two things to collect the results of coding. The codebook and the codes applied to each response. We can retrieve these in either order. To get the codebook we GET from the /Codebooks/Question/{QuestionKey} resource. In our example we would GET /Codebooks/Question/3487. The response has this form:{
"codebookKey": 1499,
"codebook": [
{
"key": 528,
"description": "Not like red",
"outputId": "201"
},
{
"key": 529,
"description": "Fantastic product",
"outputId": "202"
}
]
}This codebook contains only two codes. Each has a key, textual description as displayed in the codebook, and an outputId. The output ID identifies the code for the tab department. But to associate these codes with the coding results from the API we want the code keys, 528 and 529.

Retrieving Coding Results with the Ascribe Coder API

The final operation in our workflow is to get the results of the coding. We GET from the /Responses/{QuestionKey} resource. The response has this form:{
"responses": [
{
"rid": "34-22907",
"codeKeys": [
528
]
},
{
"rid": "34-22988",
"codeKeys": [
529
]
}
]
}The coders have applied code 528, “Not like red”, to respondent "34-22907". 528 is the key of the code in the codebook. The other respondent has received the “Fantastic product” code. While each response in this example has only one code applied, in general any number of code keys can be returned in the codeKeys arrays.Note that the text of the responses is not included in the response to reduce the payload size. If you want the response text you can set the includeText property in the request body to true. The response would then look like this:{
"responses": [
{
"rid": "34-22907",
"text": "I do not like the red color",
"codeKeys": [
528
]
},
{
"rid": "34-22988",
"text": "This is a fantastic product",
"codeKeys": [
529
]
}
]
}

Summary

The Ascribe Coder API can be used to automate the workflow in your coding department. You can send responses to be coded to Ascribe and retrieve the results of the coding operation.See the Ascribe Coder API documentation for information on how to automate coding of responses as they are sent to Ascribe.

The various Ascribe™ APIs, such as the Ascribe Coder API, share a common authentication operation. You authenticate with the API by a POST to the /Sessions resource. To interact with any of the other resources in the APIs you must include a token returned in the POST response in an HTTP header.

Obtaining an Authentication Token

To obtain an authentication token, POST to the /Sessions resource. The body of the POST request contains the login credentials for an Ascribe user: Account, Username, and Password. The body of the POST request has this form:{
"account": "MyAscribeAccount",
"userName": "apiuser",
"password": "--------"
}Here we are authenticating as with the user name apiuser, on the MyAscribeAccount. We recommend that you create an Associate in Ascribe exclusively for the API. This is because the time accounting features of Ascribe will attribute activity initiated via the API to this user. This makes interpretation of the time accounting reports easier.The POST response has this form:{
"authenticationToken": "0e2338c4-adb4-474a-a26a-b9dbe1b32ac8",
"bearerToken": "bearer eyJhbGciOiJSUzI1NiIsInR5cC ... WiiVzXPhdgSWNvH1hNOIirNmg"
}The value of the bearerToken property is actually much longer than shown here. You can use either of these tokens (but not both) in subsequent operations with the API.

Differences between the Token Types

The authenticationToken returned by the /Sessions resource expires after 30 minutes of inactivity with the API. In other words, you must perform an operation with the API at least once every 30 minutes. After that you must obtain another token from the /Sessions resource. The token will remain valid indefinitely if you do make a request at least once every 30 minutes.The bearerToken does not expire. Once you have obtained a bearerToken it will remain valid until the login credentials of the user are changed.

Using Authentication Tokens

To use the authenticationToken returned by the /Sessions resource, include it in an HTTP header. The key of the header is authentication, and the value is the authenticationToken. The raw HTTP request looks like this:GET /coder/studies
accept: application/json, text/json, application/xml, text/xml
authentication: 207e5be1-c3fa-4ff6-bbc7-475a367ec095
cache-control: no-cache
host: webservices.languagelogic.net
accept-encoding: gzip, deflateTo use the bearerToken, use an HTTP header whose key is “authorization” and value the bearerToken. The raw HTTP request looks like this:GET /coder/Studies
accept: application/json, text/json, application/xml, text/xml
authorization: Bearer eyJhbGciOiJSUzI1NiI ... lJqc7nPxcFdU3s90BkOPlPF6wTxkzA
cache-control: no-cache
host: webservices.languagelogic.net
accept-encoding: gzip, deflate

Summary

The Ascribe APIs require the remote client to authenticate. The remote client authenticates by providing user credentials, and uses one of the two tokens returned in subsequent operations with the API.See the Ascribe Coder API documentation, and the Ascribe CX Inspector API documentation for more information.

If your company has customers in more than one country you are likely faced with analysis of customer feedback in multiple languages.  CX Inspector can perform text analytics in several languages and can translate customer responses in any language to one of the supported analysis languages.

Supported Analysis Languages

CX Inspector can perform text analytics in these languages:

• Arabic
• Chinese (both Simplified and Traditional)
• English
• French
• German
• Italian
• Japanese
• Korean
• Portuguese
• Russian
• Spanish

The language that you select for the analysis language determines the language you will see when looking at the Inspection.  If the comments you are loading are not in the language that you select for the analysis, then the comments will be translated to that language.

Loading Multilingual Comments

CX Inspector detects the language in each question when you load new data.  For example, if I load Russian comments CX Inspector will present these options for the analysis language:

CX Inspector has detected that the comments are Russian and will not translate the responses because the selected analysis language is also Russian.  I can inform CX Inspector that it has incorrectly determined that all the comments are Russian by checking the box force translation.  When I load the comments with Russian selected as the analysis language the Inspection results will be presented in Russian.

If I instead select German as the analysis language:

CX Inspector will now translate the comments to German, and then perform text analytics in German.  The Inspection results will be presented in German.

During translation CX Inspector performs language detection on each comment individually, so it is fine to have a mixture of different languages in the comments.

Multilingual Analysis Scenarios

Let’s look at three scenarios:

1. Jean is a researcher in France, with data from a survey conducted in French only. His client is a French company.
2. Albert is a researcher in the U.K. His client is a London bank that is considering a German presence.  He has conducted a survey in Germany for that client.
3. Samantha is a researcher in the U.S. Her client is a global CPG company based in the Midwest.  She has conducted a survey in 12 countries for that client.

What is the best approach for each of these researchers using Inspector?

Jean speaks French, his client is French, and he has French data.  Jean clearly should select French as the language when running an analysis.  He does not need the translation features of CX Inspector.

Albert is in a different position.  He could perform an analysis in German.  But what use is that?  If Albert speaks German, he might be able to interpret the results.  But what about Albert’s client in the U.K.?  The client probably wants to see the analysis, and the comments, in English.  Albert is probably better off translating the responses to English, then running the analyses in English.  He can automatically translate the responses, then do all his work in English.  Albert can now present the results to his client in English.

Samantha has a more complex problem.  Like Albert, she will likely want to perform analyses in English.  But she has 12 languages to deal with.  Samantha can simply select English as the analysis language.  The language of each comment will be detected at translation time; all the comments will be translated to English, analyzed in English, and presented in English.

How many languages are supported?

CX Inspector can perform text analytics and present its results in the languages listed at the top of this article.  But CX Inspector can work with comments in any language, provided only that the comments are automatically translated to one of the supported analysis languages.

Coding Open-Ended Questions

Verbatim coding is used in market research to classify open-end responses for quantitative analysis. Often, verbatims are coded manually through software such as Excel, however, there are verbatim coding solutions and coding services available to streamline this process and easily categorize verbatim responses. 

Survey Research is an important branch of Market Research. Survey research poses questions to a constituency to gain insight into their thoughts and preferences through their responses.  Researchers use surveys and the data for many purposes: customer satisfaction, employee satisfaction, purchasing propensity, drug efficacy, and many more.

In market research, you will encounter terms and concepts in data specific to the industry. We will share some of those with you here, and the MRA Marketing Research Glossary can help you understand any unknown terms you encounter later.

Seeking Answers by Asking Questions

Every company in the world has the same goal: they want to increase their sales and make a good profit. For most companies, this means they need to make their customers happier — both the customers they have and the customers they want to have.

Companies work toward this goal in many ways, but for our purposes, the most important way is to ask questions and plan action based on the responses and data gathered.  By “ask questions,” we mean asking a customer or potential customer about what they care about and taking action based on the customer feedback.

One way to go about this is to simply ask your customers (or potential customers) to answer open ended questions and gather the responses:

Q: What do you think about the new package for our laundry detergent?
A: It is too slippery to open when my hands are wet.

This technique is the basis of survey research.  A company can conduct a questionnaire to get responses by asking open ended questions.

In other cases, there may be an implied question and response.  For example, a company may have a help desk for their product.  When a customer calls the help desk there is an implied question:

Q: What problem are you having with our offering?

The answers or responses to this implied question can be as valuable (or more!) as answers and responses to survey questions.

Thinking more broadly, the “customer” does not necessarily have to be the person who buys the company’s product or service. For example, if you are the manager of the Human Resources department, your “customers” are the employees of the company. Still, the goal is the same: based on the feedback or response from employees, you want to act to improve their satisfaction.

Open, Closed, and Other Specify

There are two basic types of data to gather responses in survey research: open and closed.  We also call these open-end and closed-end questions.

A closed-end question is one where the set of possible responses is known in advance.  These are typically presented to the survey respondent, who chooses among them.  For example:

Open-end questions ask for an “in your own words” response:

The response to this question will be whatever text the user types in her response.

We can also create a hybrid type of question that has a fixed set of possible responses, but lets the user make an answer or response that was not in the list:

We call these Other Specify questions (O/S for short).  If the user types a response to an O/S question it is typically short, often one or two words.

Just as we apply the terms Open, Closed, and O/S to questions, we can apply these terms to the answers or responses.  So, we can say Male is a closed response, and The barista was rude is an open response.

What is an Answer vs a Comment?

If you are conducting a survey, the meaning of the term answer is clear. It is the response given by the respondent to the question posed. But as we have said, we can also get “answers” to implied questions, such as responses to what a customer tells the help desk. For this reason, we will use the more generic term comment to refer to some text or responses that we want to make an examination for actionable insight.

In most cases, comments are electronic text, but they can also be images (handwriting) and voice recording responses.

You need to be aware of some terminology that varies by industry. In the marketing research industry, a response to a question is called either a response or a verbatim. So, when reading data in survey research we can call these responses, verbatims, or comments interchangeably.  They are responses to open-end questions. As we will see later, we don’t call the responses to an open-end question answers. We will find that these verbatims are effectively turned into answers by the process of verbatim coding.

Outside of survey research, the term verbatim is rarely used.  Here the term comment is much more prevalent.  In survey research the word verbatim is used as a noun, meaning the actual text given in response to a question.

Survey Data Collection 

In the survey research world, verbatims are collected by fielding the survey. Fielding a survey means putting it in front of a set of respondents and asking them to read it and fill it out.

Surveys can be fielded in all sorts of ways. Here are some of the different categories of surveys marketing research companies might be using:

• Paper surveys
  • Mailed to respondents
  • Distributed in a retail store
  • Given to a customer in a service department
• In-person interviews
  • In kiosks in shopping malls
  • Political exit polling
  • Door-to-door polling
• Telephone interviews
  • Outbound calling to households
  • Quality review questions after making an airline reservation
  • Survey by voice robot with either keypad or voice responses
• Mobile device surveys
  • Using an app that pays rewards for completed surveys
  • In-store surveys during the shopping experience
  • Asking shoppers to photograph their favorite items in a store
• Web surveys
  • Completed by respondents directed to the survey while visiting a site
  • Completed by customers directed to the survey on the sales receipt

There are many more categories of survey responses. The number of ways to field surveys the ingenious market research industry has come up with is almost endless.

As you can see, the form of the data collected can vary considerably.  It might be:

• Handwriting on paper
• Electronic text
• Voice recording responses
• Electronic data like telephone keyboard button presses
• Photographs or other images
• Video recording responses

And so on.  In the end, all surveys require:

1. A willing respondent
2. A way of capturing the responses

The way of capturing the responses is easy.  The first takes us to the area of sample we will consider soon.

Looping and Branch Logic

Data collection tools can be very sophisticated.  Many data collection tools have logic built in to change the way that the survey is presented to the respondent based on the data or responses given.

Suppose for example you want to get the political opinions of Republican voters.  The first question might make the respondent provide his political party affiliation.  If he responds with an answer other than “Republican,” the survey ends.  The survey has been terminated for the respondent, or the respondent is termed.  This is a simple example of branch logic.  A more sophisticated example would be to direct the respondent to question Q11 if she answers A, or to question Q32 if she answers B.

Another common bit of data collection logic is looping.  Suppose we make our respondents participate in an evaluation of five household cleaning products.  We might have four questions we want to ask the respondents about each product, the same four for each product.  We can set up a loop in our data collection tool.  It loops through the same four questions five times, once for each product.

There are many more logic features of data collection tools, such as randomization of the ordering of questions and responses to remove possible bias for the first question or answer presented.

The Survey Sample 

A sample can be described simply as a set of willing respondents. There is a sizable industry around providing samples to survey researchers. These sample providers organize collections of willing respondents and provide access to these respondents to survey researchers for a fee.

A panel is a set of willing respondents selected by some criteria.  We might have a panel of homeowners, a panel of airline travelers, or a panel of hematologists.  Panelists almost always receive a reward for completing a survey.  Often this is money, which may range from cents to hundreds of dollars, however, it can be another incentive, such as coupons or vouchers for consumer goods, credits for video purchases, or anything else that would attract the desired panelists. This reward is a major component of the cost per complete of a survey: the cost to get a completed survey.  

Sample providers spend a lot of time maintaining their panels.  The survey researcher wants assurance that the sample she purchases is truly representative of the market segment she is researching.  Sample providers build their reputation on the quality of sample they provide.  They use statistical tools, trial surveys, and other techniques to measure and document the sample quality.

Trackers and Waves

Many surveys are fielded only once, a one-off survey.  Some surveys are fielded repeatedly.  These are commonly used to examine the change in the attitude of the respondents over time.  Researching the change in attitude over time is called longitudinal analysis. A survey that is fielded repeatedly is called a tracker. A tracker might be fielded monthly, quarterly, yearly, or at other intervals. The intervals are normally evenly spaced in time. Each fielding of a tracker is called a wave.

Verbatim Coding 

In the survey research industry responses to open-end questions are called verbatims.  In a closed-end question the set of possible responses from the respondent is known in advance.  With an open-end question, the respondent can say anything.  For example, suppose a company that sells laundry detergent has designed a new bottle for their product.  The company sends a sample to 5,000 households and conducts a survey after the consumers have tried the product.  The survey will probably have some closed-end responses to get a profile of the consumer, but to get an honest assessment of what the consumer thinks of the new package the survey might have an open-end question:

What do you dislike about the new package?

So, what does the survey researcher do with the responses to this question?  Well, she could just read each verbatim.  While that could provide a general understanding of the consumers’ attitudes, it’s really not what the company that is testing the package wants.  The researcher would like to provide more specific and actionable advice to the company.  Things like:

22% of women over 60 thought the screw cap was too slippery.
8% of respondents said the bottle was too wide for their shelves.

This is where verbatim coding, or simply coding, comes in. Codes are answers, just like for closed-end questions. The difference is that the codes are typically created after the survey is conducted and responses are gathered. Coders are people trained in the art of verbatim coding and often on a coding platform, such as Ascribe Coder. Coders read the verbatims collected in the survey and invent a set of codes that capture the key points in the verbatims. The set of codes is called a codebook or code frame. For our question, the codebook might contain these codes:

• Screw cap too slippery
• Bottle too wide
• Not sufficiently child-proof
• Tends to drip after pouring

The coders read each verbatim and assign one or more codes to it. Once completed, the researcher can now easily read each one of the coded responses and see what percentage of respondents thought the cap was too slippery. You can see that armed with information from the closed-end responses the researcher could then make the statement:

22% of women over 60 thought the screw cap was too slippery.

Now you can see why the responses to open-end questions are called verbatims, not answers.  The answers are the codes, and the coding process turns verbatims into answers.  Put another way, coding turns qualitative information into quantitative information.

Codebooks, Codes, and Nets

Let’s look at a real codebook. The question posed to the respondent is:

In addition to the varieties already offered by this product, are there any other old-time Snapple favorites that you would want to see included as new varieties of this product?

And here is the codebook:

• VARIETY OF FLAVORS
  • like apple variety
  • like peach variety
  • like cherry variety
  • like peach tea variety (unspecified)
  • like peach iced tea variety
  • like raspberry tea variety
  • like lemon iced tea variety
  • other variety of flavors comments
• HEALTH/ NUTRITION
  • good for dieting/ weight management
  • natural/ not contain artificial ingredients
  • sugar free
  • other health/ nutrition comments
• MISCELLANEOUS
  • other miscellaneous comments
• NOTHING
• DON’T KNOW

Notice that the codebook is not a simple list. It is indented and categorized by topics, called nets, and the other items are codes. Nets are used to organize the codebook. Here the codebook has two major categories, one for people whose responses are that they like specific flavors and the other for people mentioning health or nutrition.

In this example, there is only one level of nets, but nets can be nested in other nets.  You can think of it like a document in outline form, where the nets are the headers of the various sections.

Nets cannot be used to code responses.  They are not themselves answers or responses to questions and instead are used to organize the answers (codes).

Downstream Data Processing

Once the questions in a study are coded they are ready to be used by the downstream data processing department in the survey research company.  This department may be called data processing, tabulation, or simply tab.  In tab, the results of the survey are prepared for review by the market researcher and then to the end client.

The tab department uses software tools to analyze and organize the results of the study. These tools include statistical analysis which can be very sophisticated. Normally, this software is not interested in the text of the code. For example, if a response is coded “like apple variety” the tab software is not interested in that text but wants a number like 002. From the tab software point of view, the respondent said 002, not “like apple variety”. The text “like apple variety” is used by the tab software only when it is printing a report for a human to read. At that time, it will replace 002 with “like apple variety” to make it human-readable. Before the data are sent to the tab department each code must be given a number. The codebook then looks like this:

• 001   VARIETY OF FLAVORS
  • 002   like apple variety
  • 003   like peach variety
  • 004   like cherry variety
  • 021   like peach tea variety (unspecified)
  • 022   like peach iced tea variety
  • 023   like raspberry tea variety
  • 024   like lemon iced tea variety
  • 025   other variety of flavors comments
• 026   HEALTH/ NUTRITION
  • 027   good for dieting/ weight management
  • 028   natural/ not contain artificial ingredients
  • 029   sugar free
  • 030   other health/ nutrition comments
• 031   MISCELLANEOUS
  • 032   other miscellaneous comments
• 998   NOTHING
• 999   DON’T KNOW

The tab department may impose some rules on how codes are numbered. In this example the code 999 always means “don’t know”.

Choose Ascribe For Your Verbatim Coding Software Needs

When it comes to verbatim coding for open-ended questions in market research surveys, Ascribe offers unparalleled solutions to meet your needs. Our sophisticated coding platform, Ascribe Coder, is designed to streamline the process of categorizing and analyzing open-ended responses, transforming qualitative data into quantitative results. Whether you are dealing with responses from customer satisfaction surveys, employee feedback, or product evaluations, Ascribe provides the tools necessary for efficient and accurate verbatim coding.

If you are short on time or need further assistance with your verbatim coding projects, Ascribe Services can complete the coding project for you. They also offer additional services like Verbatim Quaity review, AI Coding with human review, and translation with human review.  Many of the top market research firms and corporations trust Ascribe for their verbatim coding needs. Contact us to learn more about coding with Coder. 

You hear the term text analytics a lot these days.  It seems to be used in so many different ways it is hard to pin down just what it means.  I’ll try to clear it up a bit.

The basic idea is that a computer looks at some text to accomplish some goal or provide some service.  Just what those goals and services might be we will get to in a moment.  First note that text analytics works with text and analyzes it in some way.  That’s the analytics part.  When I say text, I mean electronic text, like this blog page or some comments from your customers stored in a spreadsheet.  Text analytics does not work with voice recordings, videos, or pictures.

Because text analytics examines text written in a natural language (like English or French), it uses techniques from the sciences of Natural Language Processing (NLP) and Linguistic Analysis.  The computer techniques used include machine learning, word databases (like a dictionary in a database), taxonomies, part of speech tagging, sentence parsing, and so on.  You don’t need to understand these techniques to understand what text analytics does, or how to use it.

Just what can we use text analytics for?  Some of the more common uses are:

• Document classification and indexing – Given a bunch of documents, the computer can figure out the key concepts and let you search a library of documents by these. A sophisticated example of this is E-Discovery used in legal practice, which seeks to use the computer to assist in discovery in legal proceedings.
• National security – Governments use computers to monitor web postings for information or discussions of interest to national security.
• Ad serving – We are all experienced with the uncanny ability of some web sites to show us ads that are relevant to our needs and interests. Text analytics applied to the pages we are viewing is a big part of this magic.
• Business intelligence – For most of us this is the big one! We can the computer to give us insights into how to improve our service, retain customers, and give us a competitive advantage.

Text analytics for business intelligence is a rapidly growing market.  Using the right tool, you can analyze thousands of customer comments in minutes.  If the tool does a good job of presenting the results it is amazing how quickly you can figure out what they care about, their pain points and plaudits, your weaknesses and strengths.

Choosing a Text Analytics Tool

How do you find the right software product for your needs?  Well, there are many providers of raw linguistic analysis capabilities.  Google, Microsoft, Amazon, SAP, IBM, and many others provide such services via an API.  But this takes an engineering effort on your part, and you still need to figure out how to navigate the results of the analysis.

There are several vendors of complete text analytics packages for customer experience management.  As you evaluate these consider:

• Does the vendor specialize in customer experience feedback?
• Are the results of the analysis clear and insightful?
• Is text analytics a core competency or a side product?
• Are multiple languages supported?
• Is automatic translation between languages supported?
• How easy is it to tailor the text analytics to your specific business?

Navigating the Linguistic Analysis Results

Suppose you have a database of feedback from your customers.  If you run 10,000 customer comments through a linguistic analysis engine it will produce a mountain of data.  To gain insight from this data it needs to be organized and navigable.  A good text analytics tool will organize the results and display them in a manner that helps you to find the actionable insights in the comments.  Optimally the tool will help you pinpoint the strengths and weaknesses of your company from the customer's viewpoint.

Reducing the Raw Linguistic Analysis Data

Let's look at a specific example to gain an understanding of what is involved in organizing and presenting the results of linguistic analysis.  As I described in Linguistic Analysis Explained, sentence parsing is one tool in the NLP analytics bag of tricks.  Google has a very well regarded sentence parser, and it is available via an API.  You can try it out at https://cloud.google.com/natural-language/.  It's a fun way to get some insight into the complexities of presenting the results of linguistic analysis.  Try running this comment through the API:

The support staff are helpful, but slow to respond.

Now and take a look at the Syntax results.  These are the results of the sentence parser.  You find:

Wow, that's a lot of data, but hardly actionable insight!  You can see that the sentence has been broken into tokens (words and punctuation).  Each token has been tagged with its part of speech (slow is an adjective).  Each token has also been assigned a parse label, indicating how it is used in the sentence (slow is used as a conjunction).  The green arrows show how the token are interrelated.  Imagine how much data would be generated by running 10,000 customer comments through the sentence parser!

The job of text analytics is to distill this pile of data down.  In this case the analysis might go something like this:

• "Support staff" is the nominal subject of the root verb.  That's a topic the customer has mentioned.
• "Helpful" is an adjectival complement (acomp) of the subject.  The customer has said the staff are helpful.
• "Support staff" is further described by the customer by the coordinating conjunction (cc) "but", as "slow" (conj).

So we find that the support staff are both helpful and slow.  We have extracted a topic of "support staff", with expressions of "helpful" and "slow" associated with it.  This reduction of the raw data from linguistic analysis has resulted in what we are interested in knowing.  Our customer thinks the support staff is helpful, but also slow!  This is a single finding from linguistic analysis.

Presentation of the Reduced Data

Now that we have extracted the desired nuggets from the raw linguistic analysis data we need to present it in a way that helps you find the insights you seek.  An actual analysis of 10,000 customer comments may well produce 50,000 findings.  To navigate these the findings need to be organized in a way that emphasises the important insights, and allows you to explore the findings quickly and intuitively.  A good text analytics tools will assist you in ways such as:

• Grouping similar topics, preferably automatically or with a custom taxonomy you control.
• Ranking topics by frequency of occurrence or other metrics such as sentiment.
• Allowing you to filter the results in various ways, such as by demographic data.
• Showing trends across time or other variables.

Summary

Text analytics for customer experience management reduces and organizes the results of linguistic analysis.  If done well, the results are presented to you, the user, such that you can find actionable insights quickly, and explore the data to help formulate an action plan for improvement.

We are going to talk about taxonomies as used for text analytics. But to get to that, let’s first look at what we mean by a taxonomy. In general terms, taxonomies classify things. You may remember this from biology classes. Biologists classify humans into primates, mammals, and then the animal kingdom (skipping a few levels). But you get the idea. A human is a primate, a primate is a mammal, and a mammal is an animal. Taxonomies are an “is-a” hierarchy. Each level belongs to the next level up with an “I am an instance of” relationship.Taxonomies are an important tool in natural language processing in general, and in text analytics in specific.While can have several levels: Animal => Mammal => Primate => Human, in text analytics it is common to have only two levels. For example, we could have a taxonomy that looks like this:

• Government agency
  • Internal Revenue Service
  • United States Treasury
  • Office of Management and Budget
• Commercial enterprise
  • Apple
  • IBM
  • Tesla
• Non-Profit
  • American Red Cross
  • Sierra Club
  • Doctors without borders

This taxonomy classifies organizations by type. In the realm of text analytics for customer experience management we are more likely to want to classify specific topics into more general topics. We can think of this as placing topics into groups. Supposing we are an airline company, we might want a taxonomy like this:

• Baggage
  • Bag
  • Luggage
  • Suitcase
• In-flight technology
  • Wi-Fi
  • Video
  • Movies
• Airport amenities
  • Lounge
  • Gate
  • Tram

The intent of the taxonomy is to group customer mentions so that we can consider them as a whole. Supposed we used text analytics to find the topics mentioned in an airline customer satisfaction survey. The taxonomy above could be used to group the topics into the general areas we want to consider together.This application of the concept of a taxonomy is really a way of grouping topics into broader concepts that make sense for our particular business. It is a business domain specific method of grouping or aggregating. It is a powerful technique for tailoring text analytics findings to a specific business vertical.When used in this way we can view the taxonomy as a list of groups, each of which has one or more synonyms. The taxonomy maps synonyms into groups.As you can imagine from the brief examples, real taxonomies can become very large. There are techniques to manage this. First, some software products are capable of creating taxonomies automatically. These use algorithms that examine the results of the text analytics and attempt to create taxonomies suitable for the analyzed text. Second, the taxonomy may allow more powerful means of specifying synonyms than simple text matching. For example, the software may allow the use of regular expressions to specify synonyms.

By Google Surveys, Published on Google.com on June 23, 2017Ascribe, a Google Surveys Partner, is featured on the Google Analytics Solutions Success Stories page with an overview of how the partnership led to innovation and expansion of access to consumer insights for researchers.Read the full feature