This task represents the work with conducting an analysis to learn what type of in-page questions can be presented and recorded when using Quick Surveys

What we know so far
-A single answer question can be displayed and recorded (yes/no question)

Open Questions

• Can it display and record multiple questions?
  • ✅ Yes, The EXTERNAL survey mode can display and record multiple questions.
  • No, The INTERNAL/INLINE survey mode only supports a single question/answer scenario.
  • ℹ We could possibly create a new client VIEW that supports a parent/child question/answer object structure. Currently questions are generated in a loop, we tap into this action an add a parent question with child answers. We also need to explore the implications of this change. This would require new UI/UX insights.

• Can it display and record a free text question?
  • ✅ Yes, The EXTERNAL survey mode can display and record free text questions -> assuming the chosen provider application supports this feature.
  • ✅ Yes, The INTERNAL/INLINE survey mode can display and record free text questions.

• Can it support conditional questions (e.g. Question A yes/no IF answer is yes display Question B)
  • ✅ Yes, The EXTERNAL survey mode can support conditional questioning -> assuming the chosen provider application supports this feature.
  • No, The INTERNAL/INLINE survey does not yet support this feature.
    • ℹ We could consider creating a new client side VIEW that supports conditional rendering. We also need to explore the implications of this change. This would require new UI/UX insights.
  • ℹ Joaquin also pointed out the following: Right now QS sends an event where the data recorded is the survey name + survey answer(s). The backend is a simple key value store, and the value field has already been stretched by adding multi-answer responses and free form text by having the values appended together with a separator which is kind of brittle. Adding multiple questions could be done by changing what the key stores, instead of survey name it could have survey name + question key, but there would be no assurances on the backend about the integrity of the data, since the storage is so ad-hoc. The data could present answers to a survey where certain questions don't have a value, or other inconsistencies. And the analysis of it will require trickier and trickier queries splitting the field value many times per survey (for each question) and increasing the complexity of the queries substantially.