Hi I am hoping someone will be able to shed some light on this for me...

I have been creating surveys for clients to send out to their databases, with the link containing ‘ID=XXX&’ before the ‘lang=en’ part at the end of the standard URL. The organisation inserts unique IDs in place of the XXX’s, so that each person receiving the survey has a unique URL with their own unique ID embedded into it. Therefore the link looks like this:  ifsp.limequery.com/123456?ID=XXX&lang=en , with the XXXs replaced by an ID number.Within the surveys, we have a hidden Q called 'ID' – having this allows any responses to have an ID logged so that the responses can be linked to client records. Before a survey is sent out, this is tested and the IDs pull through fine.

However, we have been noticing that on some occasions, once the survey has been sent out by the organisation, IDs are not pulling through. We are not running a panel-integrated survey and have set it up so that the clients we work with can just input an ID number after ‘ID=’ within the URL. Therefore we do not need help with how to get the ID into the URL, it is an issue with getting the ID to log 100% of the time in the responses of the survey.The method we use is mostly effective but in some cases it does not log anything at all, and we cannot see any pattern to this (i.e. where the person stops in the survey or the format of their ID number).

Any further advice on how we can rectify this would be really great!

Thanks so much,

Abbie

What version of LimeSurvey is used? How long is the URL including all variables?

Personally I would not use "ID" as a variable name. Often this variable is used inside applications like LimeSurvey and bugs might cause issues with such a common name. Normally it should work, but I often use uncommon variable names to prevent collision at any point.

There are user which modify the URL, when they see ID and sometimes copy only part of the URL into the browser. Or the URL is truncated in invitation emails, where only a part is transferred into the browser.

Hi,

Thanks for getting back to me!

The version I am using is 3.25.11 and the URL we send looks like this:

ifsp.limequery.com/123456?ID=XXX&lang=en .

We emphasise that the link should look like it does above when they plug it into emails. However it could be possible that when they do this, their software adds to the end of the URL? Would this have an impact?

I will make a note of avoiding using names like ID for a variable name, thank you.

I think the most puzzling part is that this works for the most part, with some just not recording properly for whatever reason.

Thanks again!

Abbie

Are the surveys multilingual? (Is there a language switcher on the welcome screen?)

Hi,

It is not multilingual and we do not have a language switcher in the welcome screen - is this likely to help with feeding in from the URL?

Thanks,

Abbie

Hi jelo,

If I were to change the variable name ID to something unique, do you have a recommendation as to what this should be?

Do you also have any recommendations as to how I can quality check this to make sure it pulls through the ID 100% of the time? As I said previously, when testing it out it works ok but when sent out there are some that do not log properly.

Many thanks,

Abbie

If I were to change the variable name ID to something unique, do you have a recommendation as to what this should be?

ID is something that is used in a lot of places, so what Jelo means is something not so common. There is no "recommendation" for this other to avoid commonly used names, like ID, or code, or whatever that could be used by the app already. I doubt that using "ID" is the problem though. But could be. If you use something less common, chances are lower that it is already used in the app and could cause problems.

abbiephilan wrote: ...we do not have a language switcher in the welcome screen - is this likely to help with feeding in from the URL?

No, but that may have been a bug.

Are you sure that there are no conditions or relevance applied to the ID question?