Wie können Benutzerdaten nach der Anmeldung zusammengeführt werden?

8

Es spielt keine Rolle, ob Sie einen Eshop oder eine andere Anwendung erstellen, die Sessions verwendet, um Daten zwischen Anfragen zu speichern. Wenn Sie den Benutzer nicht verärgern wollen, indem Sie ihn zur Registrierung auffordern, müssen Sie ihm erlauben, bestimmte Aufgaben anonym nach Möglichkeit auszuführen (der Benutzer muss wirklich einen Grund für die Registrierung haben).

>

Es kommt zu einem Problem: Wenn der Benutzer sich mit seinem bestehenden Profil anmeldet, hat er möglicherweise bereits einige Daten in seiner "anonymen" Sitzung.

Was sind die besten Methoden zum Zusammenführen dieser Daten? Ich schätze, die Anwendung sollte es wo immer möglich automatisch zusammenführen oder den Benutzer entscheiden lassen, wo nicht möglich.

Aber was ich mehr frage ist, ob es irgendwelche Ressourcen gibt, wie man die Magie in der Datenbank (wo die Sitzungsdaten normalerweise gespeichert werden) effektiv macht.

Ich habe zwei grundlegende Lösungen im Kopf:

  1. Um anonyme Sitzungsdaten zu speichern und einfach eine weitere "Relation" hinzuzufügen, die sagt, was wo eigentlich verwendet wird und wie es zusammengeführt wird
  2. Diese Daten physisch zusammenführen

Wir könnten sagen, dass die erste Lösung wahrscheinlich effektiver sein wird, weil die Information über eine Beziehung wahrscheinlich weniger Daten bedeutet als Daten über den Benutzer. Aber es wird auch mehr Aufwand beim Lesen der Daten bedeuten (da wir zuerst die Beziehung lesen müssen, um zu den tatsächlichen Benutzerdaten zu gelangen).

Gibt es Artikel / Ressourcen zum Entwerfen von Datenstrukturen für diesen speziellen Anwendungsfall (anonym + Benutzerdaten)?

    
Radek Simko 21.08.2013, 11:39
quelle

2 Antworten

9

Eine ausgezeichnete Frage, die jeder App-Entwickler, der Benutzerdaten verwendet, stellen sollte und leider nur sehr wenige: (

Tatsächlich gibt es hier zwei völlig unabhängige Fragen:

  • Q1 - In welcher Phase muss der Benutzer sich anmelden / up-up?

  • Q2 - Datengleichzeitigkeit und Konfliktlösung (siehe unten).

Und hier eine Analyse für jede der Fragen. Bitte entschuldigen Sie meine zusätzliche Leidenschaft, die von meiner eigenen "frustrierten Benutzer" -Erfahrung kommt. :)

Q1 ist eine reine Usability-Frage. Worauf die Antwort eigentlich offensichtlich ist:

  • Vermeiden oder verzögern Sie die Anmeldung des Benutzers so weit wie möglich!

Selbst die Notwendigkeit, den Staat zu retten, reicht nicht aus. Wenn ich als Benutzer nicht daran interessiert bin, diesen Zustand zu retten, dann zwinge mich nicht zum Unterschreiben! Bitte!

Der einzige Grund für Sie (als Website), mich zur Unterschrift zu berechtigen, liegt darin, dass ich (als Benutzer) meine Daten für die spätere Verwendung speichern möchte. Hier spreche ich als Benutzer, der verschwendete Zeit beim Signieren verloren hat, um die Seite nutzlos zu finden. Wenn Sie zu viele Benutzer loswerden wollen, ist das der richtige Weg. In jedem anderen Fall - bitte, verzögere es so oft wie möglich!

