#393 Guest User Record

Nov 21, 2012 | 9 minutes | Authentication

Instead of presenting a sign up form to the user, consider creating a temporary guest record so the user can try out the application without filling in their information up front. They can then become a permanent member afterwards.

Click to Play Video ▶

Download:
source codeProject Files in Zip (71.5 KB)
mp4Full Size H.264 Video (19.9 MB)
m4vSmaller H.264 Video (10.3 MB)
webmFull Size VP8 Video (11.7 MB)
ogvFull Size Theora Video (23.1 MB)

Travis about 12 years ago

This would brie exactly what I was looking for, I was just thinking about how to do this on another app. I think stripe does this, seems great from usability perspective

Erlingur about 12 years ago

Yeah, it's great. I had to implement something similar a few years back but I managed to make it whey too complicated, Ryan's solution is much simpler!

Thiyagarajan almost 12 years ago

Damien Wilson about 12 years ago

It really, really is. The only downsides I've seen are managing a lot of junk accounts from expired sessions and limiting DB load when migrating/deleting guest users.

Ryan covers a simple solution for guest deletion here, but if you were to implement something similar in production you'd probably want to limit it to guest accounts who's sessions had expired. This is definitely stuff you'd probably be best off running as a background process or worker.

Thiyagarajan almost 12 years ago

good

Tomaž Zaman about 12 years ago

Thank you for the video. I must admit though, I'm not a fan of this approach - numerous experiments have proved that this approach doesn't really improve conversions.

Nicolas Mondollot about 12 years ago

Interesting.
Intuitively I'd say it has a big positive impact, but I confess it's only a gut feeling as I've never monitored such things.
I'd be very interested in seeing actual numbers. Is there some literature out there about this?

David Verhasselt about 12 years ago

I bet it goes something like this:

On the one hand, if the user can try it, and doesn't like it after all, they definitely won't convert (and will look for another solution).

On the other, if the user needs to register before they can use it, they've already gone through the hurdles and might as well use it then. Even if they like it just as much (less) as in the previous example, the fact that the user will need to go through some more hurdles to find something else might keep the user with your solution.

Of course there's a tight balance there, but it's the same thing with credit cards and trials. Intuitively you might think it's best to allow people to do a trial without entering a CC#, but in fact if you make them enter a CC# for a trial, they'll be more prone to convert, since it's automatic (path of least resistance from then on for the user - they don't need to do anythign anymore)

Greg Silcox about 12 years ago

I think it would be better to make an app that is so compelling the user wants to join. Why have grumbly users that are only there because it is too much work to switch.

Thiyagarajan almost 12 years ago

David Verhasselt over 11 years ago

If the only reason they're not switching is because they already have an account, then they're probably not that grumbly. We're talking about subtle unconscious cues that influence the stats in otherwise unnoticeable ways here, not torturing users and tying a lease around their neck.

elsiemkcee about 10 years ago

Yes exactly...Even I think they aren't that grumbly..

Chris almost 12 years ago

Does it help SEO, in the sense that all the membership-only material is made available for search engines such as google etc to scan?

Christiane Valejo almost 7 years ago

I don't think so, why ?

Renaud CUNY about 12 years ago

Thanks a lot Ryan for this great episode (one more :).

I'm just fighting a bit with Devise, and after a day sweating, I'm asking for help. First, here's the way I went, it could help some other folks around:
- I duplicated Devise Validatable class to apps/models/devise/models/validatable.rb, and patched the validation function to check for guest (password_required? and email_required? + created a custom one to ignore the validates_format_of :email as I store a uuid instead of an email for my guests, a bit dirty but efficient :)
- I then patched some of my controller on actions where I want to create a guest user on the fly (ex: if you create a content) and used sign_in_and_redirect(:user, my_new_gest_user) to log the guest in after creation.

The whole thing works fine, I start as anonymous, go to add a content, my patched controller does the job and I end-up as a guest user, logged in and with a content. I can then play with my app and create other pieces of content, works fine.

BUT (there is a but :) I'm stuck with the step where I need to create a new user if the guest wants to actually sign_up. Devise will refuse any sign_in or sign_up action, which makes sense as I'm kind of knocking on a door which is already opened :). Here I must admit I'm limited by my still-partial knowledge of Rails. I have the intuition I should override Devise controller to pass it as a parameter my guest_user.id, and tell him "Be nice, store this somewhere and let me signup" so I could then post-process it with something like your move_to method... but I can't find my way through Devise.

If anybody has gone through, I'll be glad to have a few crisps of advise to follow :).

Night here in Europe, I'll sleep on my code, cheers to those still working somewhere else :).

Brendan Stennett about 12 years ago

You could store the guest_user_id as a session variable, logout the guest then direct them to a sign up form. After that, generate the devise registrations controller, and do something along the lines of:

          ruby
        
after_filter :transfer_guest_information, only: [:create]

