如何在登录后合并用户数据？ [英] How to merge user data after login?

问题描述

如果你正在构建一个eshop或任何其他应用程序使用会话存储请求之间的一些数据没关系。
如果您不想通过要求他注册来惹恼用户，您需要允许他在可能的情况下匿名执行某些任务（用户确实需要注册的原因） 。

有一个问题 - 如果用户决定使用他现有的个人资料登录，他可能已在他的匿名会话中有一些数据。

合并这些数据的最佳做法是什么？我猜应用程序应该在可能的情况下自动合并它，或者让用户决定在哪里不可能。

但是我要求更多是如果有任何资源

我有两个基本的解决方案：

1. 保留匿名会话数据，并添加另一个关系，说明实际使用的位置和合并方式。


2. 数据

我们可以说第一个解决方案可能会更有效，因为关于任何关系的信息可能意味着数据比数据少关于用户。但是，这也意味着在读取数据时需要更多的努力（因为我们首先需要读取关系以获得实际的用户数据）。

是否有任何文章/资源为此特定用例设计数据结构（匿名+用户数据）？

解决方案

（

其实，这里有两个完全独立的问题：

• Q1 - 在什么阶段需要使用者登入/上载？




• Q2 - 数据并发和冲突解决（见下文）。

）

---

Q1是一个纯可用性问题。

• 避免或延迟强制用户尽可能登录！

即使需要保存状态也不足以成为一个原因。如果我作为用户不感兴趣保存那个状态，那么不要强迫我签名！请！

您（作为网站）证明强迫我签名的唯一原因是当我（作为用户）要数据供以后使用。在这里，我作为用户浪费时间签署只是发现网站没用。如果你想摆脱太多的用户，这是正确的方法。在任何其他情况下，请尽可能延迟！

为什么这么多网站完全忽视这样明显的规则？我可以看到的可能原因：

• R1-开发者友好vs用户友好。是的，它是开发人员友好要求立即登录，所以我们不需要麻烦并发（Q2）。所以我们可以节省开发人员的成本，时间等。但每一个节省都是成本！在这种情况下称为用户体验。这不一定是你想要寻找保存的地方。




• R2 - 设计师或经理作出的决定是一个室内爱好者:)她生活快乐生活包围超级快速电脑与超级快速的互联网连接，不能想象的歌曲可以是那么难以为任何用户。那么为什么这么大呢？这么多原因：




• 它打破了应用程序流。生活在上个世纪的网站仍然替代整个屏幕有时相当冗长的形式。一些形式设计不当，有些有不稳定的指示，有些根本不工作。有些提交按钮是由于某些原因在浏览器中禁用的。
  一些表单设计师有天才的想法，锁定某些领域，几乎没有明显的变化或颜色。




• 如果网站认真对待用户的数据，那么它必须请求电子邮件并且必须真实的！为什么？如何还原我忘记所有其他凭证的用户？为什么要验证？如果用户错误地输入了电子邮件怎么办？如果我不验证，下一次用户尝试恢复密码与她正确的电子邮件，恢复失败，所有数据丢失！显然，但仍有网站不在那里。然后我需要等待，直到收到验证电子邮件并点击，希望，格式良好和唯一标识的链接，不会打破我的浏览器，也不会得到一些有趣的字符，由于破坏的编码检测，使整个链接不可用。 / p>




• 互联网连接可能很慢或中断，使每一个额外的步骤都变得痛苦。即使有良好的连接，它发生在这里和那个页面突然需要更长的时间加载。此外，电子邮件可能不会立即到达。然后不耐烦的用户开始愤怒地点击重新发送验证链接。在这种情况下，90％的网站重新发送其与新令牌的链接，但也禁用所有以前的令牌。然后几个电子邮件以不可预测的顺序到达，并且糟糕的用户必须猜测，哪一个（并且只有一个）仍然有效。现在为什么这些网站发现很难保持几个令牌活跃，只是对于这种情况，是超出我的理解。