Warum ignorieren so viele Websites solch eine offensichtliche Regel völlig? Die möglichen Gründe, die ich sehen kann:

  • R1- Entwickler freundlich vs benutzerfreundlich. Ja, es ist entwicklerfreundlich, dass Sie sich sofort anmelden müssen, sodass wir uns nicht mit Nebenläufigkeit (Q2) beschäftigen müssen. So können wir Entwicklerkosten, Zeit usw. einsparen. Aber jede Einsparung hat ihren Preis! Was in diesem Fall User Experience genannt wird. Welches ist nicht unbedingt, wo Sie nach dem Speichern suchen möchten. Vor allem, da die Lösung nicht so schwer sein sollte (siehe unten).

  • R2 - Designer oder Manager, der die Entscheidung trifft, ist ein "Indoor-Enthusiast" :) Sie lebt ein glückliches Leben umgeben von superschnellen Computern mit superschneller Internetverbindung und kann sich nicht vorstellen, dass das Singen so schwer sein kann jeder Benutzer. Warum ist es so eine große Sache? So viele Gründe:

  • Es unterbricht den Anwendungsfluss. Orte, die im vorigen Jahrhundert lebten, ersetzen immer noch den ganzen Bildschirm durch manchmal ziemlich lange Form. Einige Formulare sind schlecht gestaltet, manche haben sprunghafte Anweisungen, manche funktionieren einfach nicht. Einige haben Submit-Buttons, die aus irgendeinem Grund im verwendeten Browser deaktiviert sind. Einige Formulardesigner haben eine geniale Idee, bestimmte Felder mit kaum wahrnehmbaren Veränderungen oder Farben zu sperren. Dann zeige mir das Feld nicht, wenn du nicht willst, dass ich es ausfülle!

  • Wenn die Website die Daten des Benutzers ernst nimmt, muss sie eine E-Mail anfordern und muss sie verifizieren! Warum? Wie sonst soll ich zu den Benutzern zurückkommen, die alle anderen Zugangsdaten vergessen haben? Warum verifizieren? Was ist, wenn der Benutzer die E-Mail falsch eingegeben hat? Wenn ich es nicht verifiziere, wenn der Benutzer das nächste Mal versucht, das Passwort mit seiner korrekten E-Mail wiederherzustellen, schlägt die Wiederherstellung fehl und alle Daten gehen verloren! Offensichtlich, aber es gibt immer noch Seiten da draußen, die es nicht tun. Dann muss ich warten, bis die Bestätigungs-E-Mail eingegangen ist und auf einen hoffentlich gut formatierten und eindeutig identifizierbaren Link klickt, der in meinem Browser nicht bricht, und auch keine komischen Zeichen aufgrund einer beschädigten Kodierungserkennung bekommt, wodurch der ganze Link unbrauchbar wird / p>

  • Die Internetverbindung kann langsam oder kaputt sein, was jeden weiteren Schritt zu einem kleinen Schmerz macht. Selbst bei guter Verbindung passiert es hier und da, dass diese Seite plötzlich viel länger zum Laden braucht. Auch die E-Mail kann nicht sofort ankommen. Dann beginnt ungeduldiger Benutzer wütend auf den Link "Überprüfung erneut senden" zu klicken. In diesem Fall senden 90% der Sites ihre Verknüpfung mit dem neuen Token erneut, deaktivieren aber auch alle vorherigen Token. Dann kommen mehrere E-Mails in unvorhersehbarer Reihenfolge an und der arme Benutzer muss vergeblich raten, welcher (und nur einer) noch gültig ist. Nun, warum diese Seiten es so schwer finden, mehrere Token aktiv zu halten, nur für diesen Fall, ist jenseits meines Verständnisses.

  • Schließlich ist es immer noch so schwer, die Gewohnheit für Seiten zu verlernen, auf dem sogenannten "Benutzernamen" zu bestehen. So, jetzt, neben meiner E-Mail, muss ich mir Gedanken machen, diesen einzigartigen Nutzernamen zu erstellen, der sich von jedem vorherigen Nutzer unterscheidet! Vielen Dank, dass du es einfach und süß gemacht hast! Meine eigene Art, damit umzugehen, ist, meine E-Mail als Benutzernamen zu verwenden. Leider gibt es immer noch Websites, die es nicht akzeptieren! Was ist dann, wenn ein lustiger Typ meine E-Mail als Benutzernamen verwendet? Nicht so unrealistisch, wenn Ihre E-Mail [email protected] ist. Aber warum nicht einfach E-Mail und Passwort verwenden, um all diese Unordnung zu vermeiden?

