QUALTRICS TOOLCHEST: Teach Qualtrics How to Play “Guess the Number” with Advanced Embedded Data Techniques

NOTE: You might want to try out the game we’ll be building today before you start reading. Go ahead, we’ll wait for you!

One of the most frustrating aspects of Embedded Data in Qualtrics is that it’s not always obvious how you can utilize it for applications beyond capturing some contact panel or URL information. (Case in point: in preparing today’s tutorial, I spent a couple of hours wrestling with how to get Qualtrics to do what I wanted, as the seemingly logical solution wasn’t working out for me!) Having the platform do what you don’t want and discovering that your survey design won’t work for collecting the data you do want can be really frustrating, and the more complex your survey design is, the harder it can be to catch every contingency in testing.

Even so, it’s worth beating your head against the wall as you learn how to make Qualtrics’s embedded data do what you want it to do, because there are some really neat applications you can employ to enhance your data collection once you understand the underlying mechanics. I find the easiest way to learn a new skill with programming is to try to make a game, so today, we’ll be playing “Guess What Number I’m Thinking Of?” by having Qualtrics select a number and the user try to guess correctly within 6 tries.

To do this, we first need to design our game. That means we need to first create a design document that includes the following:

  • Our list of mechanics that determine how the game is played
  • Our list of rules that determine our victory conditions (how the player wins or loses)
  • A diagram that shows us what a typical game should look like

The mechanics are incredibly simple for Guess the Number – the computer player (Qualtrics) selects a random number and the human player has to keep guessing until he or she gets it. We’ll program this so that the player gets a reasonable number of guesses – in this case, anyone who’s employing any sort of strategy ought to be able to get the correct number in fewer than six guesses, so we’ll cut them off there.

We also need to have some rules. The very simple rules of this game are:

The computer player can only select whole numbers in the range of 1-10.
The human player can only submit numbers.
The human player wins if he/she submits the correct number within 6 tries and loses if he/she does not.

Now we need a process flow. At first blush, it’s complicated, but it’s actually a straightforward and fairly linear process where the player progresses to winning upon getting the correct answer and stays in the process without one:

As with our Paper, Rock, Scissors game, we’re going to divide our survey into blocks. Think of blocks as being like the boxes in our process above which divide out the different steps the player will go through. One of the reasons we need blocks in this particular survey is because we’re going to be asking Qualtrics to updated embedded data fields and do some light math for us, and having our questions in separate blocks makes it much easier for us to do that.

Next, we need to program our survey that includes the following:

  • A first guess block
  • A second, third, fourth, fifth and final guess block that tells the player whether the correct number is higher or lower in value than their guess.
  • A block that will show up to let the Human Player know if he/she is the winner or loser and which will ask the Human Player if he/she wants to play again.

(You’ll notice right away that the survey itself is not programmed to determine what number Qualtrics will select or to evaluate if the player is actually correct. We’ll do that in Survey Flow later on.)

Our first survey question should be a text entry box:

You might notice that little gray * on the side. This indicates that I’ve turned on a certain type of validation, which in this case is content validation, which I’ve set to number to limit the human player to only be able to enter numbers without text.

(Though I didn’t do it here, I could also use custom validation to additionally limit the range of numbers to Greater Than or Equal to 1 and Less Than or Equal to 10.)

Next, I need to construct what happens after the player guesses. We’re going to Add Block and create a second block of questions called “Higher-Lower 1.” Since we want to give the player feedback on whether the number the computer is thinking of is higher or lower than the player’s guess, we need to program in two questions: one that tells them to guess higher and asks for a new number, and one that tells them to guess lower and asks for a new number.

Later on, we’ll use the embedded data result in a little while to determine which of these will be displayed to the player. We’ll also be nice and utilize some piped text to display the player_number field so the player will remember what they entered, so this block will eventually look like this:

We’re going to use this version of the block as a template later on and create four more just like it. But since we’re not quite ready for that, let’s create our final block, which is going to tell the player whether he/she has won or lost. We can actually program both of these conditions into the same block, so let’s do that!

Again, we’re going to be adding in some display logic using the embedded data result and some piped text to show a customized greeting called Congrats, the player_number and correct_number later on, so we’ll eventually make this block look like this:

For the moment, we’re done with our survey. It’s time to head into the Survey Flow window. We have a few tasks to accomplish here:

  • Set up the randomizer to have the computer select a number
  • Set up some embedded data to record the correct_number (updated by the randomizer), the player_number (updated whenever the player makes a new guess), the number_tries (updated with each attempt) and the result (which we’ll use to tell our survey which questions to display).
  • Set up branches to show our Higher-Lower 1 block (which will be a template for the other versions of it we’ll be creating) and our conditional Congrats message in embedded data.
  • Set up ending instructions to either play again or send our player to exit to a landing page.

