So in answer to your first question, as far as I know, it doesn't constrain the type of data you store, but it does tell the analytical tools that Q provides what type of data it is. So if you were to put text in a field you've said is a number, your analysis would probably error out.
As far as being able to have the embedded data in the survey twice, this is by design. It allows you to set the data in multiple places in your survey flow. For example, say you had a field that listed what city someone lives in that you pull in from your panel at the beginning but later, if they answer that they've moved, you can set the city to the new answer, which also updates your panel information.
> @jpardicusick said:
> As far as being able to have the embedded data in the survey twice, this is by design. It allows you to set the data in multiple places in your survey flow. For example, say you had a field that listed what city someone lives in that you pull in from your panel at the beginning but later, if they answer that they've moved, you can set the city to the new answer, which also updates your panel information.
I don't really understand the second part of your comment because no matter how many copies of MiscJson embedded fields are added to my survey flow, each one is not treated differently, nor is there a way to differentiate which one is being used if they happened to each have different field types. So I would caution users against having multiple copies of the same embedded field name. In the below example, the MiscJson fields I added with a set value are ignored and do not appear in the response data analysis. Only if I set the MiscJson in the querystring of the response distribution URL does the MiscJson field value appear in the data analysis. Just something to keep in mind.
!
Again, if the data analysis tools are treating the field types differently then we need to know what format the data field type for example is expecting (MM/DD/YYYY, YYYY-MM-DD, etc.). And I have no idea what format the FilterOnly field type would expect.
It's sequential. You're setting three in a row, in the same place in your survey. They're not copies of each other, they're all the same field that you're updating three times at the same time. You've told Qualtrics that you're going to be pulling in a text-set type of data from the panel or URL and then you tell it three times in a row to update the data to 22, 33, and 44. I'm not sure why you're not seeing those values in your data but the behavior I would expect from what you've shown is that it would end up as '44', but it could be that it doesn't because you're telling it to do all of that at the same time. Try splitting it into different blocks and seeing if that changes the behavior.
Also, I don't want to discourage other users from utilizing this powerful and extremely useful tool, as it's very valuable for setting and resetting data.
This is what I mean in the example I gave:
Here, I pull in all the info I already know about my panelists.
!
I want to know if an address has changed and if so, capture the new address.
!
Now I branch and update the embedded data with the new information.
!
So the embedded data is placed twice in my flow in this example, and it's updated under a condition. Again, once a field is named, any subsequent times you 'declare' it, it's actually just updating the value.
@jpardicusick sorry but you are getting off topic a bit. My question has to do with the API field type definitions and not about updating embedded field data.
> @"w.patrick.gale" said:
> @jpardicusick sorry but you are getting off topic a bit. My question has to do with the API field type definitions and not about updating embedded field data.
Fair enough. I wanted to try to make sure you understood what I was saying, since you seemed to think that each declaration was a new 'copy' instead of a single entity that was being updated (either the value or the field type), and I wanted to not only let you know that it's not multiple copies but also further explain why you'd call it multiple times in a flow (which from what I understood from your first comment, you cautioned other users against).
Let me try to answer your original question again:
> @"w.patrick.gale" said:
> I am looking at the API documentation for adding embedded data fields to my surveys
https://api.qualtrics.com/reference#insert-embedded-data-fields and would like to know what the different types of 'Valid embedded data field types' mean for the
embeddedDataFields parameter? It isn't clear if data must be in a specific format to be saved to these embedded data field types or if it is simply for 'tagging' purposes and does not constrain the data in any way with regards to format or data length.
> @jpardicusick said:
> So in answer to your first question, as far as I know, it doesn't constrain the type of data you store, but it does tell the analytical tools that Q provides what type of data it is. So if you were to put text in a field you've said is a number, your analysis would probably error out.
If you wanted to test this further to see the impact on your API call, I'd recommend setting the value only once so that you can tell what is causing the change.
> @"w.patrick.gale" said:
> When adding embedded data fields through the survey flow there is no option that I am aware of to set the field types.
>
You can do this with the options link within each embedded data 'block'.
> @"w.patrick.gale" said:
> On a side note, I see we are allowed to have multiple copies of an embedded field in the survey flow (as shown in the screenshot below). I tested adding data to the survey to populate the 'MiscJson' embedded data field and only one copy of the embedded data field appears in the response data, which is good, but makes me wonder about the point of having the embedded data field types.
As I mentioned before, you're not creating multiple copies of the embedded data in your screenshot, you're just creating one and then updating it. So in your example, you set it to be a text set, then removed the field type and gave it a value of 22, 33, and 44 respectively.
There may be additional uses, but from my perspective, the point of the embedded data field types is to tell Qualtrics what kind of data you have so that the analyses are performed correctly. For example, you can't create a breakout with data that doesn't have a field type set.