Hier einige mögliche Richtlinien, um die Schmerzen des Benutzers zu lindern:

  • Zwinge mich nur, mich anzumelden, wenn du es unbedingt brauchst, und gib mir die Chance, mich zu entscheiden, es nicht zu tun!

  • Machen Sie es zu einem Seitenformular, damit ich weiß, was ich vorhabe und natürlich nicht so viele Eingabefelder wie möglich verwende. Im Idealfall nur E-Mail und Passwort (möglicherweise zweimal), kein Benutzername!

  • Zeigen Sie Ihr Anmeldeformular als kleines Fenster oben auf Ihrer Seite an, ohne es neu zu laden, und erlauben Sie mir, es mit einem einzigen Klick weg von diesem Fenster loszuwerden.Zwinge mich nicht dazu, nach dem "Schließen" -Button zu suchen, oder, noch schlimmer, Icon, das ich für etwas anderes verwirren könnte!

  • Konto für Benutzer, um vor / zurück zu klicken und Schaltflächen neu zu laden. Löschen Sie das Formular beim erneuten Laden nicht! Setzen Sie keinen klaren Knopf überhaupt! Es ist zu einfach, versehentlich zu klicken. Die Daten, die Sie von mir verlangen, sollten nicht so lange auf dem ersten Platz liegen, dass ich sie nicht erneut eingeben kann, ohne dass Sie "Hilfe" benötigen, um sie zu löschen.

Nun zu Frage Q2. Hier haben wir ein bekanntes Problem der Konfliktlösung, das immer dann auftritt, wenn zwei Daten zusammengeführt werden müssen. Zum Beispiel die anonymen Daten und die registrierten Benutzerdaten, aber auch immer dann, wenn zwei Benutzer die gleichen Daten modifizieren oder derselbe Benutzer sie von verschiedenen Geräten zu unterschiedlichen Zeiten modifiziert oder lokal gespeicherte Daten mit Serverdaten kollidieren, und so weiter.

Aber was auch immer die Quelle ist, das Problem ist immer das gleiche. Wir haben zwei Daten, sagen wir zwei Objekte $ obj1 und $ obj2 und Sie müssen Ihr einzelnes verschmolzenes Objekt $ obj3 erzeugen. Die Logik kann so einfach sein wie die Regel, dass das Objekt des Servers immer gewinnt oder dass das zuletzt geänderte Objekt immer gewinnt oder dass die zuletzt geänderten Objektschlüssel immer gewinnen oder eine kompliziertere Logik. Dies hängt wirklich von der Art Ihrer Anwendung ab. Aber in jedem Fall müssen Sie nur Ihre Logikfunktion mit den Argumenten $ obj1, $ obj2, die $ obj3 zurückgeben.

schreiben

Eine Lösung, die möglicherweise in vielen Fällen funktioniert, besteht darin, den Zeitstempel für jedes Objektattribut (Schlüssel) zu speichern und den zuletzt geänderten Schlüssel zum Zeitpunkt der Synchronisierung zu gewinnen. Dies erklärt z.B. für die Situation, wenn derselbe Benutzer verschiedene Attribute ändert, wenn er von verschiedenen Geräten anonym ist.

Stellen Sie sich vor, ich hätte gestern die Tasten A und B am Gerät AA geändert, dann heute vom Gerät BB eingeloggt, um ein anderes B einzugeben und auf dem Server gespeichert, dann zu meinem Gerät AA zurückgekehrt, wo ich anonym bin, um noch ein anderes zu betreten A ohne das alte B von gestern zu ändern, und dann realisiert, dass ich mich einloggen und synchronisieren möchte. Dann ist mein lokales B offensichtlich alt und sollte den Wert von B, den ich kürzlich auf Gerät BB geändert habe, eindeutig nicht überschreiben. In diesem scheinbar komplizierten Fall funktionieren die obigen Lösungen nahtlos und effektiv. Im Gegensatz dazu wäre es falsch, den Zeitstempel nur auf ganze Objekte zu setzen.

Nun könnte es in einigen Fällen sinnvoll sein, beide Objekte zu behalten, und z. unterscheiden Sie sie, indem Sie zusätzliche Eigenschaften hinzufügen, wie im Fall 1, der in Radeks Frage vorgeschlagen wurde. Zum Beispiel fügt Dropbox etwas wie "Konfliktkopie durch Benutzer X" am Ende der Datei hinzu. Wie im Dropbox-Fall ist dies bei Collaboration-Apps sinnvoll, bei denen Benutzer eine Versionskontrolle bevorzugen. In diesen Fällen speichern Sie jedoch als Entwickler einfach zwei Kopien und lassen die Benutzer mit diesem Problem umgehen.

