有哪些方法可以在数据库中存储有关匿名/访客用户的信息？

Question

我们的应用程序具有在线商店以及其他功能，通常要求用户在完成销售之前进行注册，在此过程中创建一个独特的customer_ID。当他们返回时，他们可以登录并从数据库中检索他们的联系方式和交易历史。

我们现在正在探索在“匿名”或“访客”客户的情况下该怎么做，向不想注册的客户开放在线商店，以及登录后端应用程序的销售，其中获取客户的电子邮件、邮政地址等太费时了。该解决方案在网上商店之外也有应用。

多家公司使用同一个数据库，数据库建立在party model结构之上，因此我们探索了几种方案：

1. 将所有匿名客户存储在transaction 表中一个预定义的customer_ID 下：
   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. 其他一些受 Stack Overflow 启发的解决方案！

加法

#2 和 #3 的组合已在别处提出 - 尝试为每个客户存储一条记录，如果可能，使用电子邮件地址，或者在每次访问时使用新记录。

我应该指出，我们需要为每个匿名客户存储一条记录，但似乎关系数据库是为处理关系而构建的，所以有一个 NULL 或customer_ID 在transaction 表中没有引用实际客户记录似乎是错误的......

我还必须强调，这个问题的目的是确定有哪些现实世界的解决方案可以记录没有提供邮政地址或电子邮件地址的“临时”交易（想象超市结账）以及在线商店交易，其中电子邮件地址和邮政地址是否被存储。

SO 社区过去使用过哪些解决方案？

Answer 1

假设所有在线订单都需要一个电子邮件地址，您可以在每个未登录的客户完成每个订单时为他们创建一个临时帐户。

这可以通过使用结帐时提供的送货地址和其他信息来填写帐户，然后通过电子邮件向他们发送一个随机临时密码来完成（如果需要，可以选择在第一次登录时将其标记为需要更改）功能内置在网站中）。这需要他们花费最少的精力来设置帐户，并允许他们登录以检查他们的订单状态。

由于您的数据库中的主键是 customer_id，如果他们继续使用相同的电子邮件/地址/等创建新帐户，它应该不会导致冲突，除非您已经有代码来防止重复。但是，很少有人创建多个临时帐户，因为使用电子邮件发送给他们的密码登录比再次输入他们的数据更容易。

对于后端订单，我们通常以与上述相同的方式为每个客户创建一个帐户。但是，如果他们没有电子邮件地址（或者他们只想通过电话购买），我们会生成一个包含他们的送货信息和空白电子邮件地址的帐户（必须编写一个例外代码以不发送临时密码/订单确认时为空白）。 customer_id 提供给他们，他们的运输信息和公司名称存储在帐户中，以查找和加快未来的订单。

Answer 2

我怀疑这个问题是否有任何完美的解决方案。您只需要做出选择：与不强迫客户完成完整注册流程所带来的转化率提升相比，保证可识别的客户历史记录有多重要。

如果您不强制注册，您将无法 100% 识别回头客。有人可能会争辩说，即使 使用 注册也是不可能的，因为用户有时会出于各种原因选择创建新帐户。但是，通过了解已有的数据，您也许可以做一些“足够好”的事情。

例如，在某些国家/地区，邮政编码非常具体。它们是否足够具体？取决于您在哪些国家/地区开展业务，以及您的客户群是如何建立的。如果您倾向于每个家庭只有一个用户，也许可以。

或者根据您支持的付款方式，您可以考虑构建信用卡号的单向哈希（“伪唯一 ID”）。一些支付解决方案实际上确实返回了一个唯一的“付款人 ID”，这可能是完美的——假设您从您支持的所有支付服务中获得了一些东西。

Answer 3

我会分配一个唯一的客户 ID 来保存数据，然后在同一匿名购买者的未来购买中，您可以查看相同的电子邮件地址和/或地址和邮政编码的第一行是否已经存在。如果您要电话号码，请进行比较。基本上，您需要一些相当独特的东西，同时消除可能的错误（例如，只查看地址的第一行 - 很可能有不止一个 123 Main Street！但是只有一个邮政编码为 ABC123 的 123 Main Street )。

一旦您知道这一点，您就可以自动为他们创建一个帐户 - 向客户发送一封电子邮件，说明您注意到他们以前购买过，并使用此电子邮件地址和此自动生成的密码为他们节省时间。当他们第一次登录时，做一个快速的安全检查（可能是最后一张发票的价值），然后让他们检查他们的详细信息。您甚至可以在结帐过程中执行此操作。我认为通过展示您可以通过自动执行来节省他们的时间可能是一种奖励。

如果您不想这样做，则可以设置 cookie，但如果您在欧盟境内进行交易，则必须警告用户（cookie 法律）。

如果有人拥有不同的电子邮件地址和邮政地址，问题可能是他们为商务订购，然后他们可以为个人使用订购（很难说，因为我们不知道您在卖什么）。

Answer 4

当然，您可以使用 cookie 跟踪销售会话。但也要在您的网站上注册匿名用户，但不要让他们意识到他们正在填写任何注册表单。让他们遵循销售流程，并在销售流程结束时生成一个唯一的客户 ID 并通过电子邮件发送给他们并显示该通知在他们完成销售后在网站上登录，只需输入他们的客户 ID 即可登录。

Answer 5

我通常使用用户 IP，我只用一个 ID 和他的 IP 地址创建一个帐户。当他注册时，我只是更新他的记录。除了 IP 之外的其他东西也可以（并且应该）使用，例如创建一个随机令牌以放入 cookie 以绕过任何正在使用的会话系统，这样您就可以使其持续更长时间。

现在，在应用程序中，您必须使您的用户类能够使用此 IP/令牌、真实会话或您可能拥有的任何其他登录系统来“识别”您的用户。

Answer 6

我的做法是：一点也不。

简单地说，让人们通过 paypal 或任何您放置的支付解决方案付款并从那里获取数据，使用提供的 API 处理付款后自动创建用户和订单。

此时您拥有所需的所有信息，并且绝对可以存储足够用于统计/垃圾邮件营销的信息。

保持简单，不需要任何东西，甚至不需要人们输入客户 ID 或电子邮件，他们都会喜欢它。

这样做我仍然拥有我可能感兴趣的所有信息，并且用户体验尽可能快速/简单。

Answer 7

嗯……我们为来宾用户生成一个 uniq ID——用户名的哈希值或 uuid，并将其存储在购物篮表中。如果您不介意将此类数据弄乱您的数据库，您也可以将其冷存储在客户表中。 uuid 存储在客户浏览器中的 cookie 中，直到他签出购物篮。如果用户决定稍后/在签出购物篮之前注册，cookie 也很适合将匿名帐户（及其购物篮的内容）分配给有效帐户。

Answer 8

我会创建一个唯一的客户 ID，并将其作为 cookie 存储在用户的机器上。这应该会减少拥有多个客户 ID 的用户数量。

但是说真的，只要您的 id 数量没有达到数十万（如果是的话，恭喜！），只要您对客户有适当的索引，它就不会损害您的数据库标识列。

如果您为每个客户设置 id=0，您的行数不会一样多吗？如果您想保留所有数据，我认为这是不可避免的，对吗？零 id 也可能会导致您的索引出现额外问题。