この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Identity & Paywall Transformation
2019年11月19日（火）にNagatacho GRiDでAuth0社の自社イベント「Auth0 Day 2019」が開催されました。
本記事は、セッション「Identity & Paywall Transformation」をレポートします。なんと！海外からのスペシャルゲストです。
スピーカー
Andreas Martin [News Corp Australia Head of Online & Subscription Delivery]
セッション概要
The journey for News Corp Australia to transform their identity and paywall capabilities from legacy platforms requiring heavy engineering to configurable platforms, enabling the business roadmap.
レポート
Presentation Overview
- どのようにレガシーなpyラットフォームから移行を行ってきたか
- ビジネスのアドバンテージも大きくなってきた
- 以下の数字についてお話しする
- 3.6m
- 500,000
- 6,738
WHO
- News Corp Aurstalia
- オーストラリア最大規模のニュースメディア
- US, UK色々なところで行っている
- オーストラリアは群を抜いて最大
- このメディアを使って、様々なアクションを起こしている
- 出版、放送など様々行っているが、出版にフォーカスする
- 40のブランドがある
- Custumer Technorogy
- コアのサブスクリプションおyラットフォ０ーむをビジネスに提供
- Eコマース、CRM、セルフサービス、マーケティングプラットフォームを提供
- 究極的な目的はCXの向上
- Facebook, Google, Twitterなど、これらを使っていて慣れている
- マッチするExを提供しなければユーザーは離れてしまう
- マッチしなければ買ってくれなくなる
- 戦略の一部、Configuration可能なプラットフォーム
- レガシーは自分たちで構築してきた、それらは素晴らしい
- しかし、過去数年の間に止めなければいけなくなった
- そうでなければ、新しいアイデアが出てくるたびに作り直しになってしまう
- 製品リーダーとパートナーシップを持つというのも大きな仕事
- サービスは買ってくればいい、これ以上のIDプラットフォームを作れるとは思わない
- だからこそAuth0を使う
- フォーカスを当てるのはコアなビジネス
- アクティブなロードマップを増やしていく
- そこに投資も注力していく
- 我々のビジネスにEnablerを提供するか
WHY
- なぜ旅路を始めたのか？
- 以前のソリューション
- 7年くらい経っていた
- デジタルサブスクサービスを始めた時から使っていた
- Identity & Paywall
- メディアがよく使っているもの
- Paywall : 有料コンテンツのこと
- 記事を読んでいくと、Subscriberでなければ先を読むことができない
- 認証に紐づいている
- 有料会員であれば記事を読むことができる
- IDとPaywallは一緒に構築することになる
- 常に調和
- 世界で事業でやっているため、グローバル戦略として徹底してやる必要がある
- そのほうが効率が良いし、競争力も上がる
- グローバル1社としてまとめる
- レガシーなプラットフォームではかなりの作業量が必要だった
- そこからできるだけ脱却したかった
- 設定作業だけで済ませたかった
- OIDCなど、できるだけグローバルスタンダードにしたかった
- メディアならではの要件
- 社員にとってもやりやすくしたい
- 会社のIDと連携できるものを探していた
- 社員も会社のクレデンシャルでアクセスできるようにしたかった
- 当時、比較的新しい考え方だった
- 結構ニーズに高い要件
- アーキテクチャをシンプルにしたかった
- すぐに複雑になる
- 詳細な調整が難しいものに陥りがち
- グレーエリアを残さず、クリアなハンドオーバーで提供する
- 明確なオーナーシップの線引きができるようなものを目指す
- アウトボックスで実装したい
- すぐにカスタマイズしたくなるが、行わない
- SSOでアクセスできるようにしたかった
- 非常に難しい
- 例えばSafariでCookieで制限されるなど
- 自動的にログイン、サイトAでログインしていたらサイトBで自動ログインしたい
- チャレンジングで、課題はまだ全て解決していない
HOW
- 重要な決断としてやるべきこと : マイグレーション
- 数百万規模で乗っかっていた
- lazy migration or bulk migration
- lazy : 新しい方で試すが、ダメだったら古い方でやる
- できるだけシームレスにできるように目指した
- 全てはカスタマーのために
- 結果的によかった
- パスワード自体もマイグレーションできた
- あとでbulk migrationで補強
- あまりログインしていない人向けに
- クライアントサイドの認証
- セッションが格納されている
- やった理由
- 迅速なものが欲しい（止まって欲しくない）
- SSOを可能にしていく
- しかし、ハイブリットという形になる
- サーバーサイドの実装も必要
- パフォーマンスが重要
- サイトを毎日測定している
- パフォーマンスにインパクトがないことを確認
- lazy migration
- 大きなイベントが起こるとトラフィックが増える、これを予測することは大変
- 何かが起こったら対応できるように
- スケーラブルなアーキテクチャが必要になる
- 速報が入った時も対応できるように
- 統計
- 移行は大手術
- 12のアプリケーションがあった、かなりの大きさ
- 6,738のテストケースを行った
- 12ヶ月かかったが、意図的にゆっくりにしている
- 大きな速報が入ってくる場合があるから慎重にやった
- 十分な長さだと思っている
- 6ヶ月経過しているが、古いIDプラットフォームを使っていなかったから機能しないが無いことを確認した
- 15時間かかったが、ほとんどうまくいった
- 多くのコードを移行しなければいけない
- 夜の間に移行した
- 100人以上が20チーム以上が関わった
- 一人ずつコツコツと構築していった
- 最初、50万人のカスタマーがアクセス
- 本当に大きなアクティブユーザー
- 60万人、70万人のアクティブなユーザーのうち50万人がはじめにアクセス
- ほとんどパーフェクトなCXを提供できている
- まだ我々の理想通りに入っていない
- 実際の移行
- 一番重要なのはニュースをお届けすること
- 短い中断はあったものの、迅速にデプロイできた
- 他のニュースを見てしまうということは何としても避けたい
WHAT HAPPEND
- 明らかにビジネスアドバンテージを達成できた
- 設定可能なプラットフォームができた
- 色々な意味でよくなった
- 要望がたくさん来ていて大変なことになったが、これがやりたかったこと
- 聞いてもどうせ意味ないだろう、と思われていたことが無くなった、たくさんのリクエストが届く
- パーソナライゼーションにも力が入れられるようになった
- AI、機械学習の企業とパートナーシップを結んだ
- 匿名の人たちにはCookie ID、ログイン済みの人はAuth0のID
- 加入してくれるスコアを出せるようになった
- スコアが低い場合はもう少し読ませるなど調整
- ヘビーユーザーの場合はすぐに加入を勧める
- カスタマーの行動パターンによって、リアルタイムに振る舞いを変えている
- B2Bの契約
- 5社と契約している
- 社員にとってのメリットがある
- 我々が目指していた戦略に推移できた
- 以前のプロダクトの価値は変わらず
- 学び
- 想定通りに全てが進んだわけではない
- 変化に対する度合いを見くびってはいけない
- 社内外で大きな変更を強いることになる、予想より大きな変化だった
- できるだけシームレスにしたい
- ログインスクリーンは前から少し変わったりした
- 長く使っていない人はパスワードを覚えていないとか
- ステークホルダとの交渉
- 彼らが最初から含まれているか
- 最初からオンボーディングしてもらう
- パフォーマンステスト
- 十分に時間を取る
- レポーティング、ロギング
- 最終的なところで時間内に終わらせたい
- トラブルシュートやKPIに苦労した
- 7ヶ月経過したが、370万のユーザーがAuth0にマイグレーションしている
- プロダクトは非常に安定している
- インシデントは2回しか起きなかった
- アクティブにチューニングなどをしている、士気も高まってきている
- 残っているチャレンジもある
- セッションマネジメント
- Apple IdP（SIWA）
- それらが片付いてもまだある
- 今の所順調に進んでいる
- SafariとChromeで違うコードになっているが、一本のコードにしたい
- アウトボックスのソリューションを使う選択をした、しかしビジネスユーザーにとっては制約を生じる
- ビジネス側は柔軟性が欲しいと言う
- アウトボックス仕様を止めるわけには行かない
- クレデンシャルスタフィンガーアタックに対応する必要がある
- ハッカーからデータを守らなければいけない
- 過去になりすましが起きたことがある
- 攻撃に対して保護をしていく必要がある
- より一層の保護をEnableしていく必要がある
- Auth0の中で既知のユーザー、パスワードを保護する必要がある
Q&A
Q : 移行の段階でユーザーに対してリトルフリクションで済んだとあったが、普段とは違うような画面遷移やフローをやってもらったり、ユーザーにお願いをしたりとか、そのような違う体験をさせたことがあるか？また、それをやるために事前に告知しているか？
A : 色々検討し、準備した、オプションを考えた。プロアクティブでユーザーにお知らせすることはしなかった。メールを書くのも大変。フィッシングのメールなどの心配などさせてしまうので、全てのログインスクリーンを置き換えましたと伝えた、コールセンターにもブリーフィングをし、準備をした。ダイレクトなコミュニケーションはしなかった。お客様がそこに居た時は表示されるが、全員へのアナウンスはしなかった。
Q : コールセンターにどのくらい問い合わせがあったか？
A : 6,000コールほど。我々の予測より10倍入ってきた。パスワードを忘れた場合のリンクを知らずに電話が入ってきた。全体で見ると1%で済んだと言うこと。年齢層が高めで電話の方が簡単と思う人。年配の方のユーザーベースだった。
Q : Lazy Migrationについて、その場合ログインしていないユーザーはAuth0に移行されないが、残りのユーザーはどうしたか？
A : 指摘通り、Lazy Migrationはログインのタイミングのみ。ログインしなければマイグレーションされない。2, 3ヶ月間猶予を持たせたところ95%くらいあった。残りのユーザーはBulk Migrationを行なった。そのユーザーはパスワードなし、つまりリセット。ほとんどのユーザーが済んだ中でやったので、ほとんどインパクトがない形で実現できた。
Q : 問題を対処するためのハッキングアタックの話があったが、問題のために何かを使ったのか？
A : Brute Force Protectionは使っていたが乗り越える場合もある。既知のユーザー名があったので早めにストップすると言うのも行なった（Bot Protection）。これはログインの前に入れている。
A : Auth0の中ではMLを入れていて、過去にログイン/ログアウトが通らなかったもののデータから判断するような機能を作っている。Botかどうかが判定し、Botと判定されたらCaptureを出すようになる。
A : AkamaiをCDAを使っていて、Bot Protectionをかけている。Auth0のビルトインのソリューションが欲しかったのでサポートする予定とのことで嬉しい。
まとめ
グローバルでも最も大きな移行事例ではないでしょうか。その方法は非常に参考になる内容でした。マイグレーションがネックで移行を躊躇している場合はぜひ参考にしてみてください。
2
