Twitter は人通りの多い地上階にあるガラス張りのお店って感じ。 はてなブログは半地下にあるお店の感じ。 入ろうと思った人しか入ってこない。
Twitter の投稿数よりはてなブログの投稿数のほうが多い理由がわかったような。 自分には Twitter は向いていないっぽい。
マーケティングファネルを整える
マーケティングファネルのステージ
- Top of the funnel (ToFu) – Awareness: 新たな見込み客を引き付ける
- Middle of the funnel (MoFu) – Consideration: リードの獲得と育成
- Bottom of the funnel (BoFu) – Conversion: リードを顧客に変える
ToFU のメトリクスを取る
前出の記事によると、ToFU: Top of the Funnel のメトリクスは次の通り：
GA4 で対応するメトリクス
この記事がとてもわかり易い：
- Session: セッション数
- Bounce rate: エンゲージメント率 （>= 30%）
- Time on Site: 平均エンゲージメント時間
「SPA の認証に JWT を使うな」な意見をまとめる
有名なやつ
まあ僕自身のケースで言うと、 OpenID Connect 経由で得られる ID Token (JWT) はログインのためだけに使い、伝統的なセッション管理を引き続き使いますよ、もしくは ID Token にセッション ID を含みますよ、で要件を満たせてしまいます (実際には OpenID Connect の Session Management における拡張仕様のどれかにも載っからないと各サービス間でのログアウト状態の整合性が取れないので頑張りが必要ですが)。
Twitter で拾ったもの
第三者サービスへの認可の委譲は OAuth 2 の一時的なアクセストークンで行うべきだし，自社サービスの認証は今まで通り Cookie でやるのが最善。後者にリフレッシュトークン持ち出してくるのは本当にセンスがない。
— 刺身食べたい (@mpyw) 2020年3月11日
第三者サービスへの認可の委譲は OAuth 2 の一時的なアクセストークンで行うべきだし，自社サービスの認証は今まで通り Cookie でやるのが最善。後者にリフレッシュトークン持ち出してくるのは本当にセンスがない。
Qiita
セッション管理ではなくOAuth認証などに使うのは問題ない。一回認証したら終わりなので、有効期限を短くしておけば済む。「一人のために全員ログアウト」のような不便は発生しない。
StackOverflow
@user3601262 I would say that regardless of it's (prolific) popularity as an approach, it is not a best practice to give access tokens to a SPA frontend which ultimately will store those tokens in browser storage (which is not secure). The recommended approach is to introduce a middleware service (usually a BFF) that uses sessions and acts as an OAuth2 Client for stateless backend services. This also hides the backend architecture from the frontend, which is another good practice.
DeepL で翻訳
@user3601262 アプローチとしての（多くの）人気にかかわらず、SPAフロントエンドにアクセストークンを与えるのはベストプラクティスではない。推奨されるアプローチは、セッションを使用し、ステートレスバックエンドサービスのOAuth2クライアントとして動作するミドルウェアサービス（通常はBFF）を導入することです。これはまた、フロントエンドからバックエンドアーキテクチャを隠すことにもなり、これも良いプラクティスです。
実装するならこんな感じか：
quit quit ~ ♪
- 2023.01.31
- 2023.02.29