Wenn Sie auf der anderen Seite eine komplizierte Logik schreiben müssen, die auf Benutzerdaten basiert, können zwei verschiedene Kopien, die herumhängen, ein Albtraum sein. In diesem Fall würde ich Daten in zwei Gruppen aufteilen (z. B. zwei Objekte aus einem erstellen). Die erste Gruppe enthält Daten, die den Zustand der Anwendung als Ganzes darstellen, was wichtig ist, um einzigartig zu sein. Für diese Daten würde ich die Konfliktlösung wie oben oder ähnlich verwenden. Dann ist die zweite Gruppe benutzerspezifisch, wo ich beide Daten als zwei separate Einträge in der Datenbank speichern, sie richtig markieren (wie Dropbox) und dann die Benutzer mit der Liste von zwei (oder mehr) Einträgen ihres Projekts befassen kann .

Wenn schließlich diese zusätzliche Komplizierung der Datenbankverwaltung den Entwickler beunruhigt, und da Radek gebeten hat, eine Ressourcenreferenz zu geben, möchte ich "zwei Fliegen mit einem Schuss töten", indem ich den Blog-Eintrag StackMob offline Sync , dessen Lösung sowohl Datenbank- als auch Benutzerverwaltungsfunktionalität bietet und so den Entwickler von diesen Problemen befreit. Sicherlich gibt es eine Menge mehr Informationen, die bei der Suche nach Datenkonkurrenz, Konfliktlösung und ähnlichem gefunden werden können.

Abschließend muss ich den obligatorischen Disclaimer hinzufügen, dass alle hier geschriebenen nur meine eigenen Gedanken und Vorschläge sind, die jeder auf eigene Gefahr verwenden sollte und mich nicht verantwortlich machen, wenn Sie plötzlich zu viele glückliche Nutzer haben, die Ihre machen Systemabsturz:)

Da ich selbst an einer App arbeite, bei der ich alle diese Aspekte umsetze, bin ich natürlich sehr daran interessiert, andere Meinungen zu hören und was sonst noch zu diesem Thema zu sagen ist.

    
Dmitri Zaitsev 26.08.2013, 11:44
quelle
7

Aus meiner Erfahrung - sowohl als Benutzer von Websites, die eine Anmeldung erfordern, als auch als Entwickler, der mit angemeldeten Benutzern arbeitet - glaube ich nicht, dass ich jemals gesehen habe, dass eine Website sich so verhält.

Das übliche Muster besteht darin, einen Benutzer anonym zu halten, und wenn er das erste Mal etwas tut, das den Status speichern müsste, werden sie aufgefordert, sich anzumelden. Dann wird die vorherige Aktion gespeichert und der Benutzer kann fortfahren. Wenn sie beispielsweise versuchen, ihrem Warenkorb etwas hinzuzufügen, werden sie aufgefordert, sich anzumelden, und nach der Anmeldung befindet sich der Artikel in ihrem Warenkorb.

Ich nehme an, einige Orte würden es Ihnen erlauben, einen Einkaufswagen zu füllen und sich dann einzuloggen, an welchem ​​Punkt der Einkaufswagen einem konkreten Benutzer zugeordnet ist.

Ich würde ein SessionUser-Objekt erstellen, das den Status der Site-Interaktion hat, und ein Feld namens UserId, mit dem andere Dinge wie Name, Adresse usw. abgerufen werden können.

Bei anonymen Benutzern würde ich das SessionUser-Objekt mit einer leeren Referenz für UserId erstellen. Dies bedeutet, dass wir einen Namen oder eine Adresse nicht auflösen können, aber wir können trotzdem den Status speichern. Die Aktionen, die sie ausführen, die angezeigten Seiten usw.

Nach der Anmeldung müssen wir nicht zwei Objekte zusammenführen, wir füllen nur das UserId-Feld in SessionUser und jetzt können wir ein Objektdiagramm durchlaufen, um Namen, E-Mail, Adresse oder was auch immer zu erhalten.

    
ryan1234 22.08.2013 16:17
quelle