I am a long time user - just upgraded from my own hosting to Pro Hosting because I kept getting a high percentage, over 50%, totally blank survey responses. I just launched my first survey hosted and already received 56% blank in the first few hours. How is this possible when there is one required field for a given survey? This was the WHOLE reason I joined the Professional Hosting so I would stop getting these blank responses. Can anyone please help?

Thanks,

William cline

Whenever someone opens the link, a line in the data base is created (what you call response). If the person does not type anything, this field in the database stays empty.

This is just a normal behaviour, it does not hurt. You can delete those empty lines after a while (make sure it is not a very recent response, because this person might still be responding) or you just leave them as is. You can export only the completed responses for your analysis later.

Actually I find the % relatively low. Depending on the way your respondents are approached for this survey, it is very normal that many people completely ignore it, many just open it because they are curious and then leave, etc.

holch wrote: This is just a normal behaviour, it does not hurt.

A big percentage of LimeSurvey user seems to just stay in the application. They want the raw data of LimeSurvey to be a clean data without exporting and cleaning.

Since the GDPR consent is implemented a feature to prevent creation of an record before a certain threshold (after consent/welcom) would make sense.

But those answers shouldn't even appear in statistics or are they?

A way to prevent that these first pages hitters get saved. I think about the situation, when IP address and date/time is saved. People currently could hit the clear button (if shown) to delete the record.
Currently there is no easy way to prevent creation of a record for first page hitters (think about when having URL data). Easier way would be a cleaning function, which is triggered ever x hits or minutes to clean first page hitters. I wouldn't use it, cause I would be to afraid a glitch in the code deletes everything

If you are impacted by the GDPR, then you might think twice about recording IP data together with date/time anyway.
But from what I understand, if you clearly documento what you are doing with this data, how long it is stored, etc. you can store this data anyway for a certain time.
So I don't see the big deal there. Of course, if someone wants their "personal data" (I still refuse to consider IP addresses as personal data, as long as I do not have direct access to the ISPs information about who had the IP at the certain point of time easily available) deleted, you can just ask them for their IP address and the date time they have participated, so you can delete their record. They won't be able to do it, which proofs that you don't really have identifyable date stored.

If don't make error,
New response is created ONLY after welcome page move next ( with or without GDPR)

It must be the case in all survey and i think it's the case in a lot of survey.

Survey than can create a new line at first page
- Survey without welcome page
- Survey show All in one (maybe there are survey where it's OK : not created)

Survey than can have issue about this system (see only welcome page : no response line)
- Prefill by URL GET param (i don't think, but still unsure)
- Survey with default value
- Survey with Equation and www.limesurvey.org/manual/Expression_Man..._Assignment_Operator

If a line appear on a simple survey at welcome page : It's must be reported as major issue (and more major with GDPR)

If a line appear on a survey with a special cas : it muts be reported as an issue.

I still do not understand why a person 'looking' at the survey would be recorded unless they press the 'submit' button on the survey. This makes no sense that an IP address would be recored without a survey response?

I still do not understand why a person 'looking' at the survey would be recorded unless they press the 'submit' button on the survey. This makes no sense that an IP address would be recored without a survey response?

The submit button only appears at the end of the survey. Most surveys are in question by question or group by group mode, not in all in one. If you would only create a row in the database when the submit button is triggered, then if the internet connection drops, nothing is saved.

What I don't understand is what the big deal with empty rows is. I have never felt that they were a problem for me personally. But of course there might be good reasons why they are a problem. Maybe you want to elaborate a little bit? Might help to find a solution.

Thank you all for your replies. How can I know that these 'blank' entries are not real responses that for some reason the software does not record the data. If I'm NOT using captia and all 7 questions are in one survey, then how does anything get saved without the 'submit' button being pressed? I fear I am loosing a huge percentage of responses to a glitch in the software recording the record with no data.

clinegroup wrote: How can I know that these 'blank' entries are not real responses that for some reason the software does not record the data.

You never will know for sure for every case.
You can only test your survey with different browsers and devices before. And with every update of LimeSurvey you will need to do these tests again.

I have 165 responses for a current survey with 111 blank. It's significant issue or bug regardless.

Since you're a customer of LimeSurvey GmbH you might ask for support via the ticket system. None of the people currently on this thread are part of LimeSurvey GmbH. Just developers and users which are no involved in the hosting offered by LimeSurvey GmbH.

DenisChenu wrote: If don't make error,
New response is created ONLY after welcome page move next ( with or without GDPR)

Since the welcome page can be disabled, there are many surveys without a welcome page.
So we have many surveys, which have a respondent record without any button click on the first question page.