• 最后还是这么难忘记网站的习惯坚持所谓的用户名。现在，在我的电子邮件旁边，我必须努力想出这个唯一用户名，与任何以前的用户不同！非常感谢你使它甜蜜和容易！我自己的处理方式是使用我的电子邮件作为用户名。可悲的是，还有网站不接受它！那么如果一些有趣的类型使用我的电子邮件作为他的用户名？如果你的电子邮件是[e-mail]不是那么不现实。

---

这里有一些可以减轻使用者痛苦的指南：

• 只有在您绝对需要时，才强迫我登入/我有机会选择不去！




• 使它成为一页表格，因此我知道我要做什么，不用说，尽可能少使用输入字段。理想情况下只需使用电子邮件和密码（可能两次），无用户名！




• 将您的登录表单作为小窗口显示在网页顶部，以从窗口单击单击它摆脱它。不要强迫我寻找关闭按钮，或者更糟糕的是，我可能会混淆其他的图标！




• 帐户，前进和重新加载按钮。不要在重新加载时清除表单！不要放清楚按钮！很容易意外点击。您要求我填写的数据不应过长，我无法重新输入，无需帮助来清除。

---

现在问题Q2。这里我们有众所周知的解决冲突的问题，任何时候两个数据需要合并。例如，匿名数据和注册的用户数据，但是每当两个用户修改相同的数据，或者相同的用户在不同时间从不同设备修改它，或者本地存储的数据与服务器数据冲突时，等等。

但无论源是什么，问题总是一样的。我们有两个数据，说两个对象$ obj1和$ obj2，你需要产生你的单一合并对象$ obj3。逻辑可以像服务器的对象总是赢得的规则那样简单，或者最后修改的对象总是赢得，或者最后修改的对象键总是赢或任何更复杂的逻辑。这真的取决于你的应用程序的性质。但在每种情况下，你所需要做的就是使用参数$ obj1，$ obj2来写你的逻辑函数，返回$ obj3。

许多情况是在每个对象属性（键）上存储时间戳，并让最新的更改的键在同步时获胜。例如

想象我已经在设备AA上修改了密钥A和B，然后从设备上记录了今天BB输入另一个B并将其保存到服务器，然后切换回我的设备AA，在那里我是匿名的，进入另一个A而不从昨天更改旧B，然后意识到我想登录和同步。然后我的本地B显然是老的，应该明显不会覆盖B，我更改最近在设备BB上的值。在这个看起来很复杂的情况下，上述解决方案无缝和有效地工作。相反，将时间戳只放在整个对象上是错误的。

现在在某些情况下，保持这两个对象是有意义的。通过添加额外的属性来区分它们，例如在Radek的问题中建议的情况1。例如，Dropbox在文件末尾添加了用户X冲突复制。就像在Dropbox案例，这是明智的情况下的协作应用程序，用户喜欢有一些版本控制。
然而，在这些情况下，你作为开发人员只需保存两个副本，让用户处理这个问题。

如果在另一方面，你必须根据用户的数据编写一个复杂的逻辑，有两个不同的副本挂在周围可能是一场噩梦。在这种情况下，我会将数据分成两组（例如创建两个对象中的一个）。第一组具有表示作为整体的应用程序的状态的数据，其对于唯一是重要的。对于这些数据，我将使用上述或类似的冲突解决方案。然后第二组是用户特定的，其中我将这两个数据作为两个单独的条目存储在数据库中，正确地标记它们（像Dropbox），然后让用户处理他们的项目的两个（或更多）条目的列表。

最后，如果数据库管理的额外复杂性使开发人员感到不安，并且Radek要求提供资源引用，我想一次杀死两个苍蝇通过提及博客条目 StackMob离线同步，其解决方案同时提供数据库和用户管理功能，从而减轻开发者的痛苦。当然，在搜索数据同步，冲突解决等方面还有更多的信息。

