Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Pixelairport's avatar

Store guest email in user db

I think about storing emails together with extra information in user table. Information like: I'm interested in this product, I want to get the newsletter, I vote for something. That is why I want to store these emails in user database, without a password. Is there anything against it? Or would this be a good way. I want to do it, because user can later create a real account and already have subscribed to a list or something else. And of course, I will do double opt in, if user did something.

0 likes
2 replies
LaryAI's avatar
Level 58

Storing guest emails in the user database can be a practical approach, especially if you want to allow users to later convert their guest interactions into a full account. However, there are a few considerations and best practices you should keep in mind:

  1. Database Design: You can add a column to your users table to differentiate between guest users and registered users. For example, you could use a boolean column like is_guest to indicate whether the entry is a guest.

  2. Nullable Password Field: Since guest users won't have a password initially, ensure that the password field in your database is nullable.

  3. Email Uniqueness: Consider whether you want to enforce email uniqueness across both guest and registered users. If you do, ensure that the email column is unique.

  4. Data Privacy and Security: Make sure you comply with data protection regulations like GDPR. Always use double opt-in for newsletters and other communications to ensure consent.

  5. Conversion to Registered User: When a guest user decides to register, you can update their record with a password and any additional information they provide.

Here's a simple example of how you might structure your users table:

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    password VARCHAR(255) NULL,
    is_guest BOOLEAN DEFAULT TRUE,
    interested_in_product BOOLEAN DEFAULT FALSE,
    wants_newsletter BOOLEAN DEFAULT FALSE,
    voted_for_something BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
  1. Handling Guest Actions: When a guest performs an action like subscribing to a newsletter or voting, update the corresponding fields in their record.

  2. User Registration: When a guest decides to register, you can update their is_guest field to FALSE and set their password.

Here's a simple example of how you might handle a guest converting to a registered user:

// Assuming you have a User model and a registration form
$user = User::where('email', $request->email)->first();

if ($user && $user->is_guest) {
    // Update the user record with the new password and set is_guest to false
    $user->password = bcrypt($request->password);
    $user->is_guest = false;
    $user->save();
} else {
    // Handle the case where the email is not found or already registered
}

By following these guidelines, you can effectively manage guest users and their transition to registered users while maintaining a clean and secure database structure.

martinbean's avatar
Level 80

@pixelairport There’s nothing stopping you storing emails for those purposes (just make sure it is mentioned in your website’s privacy policy).

If a user does create an account at a future date, you could allow the user to “claim” things like product notifications if you find entries with the same email address.

1 like

Please or to participate in this conversation.