That’s a lot to do! But fortunately, it’s not difficult, just a little tedious.

Let’s begin with the randomizer, which is a tool for telling Qualtrics to do some tasks randomly. We can add it to our survey flow by clicking “add below” on one of our gray-barred blocks and then click “move” to put it at the top of the survey flow, above your starting block.

We’re going to need to Set Embedded Data below our randomizer. Let’s call our embedded data correct_number and set its value to 1. (Even though this value will be a number by default, for good data hygiene, go ahead and click “options” and set the variable type to Number“)

Also, tell the randomizer to randomly present 1 of the following elements. Your screen should look like this:

Now, click “Duplicate” on your embedded data box and another one just like it will appear below. Change the value from “1” to “2”. Continue doing this until you have 10 boxes, with each box setting a different number, like so:

Qualtrics will now start the survey by selecting one of these ten instructions and assigning a random number to correct_number before the user enters anything. In essence, we’ve taught it how to think of a number. (It’s not quite artificial intelligence, but it’ll do the trick for this game!)

Now we need to go back to our “Start” block (which should be below the randomizer) and click “Add below” to select “Embedded Data”.

In the new green box that appears, we want to set three values. Where it says “Create New Field or Choose From Dropdown…”, replace this text with player_number. Hit enter and replace the “Create New Field or Choose From Dropdown…” with result. Do this one more time and replace “Create New Field or Choose From Dropdown…” with number_tries. Then, click options and set all three to “Number” under variable type.

We now need to assign our starting values to each of these embedded data fields. We want to set player_number to whatever the player chose in the Start block’s question, which we can get from piped text by clicking on the arrow on “Value will be set from Panel or URL” and then, when a box appears that says “Custom Value,” clicking on the arrow beside it to navigate to our response from our first survey question.

