Какие способы хранения информации об анонимном/гостевом пользователе в базе данных?

В нашем приложении есть интернет-магазин среди других функций, и пользователям обычно предлагается зарегистрироваться до завершения продажи, создавая уникальный customer_ID в процессе. Когда они возвращаются, они могут войти в систему, и их контактные данные и история транзакций извлекаются из базы данных.

Теперь мы изучаем, что делать в случае "анонимного" или "гостя" клиента, открывая интернет-магазин для клиентов, которые не хотят регистрироваться, а также для продаж, зарегистрированных в бэкэнд-приложении, где получение электронной почты клиента, почтовый адрес и т.д. - это слишком много времени. Решение также имеет приложения вне интернет-магазина.

Несколько компаний используют одну и ту же базу данных, а база данных построена на структуре party model, поэтому мы изучили несколько вариантов:

Сохраняйте всех анонимных клиентов в рамках одного предопределенного customer_ID в таблице transaction:
- customer_ID = 0 для каждого анонимного пользователя и customer_ID > 0 для каждого реального пользователя
  - Это прямое обращение к жесткому коду в приложение
  - Но более активное участие в определении того, какие клиенты принадлежат к какой компании.
  - Должны ли детали для customer_ID = 0 присутствовать в таблице customer в базе данных или как объект в приложении?
    - Если в базе данных могут быть установлены ограничения на уровне базы данных, чтобы гарантировать, что они всегда существуют?
    - Если нет в базе данных, ограничения внешнего ключа от transaction.customer_ID до customer.customer_ID больше не работают
- customer_ID - это то же самое, что и компания party_ID
  - Легче определить совокупные продажи для каждой компании и т.д.
  - Это путало бы вопросы, поскольку казалось бы, что компания является ее собственным клиентом, а не другими уникальными клиентами.
Создайте уникальный customer_ID для каждого нового анонимного клиента (за сеанс)
- Что делать, если тот же физический пользователь возвращается? Будет много записей, повторяющих одни и те же данные; адрес электронной почты, адрес доставки и т.д.
Используйте другой уникальный ключ, например адрес электронной почты, чтобы обратиться к клиенту
- Не всегда надежный, поскольку люди иногда используют более одного адреса электронной почты или оставляют старые адреса позади.
- Что делать, если адрес электронной почты не принимается, как в случае с цехом, проформовыми счетами и т.д.?
Некоторые другие решения для!

Добавление

Комбинация № 2 и № 3 была предложена в другом месте - попытайтесь сохранить отдельную запись для каждого клиента, используя, по возможности, адрес электронной почты или новую запись при каждом посещении, если нет.

Я должен указать, что нам не нужно хранить запись для каждого анонимного клиента, но похоже, что реляционная база данных была создана для взаимодействия с отношениями, поэтому с помощью NULL или customer_ID в transaction таблица, которая не ссылается на фактическую запись клиента, просто кажется неправильной...

Я также должен подчеркнуть, что цель этого вопроса состоит в том, чтобы определить, какие реальные решения существуют для записи "случайных" транзакций, когда нет почтового адреса или адреса электронной почты (представьте себе супермаркет chekout) наряду с транзакциями в интернет-магазине, где адрес электронной почты и почтовый адрес, независимо от того, хранятся они или нет.

Какие решения использует сообщество SO в прошлом?

Ответ 1

Предполагая, что вам нужен адрес электронной почты для всех онлайн-заказов, вы можете создать временную учетную запись для каждого клиента при завершении каждого заказа, когда они не вошли в систему.

Это можно сделать, используя адрес доставки и другую информацию, предоставленную во время проверки, чтобы заполнить учетную запись и отправить им случайный временный пароль (необязательно, пометив его, чтобы потребовать изменения при первом входе в систему, если это функциональность встроена в веб-сайт). Это требует минимальных усилий для настройки учетной записи и позволяет им войти в систему, чтобы проверить статус своего заказа.

Поскольку основным ключом в вашей базе данных является client_id, он не должен вызывать конфликтов, если они продолжают создавать новые учетные записи с одинаковым адресом электронной почты/адресом/и т.д., если у вас нет кода для предотвращения дублирования. Для кого-то редко бывает создано несколько временных учетных записей, поскольку легче войти в систему с паролем, отправленным по электронной почте, а затем снова ввести свои данные.

Для бэкэнд-заказов мы обычно создаем учетную запись таким же образом, как и выше для каждого клиента. Однако, если у них нет адреса электронной почты (или они только хотят приобрести по телефону), мы создаем учетную запись с их информацией о доставке и пустым адресом электронной почты (необходимо закодировать исключение, чтобы не отправлять временные пароли/подтверждения заказа, когда он пуст). Заказчику дается им, и их информация о доставке и название компании хранятся в учетной записи для поиска и ускорения будущих заказов.

Ответ 2

Я сомневаюсь, что есть какие-то идеальные решения этой проблемы. Вам просто нужно сделать выбор: насколько важно гарантировать узнаваемую историю клиентов, в отличие от улучшения конверсий, которые вы получаете, не заставляя клиента пройти полный процесс регистрации.

