How are you managing state for anonymous users before they have an account?

In the Progressive Web App there are situations where you want to enable your visitors to interact with the application and do things that require tracking data before you force them to create an account.

How in this situation are you managing the state of the application for that user before he/she is logged in? I ended up using @karimoo’s dummy user trick proposed here which works but has the undesirable side effect of creating a dummy user record for every anonymous visitor to the homepage of the application. This ends up yielding a haystack of 95% garbage records in the User collection.

I looked into doing a periodic purge of any dummy user records on the User collection but that then has its own negative consequence which I learned later which is that the app then hangs indefinitely on the redirect screen for anyone who had previously visited anonymously but subsequently had their dummy user record deleted. They would have to clear their cookies to regain access to the app.

Just curious how others are handling this issue. AFAIK there is no such thing as session or client variables one can set to manage user actions & preferences prior to them becoming a registered user. Has anyone solved this in a more elegant way than the dummy user approach or are you just accepting that the User collection will always be 95% cruft? thanks

1 Like

Hi @grid7,

Very good question. In my experience, I practice the following:

  • try to sign-up “pseudo-user” as late as possible. E.g. for the services bookings type of app, I try to allow non-logged-in users view the main page, service catalog, product details, info pages. And create the pseudo-user account only when user tries to make the booking. The same logic applies to ecommerce apps (create a user only when he/she adds the product to cart).
    This reduces the quantity of these dummy accounts.

  • I try to be sure that I convert the user to “real” one whenever possible. Taking the same example of booking app - I suggest to sign up upon booking finish, I also suggest to sign up on the main screen if I see that this user is “pseudo-user” (“Don’t lose your data!”), in some other places if appropriate.

Interesting to know why your app hangs if dummy user is deleted. I’ve never observed such experience. Would be curious to know how is it possible to replicate such behaviour (and therefore to think how to protect against it).

Would love to discover what other Adalo builders think!

Best,
Victor.

1 Like

Thanks for your response @Victor

So there’s no way you’re aware of to facilitate the experience of adding products to a cart and deferring account creation until the point of checkout?

Yes that’s exactly what I’m doing now. My account creation form actually doesn’t create anything- it updates the temp user to give them a real email address. That unfortunately doesn’t solve the problem of a bunch of cruft dummy users in the db though unless I’m missing something.

Very curious to hear how others handle this challenge. I try to let visitors become invested in the app prior to gating functionality behind an account creation form and I don’t see an elegant way to accomplish maintaining state with anonymous users in a way that doesn’t inject a bunch of dummy accounts in the db.

Presumably it’s because they’re cookied with their dummy userID and the redirect page senses that but fails to find their User record when it’s trying to redirect to the home screen that requires data stored in their user record. I will film a Loom video to reproduce this and append here.

1 Like

Hi @grid7

My pleasure :slight_smile:

Once I’ve experimented with “Session variables” collection and tried to put the data there… but it ended up in so much hassle, pseudo-users turned out to be much better solution.

When you add a product to cart, you somehow must (a) have a cart and (b) have cartitems linked to this cart. And the cart itself should be somehow attributed to an exact user who is adding products in this app.
As a crazy idea - you can have a screen with inputs, store the cart ID in one of them, and then use the value from this input to manage the cart… but anyway you will have to manage the “orphaned carts”. And you will have to build 2 versions of cart management (one with users, another with inputs). As for me, pseudo-users is easier solution.

This would be really interesting to see!

Best,
Victor

@Victor as promised here’s the video reproducing the issue:

Hi @grid7,

Thanks!
This behaviour is weird. I’ve created a sample app, and tried to do similar things (not with automatic redirect, but with manual one). In my case after I delete the guest user, the app still takes me to the home screen (which is I guess expected), but also allows to update the Full Name and displays it (of nonexistent user!!).

I guess this is somehow related to browser storage, which is, in my opinion, is not correctly used by Adalo in this particular case.

Here is a short video with a workaround idea: https://youtu.be/M1IGDWA6qa8
In brief, the logic is:

  • when user gets to Home screen, before proceeding further, I check if it is a Guest user
  • if it is (and if the data is taken from browser cache, even if the user is deleted) - I force logout the user and send him to Welcome screen
  • if not - he/she can proceed to real home screen.

Best regards, Victor.