Piping answers and data in surveys
"Piping" at its most generic refers to moving information in, out, and around a survey. This makes it a very useful technology for any dynamic survey (Web, telephone, kiosk), potentially enriching the respondent experience or increasing data quality.
It's also one of the many survey terms that can mean different things to different people, so before you assume your survey tool does what you want, make sure you're using the same definitions as your vendor. This article covers four main approaches to piping:
- Answer piping within a survey
- Data piping into surveys
- Data piping out from surveys
- Data piping via URLs
With this method you take a response someone provides and copy it later in the survey. For example on one page you'll ask:
What's your favorite brand?
And on a later survey page you'll remind the respondent with:
Thinking of your favorite brand Alpha, how would you rate your satisfaction on the following...
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.
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.
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.
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.
Thanks again for the excellent training sessions. You were able to keep it interesting and worth every penny. You have such a thorough understanding of the software. ~~sigh~~ to be that wise!
Susan L. Despot
California University of Pennsylvania