Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guest customers don't create Craft users, and this creates issues with discounts etc. #885

Closed
bossanova808 opened this issue May 30, 2019 · 12 comments

Comments

@bossanova808
Copy link
Contributor

Description

(as per recent Discord discussions...)

The current behaviour in Commerce is that Commerce users are really quite separate to the core Craft concept of users.

To summarise current behaviour:

Basically, in Commerce everything is keyed by the order email.
Craft User accounts are not created by default.

Recently, register on checkout was added, which means one can add, say a checkbox, during checkout, and if the customer checks this a Craft user IS created (and an email for account activation/setting of password is sent).

At any point, if someone who was previously a guest decides to register as a user - either during a later checkout or simply using a registration form - then all previous orders and addresses are joined to the new user account, as long as they register with the same email.

For consideration/discussion:

I think we should consider whether orders from guest users should in fact create Craft user accounts by default - but (for guest users) in a pending/can't log in state (and not (or only optionally) trigger an account creation email, since they have chosen to logout as a guest). Or at least have a facility for this as an option.

The fact this doesn't happen has become an increasing frustration over time, particularly in the area of promotions/discounts, where user groups are very very handy. E.g. if one wants to offer future discount coupon based on the purchase of a particular item, that currently involves more module code than it really should, I feel. If user accounts were always created, then a method for assigning people who have bought product X to group Y becomes a simple thing.

As ever, one can work around this via module code. And perhaps that is enough. However having lived with Commerce for some years now, I personally don't see advantages to NOT registering guests as users (as probably in some specific user state like Guest Commerce User or similar, and I do see disadvantages.

Further implications:

  • Performance issues with large high volume sites/therefore huge numbers of users?
  • Privacy - I am not sure if privacy/GDPR/right-to-forget considerations come in to play? Not a huge issue (yet) in Australia, but definitely a growing issue. That said, for ecommerce once needs to save details (e.g. to prevent or minimise payment fraud liability and so on) - so in reality I think this is a non issue and one that would be allowed under most privacy regimes - I just mention it as a consideration, but I really don't know much about it.
@engram-design
Copy link
Contributor

I think its pretty presumptuous to create an account automatically for a person going through checkout, if they haven't opted to do so. I suppose that's what a Customer is for, which gets created as soon as you have a cart (which gets turned into an order). A customer and user can be linked, but they don't have to.

There's lots of important information missing in a customer though that would be useful. I wonder if gearing discounts, etc towards customers is an option? There's no such thing as a customer group though..

I'm probably on the fence about whether this should be in the core (in my opinion), or if it should be done through a custom module - which it certainly can right now.

A downside to creating users for even guests at checkout is that you'll potentially end up with user cruft, with thousands of users that don't have a password and will never log in. Keen to hear more potential issues we're not thinking of!

@bossanova808
Copy link
Contributor Author

bossanova808 commented May 30, 2019

I'm certainly open to alternate mechanisms rather than making Craft User accounts for sure. The key issue, really, is to be able to store extra data for Commerce customers (one way or another) - such as what they have bought and when, and then to be able to act on it.

But there's lots of uses/needs for extra data - e.g. for addresses (which should be elements!), notes, whatever...which in effect kinda means....what User accounts can already do, right? So perhaps...why re-invent the wheel?

The question is, if the user is not aware of the Craft User account being there, in what sense is it actually presumptuous? It's an implementation only detail that allows the business to service the customer better, that has zero effect on the customer's perspective of how they are interacting with the business.

@gojira32
Copy link

The question is, if the user is not aware of the Craft User account being there, in what sense is it actually presumptuous? It's an implementation only detail that allows the business to service the customer better, that has zero effect on the customer's perspective of how they are interacting with the business.

I agree. You wouldn't even have to send an "activate your account" email if you didn't want to. It's really just for customers who happen to create an account after the fact - you'd want them, IMO, to be able to see their historical order data. As @bossanova808 mentions it is also handy as a store owner being able have aggregated data for a user in order to trigger certain events, lump them into user groups etc. etc.

Under Magento we've had so many support tickets where a user checked out out as a guest, created an account afterwards, logged into to their account, only to find no order history in their account.

It's crap UX and creates unnecessary customer support tickets.

Whether this should be in core, I'm not sure, but either way it should be an easy thing to execute if desired.

@bossanova808
Copy link
Contributor Author

@gojira32 Just to be clear, the consolidation of orders does occur already with later registrations. Whenever someone registers, any previous orders that were made as guests will be available for the new user. And, IIRC, the most recent addresses as well (might be all, I cant' recall right now)

@lukeholder lukeholder added the 💡 enhancement Ideas and suggestions label May 30, 2019
@lukeholder
Copy link
Member

Not keen at all to generate a user for every guest. If you could be a little clearer about the information you want to retain about the guest customer when they do become a user, please list more concrete examples.

@bossanova808
Copy link
Contributor Author

Well, it's likely to be different for every business, but in our case, the example above is a real one. As always, there are lots of ways to implement these examples, of course, but my desire is to have a relatively easy, non-code approach that store admins can use to set this sort of thing up - right in Craft itself.

Concrete example: We sell a particular loss leading product that gets folks interested in what we do - they pay $10 for it, and we want them (and only them) to get $10 off their first order. We tried doing this with a coupon code, but then the coupon code can (and does) become public, so we get folks using the code who have not bought the product, for example. So what we want is a way to store this record of purchase on the customer, that then ties into the discount system (if customer in this group, then they can use this discount once). Ideally, in a product field, we'd have a chooser thing the admins could use to express 'customers who buy this product/variant should be put into this group). The discount system can already express a discount like this, but in practise it is basically useless because of guest customers.