总之，我必须添加强制性免责声明这里写的只是我自己的想法和建议，每个人都应该使用自己的风险，如果你突然得到太多的快乐用户使你的系统崩溃，不要让我负责）。

由于我正在开发一个应用程序，我正在实施所有这些方面，我当然非常感兴趣听到其他意见和其他人对这个问题说什么。

It doesn't matter if you're building an eshop or any other application which uses session to store some data between requests. If you don't want to annoy the user by requiring him to register, you need to allow him to do certain tasks anonymously when possible (user really have to have a reason for registering).

There comes a problem - if user decides to login with his existing profile, he may already have some data in his "anonymous" session.

What are the best practices of merging these data? I'm guessing the application should merge it automatically where possible or let the user decide where not possible.

But what I'm asking more is if there are any resources about how to do the magic in database (where the session data are usually stored) effectively.

I have two basic solutions in my mind:

1. To keep anonymous session data and just add another "relation" saying what's actually used where and how it's merged
2. To physically merge these data

We could say that the first solution will probably be more effective, because the information about any relation will probably mean less data than data about the user. But it will also mean more effort when reading the data (as we firstly need to read the relation to get to actual user data).

Are there any articles/resources for designing data structures for this particular use case (anonymous + user data)?

解决方案

An excellent question that any app developer using user data should ask, and, sadly very few do :(

In fact, there are two completely independent questions here:

• Q1 - At what stage require user to sign in/up?

• Q2 - Data concurrency and conflict resolution (see below).

And here some analysis for each of the questions. Please excuse my extra passion coming from my own "frustrated user" experience. :)

---

Q1 is a pure usability question. To which the answer is actually obvious:

• Avoid or delay to force the user sign in as much as possible!

Even the need to save state is not enough a reason by itself. If I am as user not interested in saving that state, then don't force me to sign! Please!

The only reason for you (as website) to justify forcing me to sign is when I (as user) want to save my data for later use. Here I speak as user having wasted time on signing only to find the site useless. If you want to get rid of too many users, that is the right way. In any other case - please, delay it as much as possible!

Why so many sites completely disregard such an obvious rule? The possible reasons I can see:

• R1- developer friendly vs user friendly. Yes, it is developer friendly to require sign in right away, so we don't need to bother with concurrency (Q2). So we can save developer costs, time etc. But every saving comes at a cost! Which in this case is called User Experience. Which is not necessarily where you would like to look for saving. Especially, since the solution should not be that hard (see below).

• R2 - Designer or Manager making the decision is an "indoor enthusiast" :) She lives happy life surrounded by super-fast computers with super-fast internet connection and can't imagine singing up can be that hard for any user. So why is it such a big deal? So many reasons:

• It breaks the application flow. Sites living in previous century still replace the whole screen with sometimes rather lengthy form. Some forms are badly designed, some have erratic instructions, some simply don't work. Some have submit buttons that are for some reason disabled in the browser used. Some form designers have genius idea to lock certain fields with barely noticeable change or colour. Then don't show me the field if you don't want me to fill it!

• If the site is serious about user's data, it must request Email and must verity it! Why? How else shall I get back to user who forgot all other credentials? Why verify? What if user mistyped the email? If I don't verify it, next time the user tries to recover password with her correct email, the recovery fails and all data are lost! Obvious, yet there are still sites out there not doing it. Then I need to wait till the verification email is received and click on, hopefully, well-formatted and uniquely identifiable link that does not break in my browser, nor get some funny characters due to broken encoding detection, making the whole link unusable.

• The internet connection can be slow or broken, making every additional step a piece of pain. Even with good connection, it happens here and there that page suddenly takes much longer to load. Also the email may not arrive right away. Then impatient user starts furiously clicking the "resend verification" link. In which case 90% of sites resend their link with new token but also disable all previous tokens. Then several emails arrive in unpredictable order and poor user has to guess in vain, which one (and only one) is still valid. Now why those sites find it so hard to keep several tokens active, just for this case, is beyond my understanding.

