Partager via


Design VoiceXML Applications for Easy Reporting and Tuning

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Use the analysis and tuning tools, such as Analytics and Tuning Studio and Business Intelligence Reports in Speech Server, to improve the efficiency and effectiveness of deployed VoiceXML applications. All speech applications benefit from the analysis of real log data, from their initial trial phases through deployment and beyond. Designing a VoiceXML application with reporting and tuning needs in mind makes it easier to measure its effectiveness and makes it easier to improve the application based on data from real user behavior.

To collect log data, enable event tracing for the application. For more information, see How to: Enable Event Tracing of Call Activity.

Turns

Dialog turns are useful for analysis of prompt and recognition performance, particularly with the Re-recognizer and Grammar Tuning Advisor tools included with Analytics and Tuning Studio. Turns in voice response applications are units of interaction with the caller that contain one or more prompts and one or more recognitions. Turns are similar to the following concepts in VoiceXML:

  • A prompt playback without a recognition, for example <block>Hello World</block>.
  • A prompt playback with a recognition, for example a form field holding a prompt or a grammar.
  • A recording with or without a prompt, for example <record>.
  • A transfer with a grammar, for example <transfer><grammar???/></transfer>.

Speech Server logs a turn when it occurs in a VoiceXML application, using the following scenarios to specify a name for the turn:

  • Where the turn is clearly related to a named item, for example the form items <field> and <initial>, that name becomes the turn name.
  • Where the turn is not clearly related to a named item, for example a prompt block within a form, the ID of the containing <form> can become the turn name.
  • Where a turn name is unavailable, a name that is contextually appropriate and readable is generated, for example _[docname]_Turn1 and _[docname]_Turn2.

Notice that as a result of prompt queuing within the VoiceXML Form Interpretation Algorithm, one or more prompts queued before a turn results in multiple rows corresponding to that turn in the details views and the Turn List view seen in Analytics and Tuning Studio. In such cases, all prompts queued for the turn appear under the final such turn instance in the details views.

Tasks

Tasks are very important for measuring the transaction completion rates of an application and for gauging its usability. Tasks map to dialog elements used as containers in the Dialog Framework API and typically hold one or more turns. The use of tasks allows the developer to do two things that are very useful at reporting and tuning time:

  • Structure the application into a hierarchy of tasks and subtasks.
  • Provide a means to signal the success or failure of the task.

VoiceXML does not implement tasks with a completion state; however, with the Speech Server implementation of VoiceXML, developers can specify the task states in code. Accordingly, authors should signal the start and end of a task using the standard VoiceXML logging mechanism. For example:

<log label=???__EnterTask???>TaskName</log>
<log label=???__ExitTask???>TaskName:TaskStatus:StatusMessage</log>

In the previous code, TaskName is a string that names the task, for example GetDate; TaskStatus is a string that should be set as one of Success, Failure, or Unset; and StatusMessage is a string that defines a reason for the completion status, for example User Hangup.

Tasks Without an Exit

A task might not have an _ExitTask, for example:

<block>
  <log label="__EnterTask">WeatherFormTask1</log>
  <log label="__EnterTask">WeatherFormUnClosedTask2</log>
  <log label="__EnterTask">WeatherFormTask3</log>
</block>
<block>
  <log label="__ExitTask">WeatherFormTask1:Success:WeatherFormTask1 ExitTaskSuccess</log>
  <log label="__ExitTask">WeatherFormTask3:Success:WeatherFormTask3 ExitTaskSuccess</log>
</block>

If _ExitTask is not present, in the previous example, the unlabeled WeatherFormTask2 task and the WeatherFormTask3 task that follows WeatherFormTask2 is labeled as Unset.

Tasks Orphaned by a GoTo Element

An author might use a goto element to bypass a task, as in the following example.

<form id="WeatherForm">
<block>
  <log label="__EnterTask">WeatherFormTask1</log>
</block>
<block>
  <if cond ="city=='Traffic'">
    <goto next="#TrafficForm" />
  </if>
</block>
<block>
  <log label="__ExitTask">WeatherFormTask1:Success:WeatherFormTask1 ExitTaskSuccess</log>
</block>
</form>

In this case, WeatherFormTask1 and any other turns or tasks in TrafficForm are labeled as Unset.

Task with an Exit but No Enter

A task can have an _ExitTask but not have an _EnterTask, for example:

<block>
  <log label="_ExitTask">WeatherFormTask1NoEnterLabelSpecified:Success: ExitTaskSuccess</log>
</block>

In this case, the task is not logged.

Commands

Commands are user responses that break out of the normal dialog flow. The Dialog Framework API contains a CommandActivity class that authors can configure and includes built-in Help and Repeat commands. VoiceXML implements a similar notion through help events, links, and form-scoped, document-scoped, and application-scoped grammars.

In a Speech Server VoiceXML application, handling a <help> or <catch event=???help??? ??? /> invokes a CommandActivity in the workflow application. VoiceXML <links> and page-scope or application-scope <forms> and <menus> also implement commands.

Application Events

Use the VoiceXML <log> tag to log data that is important at analysis time. Speech Server uses the ApplicationDataEvent class to log this into the trace logs. However, <log> tags that specify __EnterTask or __ExitTask are treated as task events and are not mapped to ApplicationDataEvent.

Confidential Turns

Standard VoiceXML does not support controlling the logging of turn data to protect privacy. This is platform-specific functionality, added by Speech Server through a proprietary <property>. See the general form in the following example.

<property name="com.microsoft.[component].LogResults" value="[boolean]" />

In the previous example, [component] is reco, dtmf, or prompt. The <property> tag can be specified at any level of form item, form/menu, document, or application. The default Boolean value is true. The primary use is turn by turn, most likely at the form item or form menu level.

Additional examples appear in the following table.

Component Example

Confidential recognition audio and results

<property name="com.microsoft.reco.LogResults" value="false" />

Confidential DTMF keypresses

<property name="com.microsoft.dtmf.LogResults" value="false" />

Confidential prompt audio and text

<property name="com.microsoft.prompt.LogResults" value="false" />

See Also

Concepts

Design Speech Applications for Easy Reporting and Tuning

Other Resources

Create VoiceXML Application Projects