Another one:
Users buy a product, and this then gives them access to a digital download. If all customers are Users, and thus we can group them, then we can use the same mechanism - add to group, and in their dashboard test on this group and give them access to the files. (Of course, plugins can do this other ways...I know).

In most cases, the data we want to use will be for segregation - basically creating groups of customers based on how they have related with the store, what they have purchased. Sure, you can do this with some custom code and Mailchimp, but I for sure don't want to be tied to that vendor, and Craft has all this User group stuff built in, so it seems the logical and easy place for it.

Once you have segregated your customers - done automatically, of course, as manually simply isn't practical - you open up a huge number of marketing possibilities that can really power a business. (Mailchimp are pretty much pivoting their entire business model now that they have recognised this).

Much better if this is done all in one back end though (at least to the point of segregating the users, even if not the actual mail-out - but with that Campaigns plugin, for example, think of what becomes possible to achieve, all within Craft!). Craft/Commerce are so close to this already...but the discounts/promotions/marketing side is very weak, and to my thinking a big reason for this is the complications that come from the current guests vs. users split.

Further, things like this can make reporting (and the making of reporting plugins) - vastly easier. And reporting, as we all know, is another big gap in Commerce right now.

In short, the disparity between some customers being guests (no easy way to get at data and tie in to discounts) - and the others being Users (where we can do all sorts of fancy thing easily) - just create a point of confusion and dramatically limits functionality. I the context of stores, you generally have super admins, admins, and customers. And for all those, you typically want to store data, set up into groups etc. I don't personally see, given all that Craft Users allows in terms of functionality, why guest customers should be some other concept than a User...just not sure what the advantage to that really is, but there definitely seems to be quite significant disadvantages in terms of functionality.

As ever - this is my thoughts on it, based on my business! It would be great if others chipped in their thoughts and use cases...

@RitterKnightCreative
Copy link

I share Jeremy's sentiment here though maybe not the proposed implementation. There are a couple of things this touches on that are super important.

It would be great if users were treated more like entries. Maybe a user—in this case, someone who purchased an item but never registered... and who also happens to be signed up to your email list—can be an entry but without certain abilities.

If they become a user, then they can login and gain those extra abilities like save credit cards, etc.

Right now, we can't put any extra data on users and I think that's really the crux of the issue.

As mentioned, trying to run specials to non-registered users is impossible. It also becomes harder to setup one-time use codes to incentivize users to complete their order, for example.

If coupon/promotional codes could apply/relate back to only certain user entries or certain tags (and not just user groups), that would be interesting.

Ideally user login data (password, credit card details, addresses, locked out status, other housekeeping stuff) can really be separate from the business data we need (order details, cart abandonment, etc).

FWIW I've seen some implementations, for example, WooCommerce, when a guest account places an order, it's basically just a new user with a randomly set password. That implementation seems pretty dirty to me and I think Commerce can do better than that.

@lukeholder
Copy link
Member

@bossanova808 Is this solved with the 'register on checkout' feature?

@lukeholder lukeholder added the ℹ️ status: need more info When waiting for user to supply database or more information. label Oct 11, 2019
@bossanova808
Copy link
Contributor Author

@lukeholder No - might be worth a re-read of the above (in all your spare time ;)

The basic issue is we can't store any info about guest customers easily. We can use fields on users, but for a lot of orders those are not created. So I propose either creating them in a pending state (if they complete an order as a guest) - or (probably better) - some other way to deal with commerce customers & storing data for them.

@lukeholder
Copy link
Member

I think this might be solved with #1043

@lukeholder lukeholder added 👤 customers 🛒 checkout and removed ℹ️ status: need more info When waiting for user to supply database or more information. labels Jan 28, 2020
@RitterKnightCreative
Copy link

@lukeholder mostly solved.

However, I just ran into an edge case today with a client where a customer had placed an order and put the wrong email address (hotmail.con) and I think later registered for account user the right email.

However, the wrong email address was somehow still associated with the actual order he placed which was needed to view the content in the portal.. We were able to fix both but Craft didn't know they were not connected which caused an issue in the content portal. He couldn't see the content because his order wasn't associated with that account.

The workaround was I created a new order under with the new user account and marked the order as complete. Commerce was smart enough at that point to associate the old order with the newly created one since that older one and gotten changed in the meantime, so I just removed the phantom order since it was no longer needed.

registerOnCheckout is false because I'm asking the user to register for an account after the order is placed. They set their password on that "thank you" screen and then are able to view the content immediately. Not sure if having it on would have made a difference in this case or not?

In the order entry screen, I couldn't "fix" the older order. I could remove the non-user customer but couldn't select the "right" Craft User customer.

Basically there should be a way to associate users with commerce customers. The guest consolidation mostly takes care of this but there also doesn't seem to be a way to do run that task manually?

@bossanova808
Copy link
Contributor Author

So there's definitely been some improvements in seeing and changing customer info like addresses. That's great. And the whole user vs. customer thing is, from the Craft UI perspective, a lot clearer. All great progress.

But - we still can't easily store data 'against' customers - e.g. for discounts and promotions based on prior purchases - unless I am missing something? I.e. discounts such as 'if the customer has ever bought this, offer them this discount on X' type stuff. But I know that rules is a bit part of Craft 4, so I am guessing this work needs to wait till then, which is fair enough.

Also - as above, it becomes clearer over time that consolidating (merging) customer accounts - would be hugely useful. For all those folks who accidentally create multiple accounts under different and/or incorrect emails (so when you merge, perhaps it can keep both emails?). This happens all the time unfortunately....customers make A LOT of mistakes in orders. The more chance our operators have to help them out and tidy up their junk, the better the ultimate customer experience is.

@craftcms craftcms locked and limited conversation to collaborators Jul 21, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

6 participants