Piping answers and data in surveys

Answer piping within a survey

With this method you take a response someone provides and copy it later in the survey. For example on one page you'll ask:

And on a later survey page you'll remind the respondent with:

Answer piping can be done with both fixed option responses and type-in answers. When working with type-in responses, it can be a challenge to write surrounding text in a way that reads smoothly but will accommodate a wide range of answers—including blanks at times.

Sometimes answer piping might be tangled up with skips, branching or looping in your survey software. In this case, I'm referring to a generic page of questions into which a snippet of answer text is inserted. In the example above, there exists only one satisfaction rating grid for their favorite brand.

Data piping into surveys

This function allows you to create handshakes between other databases/files and your survey. Common examples include:

• Using a customer or member ID to pull in their address
• Triggering a skip through the survey based on an employee's division
• Embedding a customer service representative's name based on the ticket number
• Displaying the local office location based on a respondent's Zip code

When pulling information into a survey, you can decide how much to reveal to respondents:

• Tucking data into hidden fields for use behind the scenes in skips or analysis
• Placing information in text strings for the respondent, such as:
  Welcome Jane. For the following questions, please rate the performance of your support technician Paul in handling your October 29, 2006 issue.
• Pre-filling an address field or other questions, but allowing the respondent to make updates to the data.

In all cases, you'll need to have a "key" value that matches a piece of information in the survey to the external database or data file. That key value may be used in many surveys (Zip code) or only once (unique password). However, the key can only exist once in the external data source, or the survey won't know what record's information to pull into the survey.

Your two data sources are databases (usually SQL) and ASCII data files. With a database connection you can have a real-time update, so a customer service rep could send the survey link as soon as they closed the ticket, and any updated contact information from the respondent would be immediately incorporated when they finish. With ASCII files, the information is a "snapshot" such as all member addresses when the survey is launched, which works well for surveys of that run once a year/quarter/month, and are much more broadly supported and easier to configure than database connections.

Data piping out from surveys

This may be referred to as an export in your software, but is essentially the mirror image of piping data into a survey. In this case, you're taking answers from a respondent and updating a database such as your CRM system, or creating an ASCII data file such as contest entrants.

Data piping via URLs

This is a great way to exchange information real-time between different servers. A very common application is with survey panels where the panel vendor will create a link to your survey with the panelist's ID, and you'll send a link back to their system with the ID and whether the individual qualified for compensation. It's also the same way you embed a password in a URL for an e-mail invitation.

When it's two servers or applications on a server exchanging information, you can tuck a lot of information in the URL such as the respondent's name, account number, e-mail address, etc. Remember that while your survey may be running under SSL encryption, anything in a URL is transmitted in plain text so never embed sensitive information such as a Social Security Number.

When you're putting data in the survey link of an e-mail invitation, you want to keep the URLs shorter because plain text e-mail applications (web mail, Blackberries) may break lines at 70 or 80 characters. In this case, your best bet is to embed just a unique identifier, and pair that with piping data in from a database or ASCII data file to pull in the name, address, etc.

Each application that generates or receives a URL will have its own syntax for labeling data fields, so you may need to create a small translator script to get two systems speaking properly. In addition, all punctuation needs to be encoded in hexadecimal such as %20 for a space or %40 for an @ sign. The punctuation issue is another reason for using just an ID in the URL you create during an e-mail invitation mail merge.