• Finally there is still this so hard to unlearn habit for sites to insist on the so-called "username". So now, beside my email, I have to think hard to come up with this unique username, different from any previous user! Thank you so much for making it sweet and easy! My own way of dealing with it is to use my email as username. Sadly, there are still sites not accepting it! Then what if some fun type used my email as his username? Not so unrealistic if your email is [e-mail]. But why simply not use Email and Password to avoid all this mess?

---

Here some possible guidelines to relieve user's pain:

• Only force me to sign in/up if you absolutely need and give me a chance to choose not to!

• Make it one page form, so I know what I am up to and, needless to say, use as few input fields as possible. Ideally only Email and Password (possibly twice), no Username!

• Show your sign in form as small window on top of your page without reloading, and allow me to get rid of it with single click away from that window. Don't force me to look for "close" button or, even worse, icon I could confuse for something else!

• Account for user to click back/forth and reload buttons. Don't clear the form upon reload! Don't put clear button at all! It is too easy to click by accident. The data you are ask me to fill should not be so long in first place, that I could not re-enter it without the need of "assistance" to clear.

---

Now to question Q2. Here we have well known problem of conflict resolution that occurs any time two data need to be merged. For instance, the anonymous data and the registered user data, but also whenever two users modify the same data, or the same user modifies it from different devices at different times, or locally stored data conflict with server data, and so on.

But whatever the source is, the problem is always the same. We have two data, say two objects $obj1 and $obj2 and you need to produce your single merged object $obj3. The logic can be as simple as the rule that server's object always wins, or that the last modified object always wins, or the last modified object keys always win or any more complicated logic. This really depends on the nature of your application. But in each case, all you need to do is to write your logic function with arguments $obj1, $obj2 that returns $obj3.

A solution that will possibly work in many cases is to store timestamp on each object attribute (key) and let the latest changed key win at the moment of synchronisation. That accounts e.g. for the situation when the same user modifies different attributes when being anonymous from different devices.

Imagine I had modified keys A and B on device AA yesterday, then logged today from device BB to enter another B and saved it to the server, then switched back to my device AA, where I am anonymous, to enter yet another A without changing the old B from yesterday, and then realised I want to log in and synchronise. Then my local B is obviously old and should clearly not overwrite the value of B that I changed more recently on device BB. In this seemingly complicated case, the above solutions works seamlessly and effectively. In contrast, putting the timestamp only on whole objects would be wrong.

Now in some cases, it could make sense to keep both objects, and, e.g. distinguish them by adding extra properties, like in case 1 suggested in Radek's question. For instance, Dropbox adds something like "conflicted copy by user X" to the end of the file. Like in Dropbox case, this is sensible in case of collaboration apps, where users like to have some version control. However, in those cases, you as developer simply save two copies and let the users deal with that problem.

If on the other hand, you have to write a complicated logic based on user's data, having two different copies hanging around can be a nightmare. In that case, I would split data into two groups (e.g. create two objects out of one). The first group has data representing the state of the application as a whole, that is important to be unique. For that data I would use the conflict resolution as above or similar. Then the second group is user-specific, where I would store both data as two separate entries in the database, properly mark them (like Dropbox does), and then let users deal with the list of two (or more) entries of their project.

Finally, if that additional complication of database management makes the developer uneasy, and since Radek asked to give a resource reference, I want to "kill two flies with one shot" by mentioning the blog entry StackMob offline Sync, whose solution provides both database and user management functionality and so relieves the developer from that pain. Surely there is a lot more info to be found when searching for data concurrence, conflict resolution and the likes.

To conclude, I have to add the obligatory disclaimer, that all written here are merely my own thoughts and suggestions, that everyone should use at own risk and don't hold me responsible if you suddenly get too many happy users making your system crash :)

As I am myself working on an app, where I am implementing all those aspects, I am certainly very interested to hear other opinions and what else folks have to say on the subject.

这篇关于如何在登录后合并用户数据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！