Webメディアの課題は、「記事を読んでもらうこと」だけではない
複数のWebメディアを運営している企業では、サイトごとに読者が分かれ、ユーザーとの継続的な接点を作りにくいという課題があります。
検索やSNSから記事へ訪問してもらえても、
* 誰が読んでいるのか分からない
* 一度訪れた読者との関係が続かない
* 複数メディアを横断して読者行動を把握できない
* ユーザー属性に合わせた情報配信が難しい
* 新しい記事を公開しても再訪を促しにくい
といった問題が残ります。
こうした課題に対して、単純にWebサイトをアプリ化するだけでは十分ではありません。
必要なのは、
複数メディアの記事を一つの読者体験へ統合し、Webとアプリの会員情報を安全に連携しながら、興味に合う情報を継続的に届ける仕組み
です。
Sekimosoft合同会社では、複数Webメディアを運営する事業を題材に、iOS・Android向けのメディアビューワーアプリ、会員ID連携、外部顧客管理システムとの接続、検索、プッシュ通知、パーソナライズまでを一体として考えるシステム設計を行いました。
> 本事例について
>
> 本記事は、Sekimosoft合同会社が複数Webメディアとモバイルアプリ、会員基盤、外部顧客管理システムの連携を題材に行った、自社開発検討・システム設計事例です。
>
> 特定の顧客企業から受託したプロジェクトではありません。
>
> 実際の導入時には、既存メディアの構成、記事管理方法、会員基盤、外部システム、取得する属性情報、セキュリティ要件などを確認した上で個別に設計します。
Webメディアでは、記事ごとに多くのアクセスを集められる場合があります。
しかし、Webからの集客は、
* 検索順位
* SNSの拡散
* 外部プラットフォーム
* 広告
などの影響を受けます。
アクセス数が多くても、読者との継続的な関係を作れているとは限りません。
さらに、複数のメディアを運営している場合、
* メディアAでは生活情報を読む
* メディアBでは話題の記事を読む
* 別のサイトでは会員登録している
といったように、同じ読者の行動が分散します。
運営側から見ると、
複数のサイトはあるが、読者との関係はつながっていない
状態です。
そこで今回の設計では、
Webメディアを単純に一つへ統合するのではなく、
複数メディアの記事を横断して閲覧できる共通アプリ
を中心に考えました。
メディアアプリを作る際に起こりやすいのが、Webサイトをそのままアプリ内に表示するだけの構成です。
この方法は短期間で実現しやすい一方で、アプリとしての価値を作りにくくなります。
今回の設計では、アプリの役割を次のように考えます。
複数メディアの記事を一つの場所で読める
ユーザーは、メディアごとにサイトを移動する必要がありません。
興味に合う記事を見つけやすい
検索、絞り込み、関連記事などを共通の仕組みで提供します。
読んだ記事を残せる
会員はお気に入りや閲覧履歴を利用できます。
新しい記事を届けられる
プッシュ通知によって、継続的な接点を作れます。
ユーザーごとに表示を調整できる
登録属性や閲覧傾向をもとに、表示内容を変えられます。
つまり、アプリは単なる記事表示画面ではありません。
複数メディアと読者を継続的につなぐ接点
として設計します。
今回のような構成では、複数のWebメディアに大量の記事があります。
想定する記事数が1万件規模になると、
「各サイトのページをそのまま読み込む」
だけでは、検索、関連記事、パーソナライズを共通化しにくくなります。
そこで、記事情報を共通形式で扱う層を設けます。
想定する流れは次の通りです。
複数のWebメディア
↓
記事情報を取得
↓
共通形式へ変換
↓
検索用インデックスへ登録
↓
アプリへ配信
共通化する情報には、
* 記事ID
* メディア名
* タイトル
* 概要
* 本文または参照先
* カテゴリ
* タグ
* 公開日時
* サムネイル
* 関連テーマ
などがあります。
これにより、
どのメディアの記事であっても、同じ検索・絞り込み・関連記事機能を利用できる
ようになります。
今回の設計では、すべての記事閲覧に会員登録を必須とはしません。
アプリを初めて使う人に、最初から多くの情報入力を求めると、離脱につながります。
そのため、
未登録ユーザー
* 記事閲覧
* 検索
* カテゴリ閲覧
* 関連記事閲覧
を利用できます。
会員ユーザー
さらに、
* お気に入り
* 閲覧履歴
* 属性設定
* パーソナライズ
* 通知設定
* 複数端末での情報共有
を利用できます。
この設計では、
読むために登録させるのではなく、便利さを感じた人が会員になる
流れを作ります。
Webとアプリで別々の会員登録を求めると、ユーザーにも運営側にも負担が増えます。
そこで、
Webとアプリで同じIDを利用できる構成
を基本とします。
想定する構成は、
Webメディア
↓
共通認証基盤
↑
モバイルアプリ
です。
Webで登録したユーザーは、同じIDでアプリへログインできます。
反対に、アプリで登録したユーザーも、Web側で同じ会員として扱えます。
これにより、
* アカウント重複
* パスワード管理の複雑化
* 会員情報の分散
を減らします。
会員や属性情報を管理する際、すべてを独自開発する必要はありません。
特に、
* 認証
* 会員情報
* 属性情報
を扱う場合は、セキュリティと継続運用を考慮する必要があります。
今回の設計では、外部の顧客管理システムや会員基盤を利用し、アプリとはAPIで連携する構成を想定します。
アプリ
↓
認証・連携API
↓
外部顧客管理システム
重要なのは、
アプリ側へ必要以上の属性情報を複製しないこと
です。
たとえば、アプリが記事表示に必要なのが、
* 年代区分
* 興味カテゴリ
* 家族構成区分
であれば、それ以上の情報をアプリ側へ持たせる必要はありません。
情報を持つ場所を明確にし、
* 認証情報
* 会員属性
* 閲覧履歴
* コンテンツ情報
を役割ごとに分けます。
パーソナライズには、大きく二つの情報があります。
登録属性
ユーザー自身が登録する情報です。
たとえば、
* 年代
* 興味分野
* 家族構成
* 関心テーマ
などです。
行動データ
サービス利用中に生まれる情報です。
たとえば、
* 何を読んだか
* どの記事をお気に入りにしたか
* どのカテゴリを多く見ているか
* どの通知を開いたか
などです。
これらを同じものとして扱うのではなく、
登録属性 × 閲覧行動 × 記事属性
として考えます。
たとえば、
「子育てに関心がある」と登録したユーザーに、関連テーマの記事を表示する。
さらに、そのユーザーが旅行記事を多く読んでいれば、旅行関連の記事も増やす。
このように段階的に調整します。
最初から高度なAIレコメンドを作る必要はありません。
まずは、
* カテゴリ
* タグ
* 登録属性
* 閲覧履歴
を使ったルールベースから始める方法が現実的です。
記事数が増えるほど、一覧表示だけでは目的の記事を見つけにくくなります。
そのため、
* キーワード検索
* カテゴリ
* メディア
* 公開時期
* 人気
* 関心テーマ
などで絞り込めるようにします。
検索で重要なのは、記事数ではありません。
ユーザーが目的の情報へ到達できること
です。
また、検索結果から得られる情報も重要です。
よく検索される言葉。
検索されているのに記事が少ないテーマ。
検索後に読まれている記事。
こうしたデータは、今後のコンテンツ企画にも活用できます。
アプリでは、プッシュ通知によってユーザーへ直接情報を届けられます。
しかし、通知が多すぎると利用停止につながります。
そのため、
* 全体向け
* メディア別
* テーマ別
* 属性別
* 行動傾向別
などに分けて配信します。
たとえば、
* 新着記事
* 特集
* お気に入りテーマ
* 関連記事
などです。
重要なのは、
送信数ではなく、アプリへ戻る理由を作ること
です。
通知では、
* 配信数
* 開封率
* 記事閲覧
* 継続利用
を確認します。
運営側では、
* 記事
* 広告
* 通知
* ユーザー分析
を扱います。
しかし、すべてを一つの画面に詰め込む必要はありません。
コンテンツ管理
* 取得済み記事
* メディア
* カテゴリ
* タグ
* 公開状況
配信管理
* プッシュ通知
* 対象ユーザー
* 配信日時
* 配信結果
広告管理
* 掲載枠
* 表示期間
* 対象カテゴリ
分析
* 記事閲覧
* 人気テーマ
* 会員化
* 継続利用
と役割を分けます。
パーソナライズを行う場合でも、多くの個人情報を集めれば良いわけではありません。
重要なのは、
サービス改善に必要な情報だけを取得すること
です。
たとえば、
「年齢そのもの」
が必要なのか。
それとも、
「年代区分」
で十分なのか。
「家族全員の詳細情報」
が必要なのか。
それとも、
「家族構成の区分」
で十分なのか。
取得項目ごとに、
* 何に使うのか
* 本当に必要か
* どこに保存するか
* 誰が利用できるか
* いつまで保持するか
を整理します。
会員情報を扱うサービスでは、アプリ単体の対策だけでは十分ではありません。
考える範囲は、
* モバイルアプリ
* API
* 認証
* 外部顧客管理
* 管理画面
* ログ
* データ出力
まで含まれます。
たとえば、
アプリ
必要以上の情報を端末へ保存しない。
API
認証・権限確認を行う。
管理画面
運営担当者ごとに権限を分ける。
CSV出力
誰でも自由に出力できる状態にしない。
ログ
個人情報を必要以上に記録しない。
このように、
サービス全体で情報の流れを設計すること
が重要です。
機能候補が多いアプリでは、すべてを一度に作るとリリースが遅れます。
そのため、最初のフェーズでは、
読者に使ってもらい、継続利用されるかを確認できる範囲
に絞ります。
想定するPhase 1は、
* 複数メディアの記事統合
* 記事一覧
* 記事詳細
* 検索・絞り込み
* 会員登録・ログイン連携
* お気に入り
* 閲覧履歴
* 基本的な属性別表示
* プッシュ通知
です。
一方、
* 高度なAIレコメンド
* 複雑な広告最適化
* 詳細な顧客分析
* 大規模な自動配信
などは、Phase 1の利用状況を確認してから検討します。
iOSとAndroidの両方へ提供する場合、開発方式を検討する必要があります。
重要なのは、
* 必要な機能
* 端末固有機能の利用
* 開発体制
* リリース時期
* 保守コスト
です。
要件によっては、
* クロスプラットフォームで同時開発
* iOSから先行
* 共通APIを先に構築
などの方法があります。
技術方式を先に決めるのではなく、
Phase 1を最短で検証できる方法
を選びます。
アプリをリリースすると、ダウンロード数が注目されます。
しかし、本当に見るべきなのは、
* 初回起動後に記事を読んだか
* 再訪したか
* 会員登録したか
* お気に入りを使ったか
* 通知から戻ってきたか
* 複数メディアの記事を横断して読んだか
です。
想定する改善指標には、
* インストール後の初回閲覧率
* 未登録から会員への転換率
* 7日・30日継続率
* 1人あたり閲覧記事数
* プッシュ通知からの再訪率
* お気に入り利用率
などがあります。
重要なのは、
アプリを作ったかではなく、読者との関係が深くなったか
です。
今回のメディアビューワーアプリは、次の流れで構成します。
複数のWebメディア
↓
記事情報を共通形式へ統合
↓
検索・配信用データを生成
↓
iOS・Androidアプリで閲覧
↓
必要に応じて会員登録
↓
共通認証基盤と連携
↓
外部顧客管理システムで属性管理
↓
お気に入り・閲覧履歴を蓄積
↓
ユーザーに合う記事を表示
↓
プッシュ通知で再訪を促進
↓
利用状況を分析
↓
コンテンツ・配信を改善
重要なのは、
アプリだけを作らないこと
です。
コンテンツ。
会員ID。
属性情報。
閲覧行動。
通知。
分析。
これらを一つのサービスとして設計します。
複数のWebメディアを運営すること自体には、大きな価値があります。
異なるテーマ。
異なる読者。
異なるコンテンツ。
しかし、それぞれが完全に分かれていると、読者との関係も分断されます。
アプリによって目指すのは、
すべてのメディアを同じものにすることではありません。
それぞれのメディアの価値を残しながら、読者との接点を一つにつなぐこと
です。
Sekimosoft合同会社は、アプリをリリースすること自体を最終目的にはしていません。
iOS。
Android。
プッシュ通知。
会員登録。
外部顧客管理。
これらはすべて手段です。
重要なのは、
Webから訪れた読者と、継続的な関係を作れるか
です。
そのために、
複数メディアをつなぐ。
記事を探しやすくする。
登録を強制しない。
会員には便利な機能を提供する。
必要な情報だけを安全に管理する。
利用状況を見ながら改善する。
その一連の体験を設計します。
メディアアプリ・会員基盤・外部顧客管理連携についてご相談ください
次のような課題がある場合は、ご相談ください。
* 複数のWebメディアを一つのアプリへまとめたい
* Webとアプリで会員IDを共通化したい
* 外部の顧客管理システムと連携したい
* 大量の記事を検索・絞り込みできるようにしたい
* お気に入りや閲覧履歴を提供したい
* 属性に合わせて記事を届けたい
* プッシュ通知で継続的な接点を作りたい
* 個人情報を扱うため、セキュリティを含めて設計したい
* まずPhase 1を小さくリリースして反応を確認したい
最初からすべての仕様を決める必要はありません。
誰に、どの情報を、どの接点で届けたいのか。
まずは、そこから整理します。
Sekimosoft合同会社は、要件整理、UI・UX設計、システム設計、アプリ開発、外部システム連携、セキュリティ設計、リリース後の改善までを一気通貫で支援します。