Qualtrics will spit out some funky text that looks like this: ${q://QID1/ChoiceTextEntryValue}. That’s what you want!

Next, let’s set the value for result. This is where we’re going to employ a feature in Qualtrics that many people never use: mathematical operations. Basically, we need to create a math equation that provides the difference between the correct_number and the player_number and use that to tell the survey whether the player has won or whether it should display a higher/lower question to receive another guess. The process here is not straightforward, and I recommend reading the Math Operations documentation if you want to understand how this all works.

What we need to do is create a single number that Qualtrics can utilize in its logic. The difference of our two numbers will tell us just that. If we start with the player_number and subtract the correct_number from it, we’ll know if the guess is correct, needs to be higher (negative number outcome) or needs to be lower (positive number outcome) based on the result. For example:

If the player guesses 1 and the correct number is 10, we'll have a difference of -9, which means the player needs to guess a higher number to be closer to the correct answer.

If the player guesses 5 and the correct number is 5, we'll have a difference of 0, which means the player wins.

If the player guesses 10 and the correct number is 1, we'll have a difference of 9, which means the player needs to guess a lower number to be closer to the correct answer.

In Qualtrics, we initiate math operations by typing $e{ } and the including our operation within the brackets. It’s very important to ensure there is a space after { and before } or the operation will not work. We additionally need to use piped text to call in our two embedded data fields, which we do by clicking on the arrow in our “Custom Value” box once again and selecting “Embedded Data” and our field:

We’ll have to pull out both variables and put a minus sign (-) between them. Our complete math equation is going to look like this (note the spacing!):

$e{ e://Field/player_number - e://Field/correct_number }

The will become the value for result. In our survey, any time we have a result of 0, we’ll declare the player the winner. If result is a negative number, we’ll tell them to guess higher, and if result is a positive number, we’ll tell them to guess lower.

“Why can’t we just compare the two numbers?” you might be wondering. I made the same mistake myself and spent an hour of fruitless frustration trying to get the survey to do just that before I figured out this workaround. Qualtrics only seems to be able to evaluate one embedded data field versus logic rather than comparing two embedded data fields against each other. But now that you know the workaround, you have the power not to be tripped up by this in the future!

Going back to our embedded data box, the third value we need to set is, thankfully, very easy. Set number_tries to 1. Later on, we will program this field to update as the player makes additional attempts.

You should have a box now that looks like this:

Whew! We’ve done a lot already, and we haven’t even created our logic for determining if our player is correct or not! But thankfully, we’re getting close. A lot of what comes next looks complicated, but it’s fairly easy.

Under our embedded data box we just made, click “Add Below” and select “Branch”. In this branch, set the condition to “If Embedded Data result Is Not Equal to 0.” This will tell Qualtrics to skip this block if the player somehow gets the right number on his or her first guess.

Under that branch, we want to display the block “Higher-Lower 1”. This is where the player is going to be told he/she guessed wrong and invited to make a second guess.

Under the block “Higher-Lower 1”, click “Add Below” and create another Embedded Data box. In the survey, we’ve just invited our player to make a second guess, so we need to increase the number_tries by one. We do this by setting the embedded data field number_tries to call its own value and then add one to it, like so (and please note the spacing once again!):

$e{ e://Field/number_tries + 1 }

“I didn’t know I could tell embedded data to update itself like that!” you might be thinking, and now you know – you can! While the logic might seem circular from a glance, what you’re actually doing here is an instruction the software understands perfectly, but in syntax that doesn’t tend to make intuitive sense to a non-programmer. If you’re confused by it, don’t worry; just keep moving on and trust that it will work. We’ll see the result later in the game!

Next, we need to tell the game to update our old player_choice with the new one that the player just entered and we also need to update our result so the software can evaluate if the player made the correct choice. For player_number, we’ll do pretty much exactly what we did before with piped text, but we’ll this time tell our software to overwrite our player_number field with the response from the question we just asked. For result, we’ll use the same math equation we had before to update our field in light of the fact that the player_number has changed.

Here’s the thing, though. You remember how we actually had two questions in our Higher/Lower block? We need to ensure that whether the higher or lower question is asked, we update our fields regardless. And we have to be very picky about making sure we update the player_number value with the right number and don’t accidentally change it to being empty. So, we need to branch based on which question was asked and set the embedded data relative to that question:

The big difference here is our player_number refers to different question IDs depending upon which question was asked. Our higher question was QID2, so the piped text results in ${q://QID2/ChoiceTextEntryValue}. Our lower question, by contrast, is QID3, so the piped text results in ${q://QID3/ChoiceTextEntryValue}. This is a very important detail, as we’ll need to pay attention to this when we begin creating our other four Higher-Lower blocks in a moment.

The result equation is the same in both cases, but it’s always below the adjustment to player_number because Qualtrics will process them in the order of topmost to bottommost, and we need player_value to updated before we can get a proper update to results.

Let’s take a break from Survey Flow for a moment and go back to our survey. Click Save Flow and go to your Higher-Lower 1 block. Now it’s time to make what we started with match the block I showed you we’d eventually be setting up. First, we need to set our questions to display appropriately. We only want our players to see one of these two questions, and we also want to ensure they won’t see either if their result is 0. So, we need to click on the gear on the right hand side and set our Display Logic for the first question (telling the player the correct number is higher) and say that this question should only appear if Embedded Data result is Less than 0.

Do the same thing for the second question that tells the player the correct number is lower, except this time, set the display logic to only show this question if Embedded Data result is Greater than 0.

Then, let’s jazz up the text in the actual questions a little bit to remind our player what their last guess was. We do this with piped text, which we can access by clicking on our survey text and accessing the tab above. Do this to both questions.

I wrote my questions to read:

Nope. It's higher than ${e://Field/player_number}! Try again.

Nope. It's lower than ${e://Field/player_number}! Try again.

Here’s what my finished block looks like now.

Here’s where you get to work on your own for a few minutes. I want you to look on the upper right hand corner of your block and click “Block Options”. Towards the bottom, you’ll see “Copy Block.” (It’s in the red box in the image above if you’re having trouble finding it.) Create four more blocks just like this one, and call them Higher-Lower 2, Higher-Lower 3, Higher-Lower 4 and Higher-Lower 5, and then go back into our survey flow.

First of all, find them in the survey flow (they’ll probably be under Higher-Lower 1) and delete them. They won’t be removed from your survey; just from the flow itself. This will keep them from showing up unexpectedly.

Next, find your branch with Higher-Lower 1 and, in the start of the branch (where we said “If result is Not Equal to 0″) click “Duplicate.” Do this four times.

You should now have five identical branches which all direct your survey to show the block “Higher-Lower 1” if the condition “result” is not equal to 0. And believe it or not, we could almost stop here, because your game will now sort of function! But the experience won’t be great, and we haven’t finished the ending logic yet, so we still have a few things to finish up.

The first is to go into each of your new branches and replace “Higher-Lower 1” with the next “Higher-Lower” block. You do this by clicking “Add Below” and selecting “Block” to add your next block and then delete your “Higher-Lower 1” block from the branch. When you’re done, each branch should have a unique “Higher-Lower” block.

Next, in each branch, you need to update which questions are being referred to, both in your embedded data for player_number (green boxes) AND your branches for higher/lower questions (blue boxes). You don’t need to adjust number_tries or result, however – they’ll do their job just fine.

There are four areas in each of your four new branches you need to correct (16 in all).

If you don’t make these corrections, your game won’t work, so ensure that you’re branching due to the appropriate question in the appropriate block and that you’re updating your piped data for each player_number entry.

Let’s think about our endgame for a moment. If you recall, our current message only tells the player if he/she won our lost. Wouldn’t it be nice to give them some indication of how well they did and, if they got lucky on the first try, to customize that message to express a special congratulatory remark? We can do that with embedded data!

Below our branch regarding Higher-Lower 5 (and above our End block), let’s add a new embedded data box and change “Create New Field or Choose From Dropdown…” to Congrats. Let then set its value to “Good job! You got the correct answer in <piped text> tries!” We get the piped text from clicking on arrow and setting it to our embedded data field number_tries, like so:

Qualtrics will split out some funky text like “${e://Field/number_tries}” and the survey will know when it displays the Congrats message to reference that particular piece of embedded data.

Let’s have a little more fun with this and change the message if the player gets lucky and guesses correctly on the first try. We can use branch logic below our default Congrats message to change things if number_tries is equal to 1. We just create a branch with this condition and then click “Add Below” to change our embedded data value for Congrats to read:

Wow! You got the correct answer on your first try!

With that message programmed, it’s time to set up the end of the game. Click “Save Flow” on your Survey Flow Window and return to the survey editor. Scroll down until you hit the End block. Right now, we have two questions: one that says “You got it!” and another that says, “You failed to guess the correct number in six guesses.” Both also ask, “Would you like to play again?” And honestly, this is fine for the end of the game, but we can use piped text to customize things a bit more.

The first thing we can do is pipe in our Congrats message as the first sentence of our winner question. As we’ve done previously, just click on the question text and then the piped text tab to insert the embedded data field Congrats. Then, let’s give the player validation that they selected the right number by adding, “It was” and then the piped text for the embedded data field correct_number. Finally, let’s set display logic here that this question will only be shown IF result is Equal to 0 (which is our victory condition).

We’ll do something similar with the lose question. Let’s change the text to read, “Sorry, you’re out of guesses. The correct number was” and then insert the piped text for the embedded data field correct_number. (You can just copy it from the previous question if you’d like, as it’s the same!) Then, we need to set display logic so this question only shows up IF result is Not Equal to 0 (which means the player has not yet won).

Your block should now look like this:

(You might be wondering, “why doesn’t the display logic dictate the number of tries for the lose condition?” It’s because we have already programmed to survey to give the participant six tries through the first guess and five subsequent guess blocks they’ve given. Under this programming, the end block always shows up when we’re done giving the player guesses, so we don’t need to set any other conditions. This makes life much easier for us later on if we decide to make further changes to the game.)

Our last requirement is to set the game to either take the player back to the beginning to play again or to take the player to a landing page upon exit. Go back into Survey Flow, scroll down below the End block and click “Add Below.” We need a branch that says If the player chose “Yes” in our win question OR our loss question, we’ll end the survey. Set that display logic, and then click the Customize button in the End of Survey box to Redirect to a URL…. The web address you’ll enter there is the link for the survey.

Do the same thing for selecting “No” in either question, and set the URL to redirect to the webpage of your choice. Then, click “Save Flow.”

Now our game is finally ready to play! You can try it here if you didn’t already. Have fun, and once you get it programmed, try to change things up a little bit with some of the following challenges!

  • Can you have Qualtrics display all of the user’s previous guesses so they can see what they’ve already selected?
  • Can you have Qualtrics change the look and feel of the survey to communicate visually that the user needs to guess lower or higher using different-colored backgrounds or graphics?
  • Can you have Qualtrics set a number between 1 and 100 using the randomizer without coding in 100 different numbers?

    (HINT: You can use the randomizer to generate two different single-digit numbers and then combine them together with a mathematical operation that multiplies the first number by ten and then adds it to the second number. If you want to make it between 1 and 1000, you can follow a similar process by generating three single-digit numbers. Just be sure to account for what happens if a zero is selected!)

I hope you enjoyed this article. Here’s a link to the Survey Preview and to the QSF file if you’d like to refer to either. If you’d like to discover more Qualtrics tips and tricks, be sure to check out other articles in our series, and if we can help you or someone you know with a Qualtrics question or problem, please contact us!