Best practice question labels for auto-mapping in dashboards

Not sure i am a big help here, as this is an area our team struggles with given breadth of our programs. 

We maintain a data governance file (excel) that lists all variable names across each program and before creating any new question/variable names we cross check if there is a suitable existing name used across programs.  So even if there is some variation to question in other programs if it’s close enough we will align naming, so it can be analysed/shown together more easily down the line.  

We also have the issue of renaming them on the dashboards, and for those who export seeing different labels.  So again having a separate record of each of these in excel we can share is a MUST for us.  Character limitations also have prevented us really solving this as well, with descriptive question/data labels,

Thanks @ScottG. I feel like the Support documentation on this topic is a bit lacking. Here and here there is a bit of explanation but no insight as to how the choice of labels affects export of data, import in data projects, mapping in dashboard data. There are some helpful Community post, like this one about the best export tags, this one about matrix labels, and this one about internal IDs, but not much about best practices for Question Labelling.

Here is what I have, again with export and dashboards in mind:

• Use short and descriptive labels that summarize the question content and are easy to identify in reports and exports.
• Avoid using special characters or spaces in your labels, as they may cause errors or confusion when exporting or importing data.
• Use consistent naming conventions for your labels, such as Q_Theme1, Q_Theme2, Q_Theme3, etc., depending on your survey structure and logic.
• Label every point on your response scales to avoid misdirecting respondents or misinterpreting data. Use clear and balanced labels that match the question type and the measurement level.
• Use unique labels for each question, even if they have the same wording or format, to avoid duplication or ambiguity in data analysis1.
• Use descriptive labels for matrix questions, such as M_QuestionText_RowText_ColumnText, to capture the full context of each response option1.
• Use labels that match the question type, such as MC_SingleAnswer, MC_MultipleAnswer, TE_SingleLine, TE_MultiLine, SL_Slider, etc., to facilitate data processing and visualization1.
• Use labels that reflect the survey logic, such as Q_SkipLogicCondition, Q_DisplayLogicCondition, Q_RandomizationCondition, etc., to make it easier to track and troubleshoot the survey flow1.
• Use labels that indicate the measurement level, such as NOM_NominalScale, ORD_OrdinalScale, INT_IntervalScale, RAT_RatioScale, etc., to ensure appropriate statistical analysis and interpretation
• The Export Tags in a Matrix Table should include the question number or it won't appear in the export. E.g., you will have to type the Export Tag as Q5_Snowboot instead of just Snowboot.
• Plan for Scalability: If there's a chance you'll add more similar questions in the future, leave room in your naming convention. For instance, if you have MC_sat_general_ORD, consider what you'd name a new, related question added later.

• Document Your Conventions: Create a reference guide or legend that explains your labeling conventions. This will be invaluable for anyone else working with the data or for your future self.

• Test Export and Import: Before finalizing your survey, do a test export and import to ensure that all labels come through correctly and that there are no issues with the auto-mapping feature.

For example, if there are three similar satisfaction questions, one would need to use unique labels for each question, even if they have the same question type and response scale. One could do this by adding a suffix or prefix to the label that indicates the specific aspect of satisfaction that is measured:

1. General customer satisfaction: MC_sat_general_ORD
2. Satisfaction with the relationship: MC_sat_relationship_ORD
3. Satisfaction with the information provision: MC_sat_information_ORD

Any tips?

Thanks @ScottG, that's useful. We have a similar file, but less extended.

I asked Support about this issue, specifically to optimize auto-mapping bteween Data Project and Survey Data as sources in the Dashboard Data. It might be relevant to this discussion:

This was the question:

Context: We have many projects, so we use our own templates for both surveys and dashboards. In a template dashboard all the widgets are in place, and the variables are the same as in the survey template. When we start a new project, I just copy the template and then add the new survey (also from a template) as a source. I also add a Data Project, containing the responses for exactly the same questions from last year. The variables should auto-map, and the data should automatically populate the widgets.

Question: how to organize Question Labels in order to optimize auto-mapping?

This was the answer:

After talking with my team, the labels for the imported data project, are the path the system generates on the backend in order to be able to locate and display the information for the matrix table. 

In the dashboard, the labels are different because the question exists in the survey; the label can be changed for the actual question since it is not a system path like the imported data project label.

 I just wanna reiterate that my goal wat optimizing auto-mapping of a secondary source. According to Support, this should not even be possible:

You will need to manually map the fields of additional data sources since additional data sources will not be automatically mapped according to this support page. (Support employee)

Additional data sources will not be automatically mapped, so you will need to map their fields manually. (Support page)

Even though Support employees and the Support page suggest that the additional sources need to be mapped manually, but when I test it, this does not seem the case.

The best option, at least for MC, seems the one where I have a unique code where the question number should be, and the question label left empty (which will be replaced by the long question title when loeading to a Data Project). This works even when you add a Data Project with the same variable, automatically created via a workflow.

OR, if you don't need the Data Project, a unique code where the number should be and a short version of the question for the question label.

@JohannesCE I thought that was the case, but good to know it’s the same approach.  I’ve definitely raised the idea of it to Qualtrics in a few forums, so fingers crossed it happens at some point.

I also want to be able to edit a saved widget in the library and have that update automatically everywhere it is used.  It would save me hours each week and more importantly ensure consistency across our quite complex programs.

@ScottG did you post the idea in Coda? If you give me the title we can upvote is :)

New Idea reference in CODA is EV-1930

(Ability to save your dashboard page templates and specific widget configurations within the library to select from.)