How to distinguish saved data from one user to the next

Hi bubblers,

(This might have been resolved earlier but I can’t find it…)

I am building an app for research. Survey volunteers select their current debt type (via drop down) and amount (as text field), then press “save” and add the next debt same way. This without the need to create an account (anonymous). The database is saving the info (that’s working) but I can not see which debts belong to user A and which are from user B. It is just a list of every debt entered. I want to have a field in the debt list that is unique to the “current user” so I can compare debts of different users. Does the db do that or how can I do that?

Look: your USERS are participants in a study. Presumably, they know they will be providing some data.

If you want them NOT de-identified, then you’re effed, if you ALSO want them identified.

The problem and solution here are NOT technological.

You CAN make a private site where users provide no personally identifiable data to the system.

HOWEVER, you are stuck with the problem of how to enroll them. Basically, you must create the users and — out-of-band — give them (the people represented by the User object) a unique ID and assigned password so they can log in.

They also need to know that, while this doesn’t identify then PERSONALLY, their data at time of collection is (of course) NOT aggregated, but exists in a form in which it’s tied to a specific data entity.

Srsly, think about this in terms of an old-fashioned study: where folks might fill out a paper form. In that case, you know that it was “Subject A” who provided the answers on “sheet-of-paper A” because — well, they’re on THAT sheet of paper.

Not a tech problem, really. It’s a study design problem.

Hi Keith, Sorry, bad explaining on my part. I want to have the debts of a particular user connected to that user (without asking for the user to create an account). Just by going to the website, entering the debt info and clicking “save”. When the user saves his debt info, does the db group that info under “current user”? Like a 'current user x" field and the next user “current user y”. I can’t see that is does anywhere.

OK, so here’s how you might do that:

Things to understand:

  1. If you write something on “Current User” – even when that person (more correctly, “session” as it might not be a person, right?) is not logged in – you are essentially just dropping a cookie on that browser session.

  2. This is not the same as saving data to the database. (In truth, such data MIGHT be written to the database with a temporary connection between the db object and the user session, but you should not count on that.) The solution I propose works around that anyway.

  3. That “Current User” (even one not logged in or who has never visited before) will be assigned a Unique ID, just like a signed-up user, if we drop data on them. This will be useful to us.

OK, understanding the above, structure your app this way:

  • Make it clear to the study participants that it would be best to complete the survey in a single sitting. While they MAY be able to come back and find their data preserved, it is only stored locally until they complete the survey and click “UPLOAD DATA”. (Techsplaination: If they dump their cookies, their “saved” data will be lost. This may or may not be literally true, but you do not care, because your app is not going to depend on the USER datatype.)

  • Go ahead and construct your page(s) for gathering info. It sounds like what users will be doing is building a list of things. (You call them “debts”, but we do not care what they are. I’m going to call them DATA POINTS. Create a data type for “DATA POINT”. That type needs to have all the info (fields) to describe a data point. Like “Amount Owed” (a number), “To Whom” (a text), etc.)

  • Now, on the USER data type, add a field for “Data PointS” (see what I did there?). This will be a a field of type “DATA POINT” and it is a LIST.

  • On your pages, the users (who again are not logged in nor are they signed up) build up their profile, perhaps building this list of DATA POINTS, and perhaps answering other questions, the answers to which you will add to the Current User. Create a data type to handle ALL of these things. Sounds like it’s something like a data type called “Study Response”. Study Response might have the following fields:

– Study Participant ID (type text – spoiler alert: this is where we will eventually shove the User’s unique ID)
– Data Points (again a list of type Data Point)
– Anything else you need to save (Like “Answer A” of type “whatever you need to record.”)
– Etc.

  • At some point, the user will be done entering information. At that point there is a button. The button is labeled “UPLOAD DATA”.

  • When that button is clicked, you will grab data from the Current User and store it in the database in a way that it no longer depends on “Current User”:

– Create a new thing of type Study Response.
– Set its various fields as appropriate.
– For the Study Participant field, take Current User’s Unique ID.
– For Data Points, set a list from the Current User’s Data Points
– For anything else, do what you need to do.

Now your “Current User” has responded to your study and you no longer care if that user’s cookies expire or Bubble expires their User data, etc.

Now, there is no guarantee that a user will not answer your survey twice. But it should be fairly easy to tell duplicate submissions. (For one, they will PROBABLY – but it cannot be guaranteed – have the same Study Response’s Study Participant ID.)

In short: You CAN save stuff on “Current User”. But you cannot know or rely on the persistence of data associated with “Current User”. However, you can decouple these things, by saving data that was (at one time) associated with “Current User” as separate objects in a new data type.

… Alternatively: You could take every single-dingle thing the user does and save it to the database with custom data types that all include a field for “Study Participant ID”. But that seems silly. Just let the user answer the questions (what I call “build up their profile”) and let them click to “Upload.”