Если вы идете без принудительной регистрации, вы не сможете распознать возвращающихся клиентов в 100% случаев. Можно утверждать, что даже регистрация с невозможна, так как пользователи иногда предпочитают создавать новые учетные записи по разным причинам. Но вы можете сделать что-то "достаточно хорошее", понимая данные, которые у вас уже есть.

Например, в некоторых странах почтовые индексы весьма специфичны. Являются ли они достаточно конкретными? Зависит от того, в каких странах вы работаете, а также о том, как строится ваша клиентская база. Если вы, как правило, имеете только одного пользователя в домохозяйстве, возможно.

Или в зависимости от того, какие способы оплаты вы поддерживаете, вы можете подумать о создании одностороннего хэша номера кредитной карты ( "псевдо-уникальный идентификатор" ). Некоторые платежные решения действительно возвращают уникальный "идентификатор плательщика", который может быть идеальным - если вы получаете что-то от всех поддерживаемых платежных услуг.

Ответ 3

Я бы назначил уникальный идентификатор клиента для сохранения данных, а затем в будущих покупках, которые тот же анонимный покупатель заставляет вас посмотреть, есть ли тот же адрес электронной почты и/или первая строка адреса и почтового кода уже существует. Если вы попросите номер телефона, сравните это. В основном вам нужно что-то довольно уникальное, избавляясь от возможных ошибок (например, только глядя на первую строку адреса - очень вероятно, что существует более одной 123 Main Street! Но будет только одна 123 Main Street с почтовым индексом ABC123).

Как только вы это знаете, вы можете автоматически создать им учетную запись - отправив клиенту электронное письмо, в котором говорится, что вы заметили, что они купили ранее, и чтобы сохранить их время, используйте этот адрес электронной почты и этот автоматически сгенерированный пароль. Когда они впервые заходят в систему, выполните быструю проверку безопасности (возможно, стоимость последнего счета-фактуры), а затем дайте им проверить свои данные. Вы даже можете сделать это во время процесса оформления заказа. Я думаю, показывая, что вы можете сэкономить время, сделав это автоматически, может быть бонусом.

Если вы не хотите этого делать, тогда можно установить cookie, хотя вам придется предупредить пользователя, если вы торгуете из ЕС (законы cookie).

Проблема с кем-то, у которого есть другой адрес электронной почты и почтовый адрес, может заключаться в том, что они заказывают для бизнеса, тогда они могут заказать для личного использования (трудно сказать, поскольку мы не знаем, что вы продаете).

Ответ 4

Конечно, вы можете отслеживать сеанс продажи с помощью файлов cookie. но также регистрируйте анонимных пользователей на своем сайте, но не позволяйте им понять, что они заполняют любую регистрационную форму. Позвольте им следовать процессу продажи и в конце процесса продажи создать уникальный идентификатор клиента и отправить по электронной почте, а также отобразить это уведомление на сайте после того, как они завершат продажу и сделают их вход в сайт, просто вводя свой идентификатор клиента.

Ответ 5

Обычно я использую IP-адрес пользователя, я создаю учетную запись только с идентификатором и его IP-адресом. Когда он регистрируется, я просто обновляю его запись. Другие вещи, кроме IP, могут (и должны) использоваться так же, как создание случайного токена, чтобы помещать куки файл в обход любой используемой системы сеанса, чтобы вы могли сделать это дольше, например.

Теперь, в приложении, вы должны сделать свой пользовательский класс способным "идентифицировать" ваших пользователей с помощью этого IP/токена, реального сеанса или любой другой системы входа, которую вы можете иметь на месте.

Ответ 6

Как я это делаю: совсем нет.

Проще говоря, пусть люди платят через paypal или все, что вы ставите в качестве платежного решения, и получаете данные оттуда, автоматически создавайте пользователя и заказ после обработки платежа с помощью предоставленного API.

В этот момент у вас есть вся необходимая информация и, возможно, сохраните достаточно для вашей статистики/электронного спама.

Держите его простым, не требуйте НИЧЕГО, даже людям не нужно вводить идентификатор клиента или электронную почту, и им все это понравится.

Выполняя это, у меня все еще есть информация, которую я мог бы заинтересовать, и пользовательский интерфейс так же быстро и просто, как может быть.

Ответ 7

Mmmm... мы генерируем идентификатор uniq для гостевых пользователей - хеш-значение или uuid для имени пользователя и сохраняем его в таблице корзины. Вы также можете хранить это в таблице клиентов, если не хотите загромождать свою базу данных такими данными. Uuid хранится в файле cookie в браузере клиентов, пока он не проверит корзину. Файл cookie также хорош для присвоения анонимной учетной записи (и содержимого ее корзины) действительной учетной записи, если пользователь решил зарегистрироваться позже/перед проверкой корзины.

Ответ 8

Я бы создал уникальный идентификатор клиента и сохранил его на пользовательской машине в качестве файла cookie. Это должно уменьшить количество пользователей с несколькими идентификаторами клиентов.

Но при всей серьезности, пока ваше количество идентификаторов не попадет в сотни тысяч (и поздравляет, если это так!), это не повредит вашей базе данных, если у вас есть соответствующие индексы для клиента id столбец.

Если у вас был id = 0 для каждого клиента, у вас было бы столько же строк? Я думаю, что это неизбежно, если вы хотите сохранить все данные, верно? Идентификатор нуля может также вызвать дополнительные проблемы с индексом.