Warum man ein Produkt ohne Login-Funktion launchen sollte
(casparwre.de)- Indem man die Implementierung des Logins aufschiebt,
→ beschleunigt man die Entwicklung und verringert die Code-Komplexität
→ reduziert man die Hürde beim Nutzer-Onboarding
→ verkleinert man die Angriffsfläche für Hacking-Angriffe
→ ergeben sich potenzielle SEO-Vorteile
-
Die zwei Web-Produkte des Autors, die erfolgreich waren, hatten keinen Login
-
Das Produkt, an dem er derzeit arbeitet, erreicht 50.000 Views pro Tag / 2.000 $ Umsatz pro Monat, bekam aber erst 4 Jahre nach dem Launch einen Login
13 Kommentare
Wow … auf die Idee, Nutzer ohne Login über einen eindeutigen Link zu identifizieren, wäre ich nie gekommen — echt originell.
Mein nächstes Side-Projekt sollte ich wohl auch mal ohne Login umsetzen, haha.
Wegen des Aufwands für die Verarbeitung personenbezogener Daten war die erste Funktion, die wir in der ersten Runde ausgeschlossen haben, die Registrierung/der Login. Neben dem Aufwand für die Implementierung der Funktion war es vor allem belastend, dass uns schlicht das Personal für den Betrieb und die Verarbeitung personenbezogener Daten fehlt. Wir haben zwar lange überlegt, weil es viele Funktionen und Komfortmerkmale gibt, die man nach dem Login anbieten kann, aber am Ende haben wir es weggelassen und fahren in der ersten Phase ohne weiter.
Ja, ich denke, das ist eine ausgezeichnete Entscheidung. Wenn sich die Gelegenheit ergibt, stellen Sie Ihr Produkt auch bei Show GN vor! :)
Enthält vermutlich SEO-Vorteile -> Hier scheint ein Tippfehler zu sein
Ups, ja, ich habe es schnell korrigiert ;)
Unser Firmenprodukt ist anfangs ohne Login gestartet und ist damit gut gewachsen, aber als sich das Produkt später so weiterentwickelte, dass ein Login nötig wurde, war es schwierig, die Nutzer dazu zu bewegen. Je nach Produkt scheint das eine Option zu sein, die man wählen kann.
Ja, es scheint darauf anzukommen, Nutzer später auf sanfte Weise zum Login zu bewegen. Es wäre gut, wenn mehr solche Beispiele geteilt würden.
Ich bin mir nicht sicher, aber ich frage mich, ob sich selbst eine Login-Funktion einschließlich OAuth2 nicht in gewissem Maße als Template standardisieren ließe.
Ich denke, schon allein mit OAuth2 könnte die Hürde beim User-Onboarding deutlich sinken.
Kann man die Verringerung der Angriffsfläche für Hacker so verstehen, dass es gar nichts zu hacken gibt, weil von vornherein keine personenbezogenen Informationen enthalten sind?
Da es im Original heißt: "Evil-doers are much less likely to break into your house if there is nothing of value inside", ist die Bedeutung wohl tatsächlich, dass man sicher ist, weil es nichts zu stehlen gibt.
Danke. Ich hatte mir den Originaltext zwar nicht angesehen, aber jetzt ist es klarer.
Ja, vermutlich war damit gemeint, dass dabei Dinge wie das Senden von etwas an den Server oder das Speichern von Passwörtern nötig werden.
Für mich wirkt die Entwicklungsseite auch nicht wie eine große Belastung, weil heutzutage vieles von Dingen wie Passport.js übernommen wird.
Aber sobald es eine ID gibt, fließt eben auch viel Service-Planung mit ein. Es wirkt daher viel besser für die anfängliche User-Traction, wenn man Funktionen auch ohne ID ausprobieren kann. Ich persönlich zögere sogar schon, mich auf neu erstellten Websites überhaupt per OAuth anzumelden. ^^;
Wenn ich mir das so anhöre, ist auch OAuth letztlich eine Handlung, bei der meine personenbezogenen Daten verstreut werden. Ich bin da ohnehin ziemlich entspannt ...;;;
Das hängt zwar vom jeweiligen Produkt ab, aber …
Wenn es sich um einen Service handelt, der nicht unbedingt einen Login braucht, halte ich es für richtig, diese Funktion zunächst wegzulassen, schnell zu entwickeln, zu launchen und sie später hinzuzufügen. Bei Diensten hierzulande werden, wie ich finde, oft unnötig viele andere personenbezogene Daten abgefragt.
Noch ein Punkt: Im Artikel heißt es zwar, man solle nicht einmal E-Mail-Adressen speichern, aber ich finde, für Funktionsbenachrichtigungen oder den Versand eines Newsletters sollte man zumindest optional eine E-Mail-Adresse abfragen.