Restarting a survey using a different browser causes data loss

Question

TL;DR: I'm going to email this to support because I have documentation, pics, etc. to share, but it is on the forms because I think it is interesting.

I have an odd project.  It consists of two parts.
1) live interviewers approach and ask people a short survey. At the end of the short survey, we gather the respondent's email address or phone number.

2) A few moments later the respondent is then sent an email or SMS with a link to the long survey.

I have this set up so that it is one program/survey in Lighthouse. The reason it is this way is it allows us to easily track those who have/have not completed the long version.

The short survey works well and the email/sms works as well.  After completing the short survey I can see that the test data has populated correctly.

From what I understand, in order for a respondent to pick up from where they left off they need to be assigned some type of password. The trick I have is I cant send interviewers to into the field with 500 links to click on, each one containing a unique password. That is just not feasable.

So, I created a link containing a simple password: &USERID=111 and a variable called initialInterview=1. that indicates this is being done as an intercept/short survey.

Then, on the intro screen (not the start screen, but my intro screen). I ran the following perl

[% Begin Unverified Perl

# Create a hash table, left side is RespNumb (I'm going to go up to 50,000 or so). Right side is randomly generated passwords that are accepted in the password field in the start screen.
my %hash = (
    1=>'1RI2KYPL6YB1',
     2=>'1BZC8BULV4PU',
     3=>'I5YDEUM0C13Q',
      4=>'CTTVZAOYGCUC',
      5=>'ID6CXDF6CXUO',
      6=>'AMHLLKYAIJAO',
      7=>'S8WUQ0OFKV5A',
      8=>'YKD9W7NO9EUN',
      9=>'2CM5NU48DRUY'
 );

# Creating a perl variable based on respondent number, then looking that number up in a table, assigning it to a new variable then setting the USERID variable to the new variable
my $respNum = RESPNUM;
my $newUserID = $hash{$respNum};
SETVALUE("USERID",$newUserID);
End Unverified %]

This <u>WORKS</u>. I am successfully able to reassign the value of USERID.  When I go into the admin module I can see all of the data and it looks correct (including the USERID).  

As mentioned above, this is part 1) the short survey. When this is submitted the respondent (me) gets an email with a link.  The link (designed to be clicked on by a different person on a different device) carries forward the newly assigned password (userid) successfully. It also retains the respNum (as I would hope).  However, all of the previous data is erased.

This is very strange. I thought that one purpose of a password field was to allow a respondent to leave and come back.  Which is what this is doing...it just happens not to be going anywhere in between and the data from the short survey should still be there when they come back to take the long survey, but it is gone.

I'm going to email this to support as well because I took several screenshots AND I can provide the ssi file and specific study information (none of which I want to do here), but I like it on the forums because I think it is interesting and am probably going to try to get a talk out of it :).

Comments

Currently if any pass-in variables on the URL have different values (or they are missing) when the respondent comes back into the survey, all prior answers are limbo data cleaned and the respondent starts back at the first question.  Pass-in variables can be used in skip logic etc. so changing them is similar to changing an answer in the survey.

I'm interested to know what everyone thinks of this behavior.  Should we change our code to ignore this case, essentially allowing pass-in variables to change and to not trigger data cleaning?

---

I vote for allowing pass-in variables to change and to not trigger data cleaning (but you knew that was my vote). :-)

Answer 1

So it sounds like this happens EVERY time, so not really a different browser issue, but upon a restart in the long version.  I have a feeling this has to do with the history cleaning that is built in.  I have had several studies where I've done similar things, starting interviewer based and then passing a link to a respondent to finish online with a changed variable to indicate it was passed on.  The issue I had was CHANGING a pass in variable.  The software reads that as a something that could affect the survey flow and clears previous responses to start at the beginning.  I was able to resolve this with Justin at Sawtooth.  He provided me some modified Perl files to replace on the server which bypasses that 'reset' functionality.  Then I was able to change the value of a passed-in variable seamlessly and continue with the survey.  Hopefully that is your issue and this helps.