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

Question

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

Сейчас мы изучаем, что делать в случае «анонимного» или «гостевого» клиента, открываяИнтернет-магазин для клиентов, которые не хотят регистрироваться, а также для продаж, зарегистрированных в бэкэнд-приложении, где получение электронной почты, почтового адреса и т. д. потребителя занимает слишком много времени.В решении также есть приложения вне интернет-магазина.

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

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

Добавление

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

Я так и делаю: совсем нет.

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

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

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

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

Answer 8

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

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