private
def transfer_guest_information
  if session[:guest_user_id]
    guest = User.find(session[:guest_user_id])
    current_user.move_from(guest)
    session[:guest_user_id] = nil
  end
end

Hope this helps!

Renaud CUNY about 12 years ago

Hi HuffModdy,
That's pretty much what I was trying to do :), thanks for putting me back on the way :).

For those who try the same, don't forget to add some logic to give back his session to the user if he cancels the signin or sinup for any reason (he returns to the homepage, for instance).

Something like this should do the trick (before_filter in application controller)

          ruby
        
def fallbacks_to_guest
  if controller_name != 'registrations' && controller_name != 'sessions' && controller_name != 'passwords' && controller_name != 'confirmations'
    if current_user.nil? && session[:guest_user_id]
     user = User.find(session[:guest_user_id])
     sign_in_and_redirect(:user, user)
    end
  end
end

Gant Laborde about 11 years ago

If you're going to session, why not store the whole thing in session, and then add it to their account upon sign up?

No guest accounts needed.

Michael about 12 years ago

No offense but, using a gem is fine but dont you think you could write it from scratch so you dont work 1 day of adding a feature to it? It will take you a couple of hours to write authentication from scratch.

Mohamad El-Husseini about 12 years ago

Totally agreed. Writing authentication from scratch is so simple. The ugly side of Devise comes out when you start customising your app, and you spend more time fixing such issues than you would have had you written authentication from scratch.

Thiyagarajan almost 12 years ago

good

Jan Berdajs about 12 years ago

There's no problem with destroying the guest user, just call reload first.
Although you would still need the rake tasks for users who never become members.

Zac about 12 years ago

I wrote an article on doing this but in my solution, upon registering I just updated the current anonymous user instead of creating a new one and transferring all their data.

http://highgroove.com/articles/2012/10/09/lazy-user-registration-for-rails-apps.html

Philippe Guégan about 12 years ago

Instead of playing with booleans to change objects behaviors, what you guys think about STI?

Personally, I'd made the Guest class as a subclass of User. It's then possible to override behavior (validations, methods, etc.) without any ugly if. It sounds more OO to me. Am I right?

Lukas Svoboda about 12 years ago

By STI you are extending the the parent eg. all validations are inherited. I think that there is not simple way how to override validation.

Frédéric about 12 years ago

Instead of booleans (or STI), you can also use a state machine (last week pro episode ;-)) to keep track of the user's status (guest, registered user, admin...), for instance as describe in this railstips blog (this example modeli{s,z}es an inactive/active/abusive user).

Ryan Bates about 12 years ago

Great points everyone, this is actually the topic of my next episode!

Lecky about 12 years ago

save(:validate => false) if current_user.guest?
Bang! :)

Ryan Bates about 12 years ago

True but then you need to worry about every time you save the record after that. I am very careful whenever saving without validations.

Jonathan Barrett about 12 years ago

Could you not just direct "become a member" to an edit form for the guest user?

Gonzalo Arreche about 12 years ago

It would be cool, but maybe you have to make sure the user changes his email address, the name, and so.
Else, if users need to confirm their email addresses in the "normal signup" (for example), then you are leaving an open back door.

Michael Roher about 12 years ago

How would you test the guest behaviour with RSpec/Capybara?

hzz7223591 almost 12 years ago

i have <%= button_to "游客入口", signup_path, :method=> :post %> and
def create

@user=params[:user] ? User.new(params[:user]) : User.new_guest
if @user.save
  flash[:success] ="注册成功"
  session[:user_id] = @user.id
  @user.type=workers
  redirect_to '/superadmins/inspect'
else
  render 'new'
end

end
but when i click button it can't creat a new guest.it just link to signup_path.Doesn't the method post work?

Tiago Vieira over 11 years ago

When I substitute has_secure_password for

require 'bcrypt'
attr_reader :password
include ActiveModel::SecurePassword::InstanceMethodsOnActivation

when I do a signup he says unknown attribute: password_confirmation

nfriend21 about 10 years ago

same here

Raul Riera about 11 years ago

I am a bit curious about why do we send the user to the :new action instead of the :edit action when they want to become a full member?

Thomas Anthony over 10 years ago

I was thinking along the same lines. The logic is very simple. Set the guest field to false when updating the attributes within the update action. If it is the user's intent to become a full-fledged member, they will input the information required to submit the form to the update action. Bottom line, there are very few reasons to set the guest field to true again, thus setting the guest field to false on each update will easily circumvent the issue of converting users.

vishalsingh123 over 9 years ago

id is increasing when making guest users . what is the best way to solve this problem... please help

bparanj over 8 years ago

This episode has been updated to Rails 5 as a blog post Supporting Guest Users in Rails 5 App

slither io over 7 years ago

Many thanks for sharing this very diverse opinion post where each expert has no doubt shared his best knowledge on the topic. Have more success in your journey.