ログイン機能なしでプロダクトをローンチすべき理由
(casparwre.de)- ログイン実装を後回しにすることで
→ 開発速度が上がり、コードの複雑さが減る
→ ユーザーのオンボーディング時の負担が減る
→ ハッキング攻撃の対象範囲が減る
→ 潜在的なSEO上の利点もある
-
筆者が成功させた2つのWebプロダクトにはログインがなかった
-
現在取り組んでいるプロダクトは1日5万ビュー / 月間$2Kの収益があるが、ローンチから4年経ってようやくログインを追加した
→ 開発速度が上がり、コードの複雑さが減る
→ ユーザーのオンボーディング時の負担が減る
→ ハッキング攻撃の対象範囲が減る
→ 潜在的なSEO上の利点もある
筆者が成功させた2つのWebプロダクトにはログインがなかった
現在取り組んでいるプロダクトは1日5万ビュー / 月間$2Kの収益があるが、ローンチから4年経ってようやくログインを追加した
13件のコメント
おお……ログインなしで unique な link を通じてユーザーを識別する方式は、まったく想像もしていませんでしたが、斬新ですね。
今回のサイドプロジェクトはログインなしで実装してみようと思います(笑)
私たちは個人情報処理の負担のため、最初に一次リリースの対象から外した機能が会員登録/ログインでした。機能実装の負担もありますが、まず運用や個人情報を処理する人員がいないため負担に感じていました。ログイン後に提供できる機能や利便性が多く悩みましたが、結局外して一次リリースを進めています。
そうですね、すばらしい選択だと思います。作っている製品も、機会があればぜひ Show GN で紹介してください! 笑
潜在的なSEOの利点を含む -> この部分は誤字のようです
あっ、はい、急いで修正しておきました ;)
うちの会社の製品は最初はログインなしで始めてうまく成長したのですが、後になってログインが必要な方向へ製品が進化したときに、ログインへ誘導しようとすると大変でしたね。製品によって選べるオプションではあるように思います。
はい、後からログインへの導線を自然に促すのがスキルなのだと思います。こういうものは事例の共有がもっと増えるとよさそうですね。
ログイン機能も、OAuth2を含めてある種テンプレート化できるのではないかと思うのですが、よく分かりません。
OAuth2程度だけでも、ユーザーのオンボーディング負担はかなり減るのではないかという気はします。
ハッキングの攻撃範囲の縮小というのは、個々人の情報を保持していないため、そもそもハッキングする対象がない、という程度に理解すればよいのでしょうか?
原文に「Evil-doers are much less likely to break into your house if there is nothing of value inside」とあるので、持ち去るものが何もないから安全だ、という意味で合っていますね。
ありがとうございます。原文までは確認できていませんでしたが、これではっきりしました。
ええ、おそらくサーバーに何かを送ったり、パスワード保存のような処理が発生するので、その部分を言っていたのだと思います。
私も最近は Passport.js のようなものがかなりやってくれるので、開発面では大きな負担ではない気がします。
でも ID があるとサービス企画の要素がかなり入ってくるんですよね。ID がなくても機能を試せるようにするほうが、初期ユーザーのトラクションを作るにはずっと良さそうです。個人的には、新しく作られたサイトで OAuth でログインすること自体にも抵抗があります。 ^^;
なるほど、そう言われてみると OAuth も私の個人情報をばらまく行為ではありますね。私はもともとあまり気にしないタイプなので…;;;
これは作る製品によって違うと思いますが..
必ずしもログインまで必要ないサービスであれば、その機能を外して素早く開発してローンチしたあとで追加するのが正しいと思います。韓国のサービスは、不要な個人情報をあれこれ取りすぎな気がします。
ひとつだけ付け加えると.. 記事ではメールアドレスも保存するなと言っていますが、機能のお知らせやニュースレター配信のために、メールアドレスくらいは任意で受け取るのがよい気がします