#linedevday なぜLINEではウェブトラッキングシステムがフロントエンド開発チームによって構築されたのかにいってきたまとめ！【LINE DEVELOPER DAY 2017】

今年もLINE Developer Day 2017に行ってきました！！

本記事はウェブトラッキングシステムをフロントエンドがどのように開発して活用しているかを語る「なぜLINEではウェブトラッキングシステムがフロントエンド開発チームによって構築されたのか」のまとめになります！

なぜLINEではウェブトラッキングシステムがフロントエンド開発チームによって構築されたのか

川崎康平様

LINEのフロントエンドウェブ開発について

• LINEは幅広いコンテンツをwebブラウザ、アプリから使えるようになっている
• 近年ではサーバーアプリケーションとクライアントとの開発が疎結合で開発できるようになった
• ラインではフロントエンドを専任するチームは各国に拠点がある
  • なぜなら通信速度、法律、文化は違うので、エンドユーザに最も近いアウトプット、ノウハウに合わせて国をまたいで共有することで専門性を高めている

NewsTabについて

• 2017年/3月時点で、5900万のユーザが使用している
  • 改善を早いサイクルで回すためにwebview上で使っている
• webviewで構築する場合webアプリケーションで構築してしまうと、オフラインで使用しているときや、ネットワークが切断されたときに一切画面を表示できなくなる。
  • LINEのネイティブクライアントがサーバに対してHTMLをリクエストしてクライアント上でキャッシュするようにしている
• クライアントはチャンネルサーバから認証トークンを通知、取得するが、カスタムイベントとして発火され、JS SDKやapp.jsが用いている
  • トークンを用いてニュースサーバにAPIをリクエストして取得している
• 画面が表示された後にユーザのアクションをトリガーをもとにクライアントに通知を起こしたいときは、js sdkを通して行う
  • どのイベントのコールバックかを判定するためにcall back idが振られている
  • callback idを元にwebview側では、イベントごとに処理できるようにされている
    • こうすることでダミーイベント発生させてテストしやすくなっている
• webviewからクライアントに通知する場合は、lineNative.postMessageというものを用いてイベント発火を行う
  • 未定義のイベントのエラーハンドリングも行いやすくなっている
• Fluxを採用してstorageにjsonにして保存することでデータ受信を待たずとして表示することができる
• 数百記事のコンテンツを一つのviewportで行うようにしている
  • collectionviewとよばれるjsonコンポーネントを開発した
  • 画面内に表示するどのコンポーネントを表示するかを制御することでユーザに対して迅速に表示が行える

coupon bookについて

• 公式アカウントから受け取ったクーポンをタップするとクーポンを表示するという機能のbugfixについて
• gps情報を取得して周囲の利用できるクーポンを一覧できるという機能を開いたら、404ページが表示されてしまった
  • シンガポールでアクセスされた場合のみ発生するエラーだった

JSのエラーログトラッキング

• 世界中に存在する端末で全てのテストケースをクリアするのは現実的ではない
  • 問題が起きたときにどう知るかが問題
• JSのエラーログを収集する機能を作った
  • 重要視したのはスケーラビリティ
  • 薄いレイヤーのツールとなっているが、サーバ側はログの受け口としていて、スケールしやすくなっている
• 収集したログはダッシュボードにして見やすくしている
  • シンガポールで起きた問題は他の国で起きているかを調査する際に、このツールで国別にみることで察知できるようにしている

ウェブトラッキングサービスについて

• エラーが発生した祭、1億人の10万件なのか、1000万人の10万件なのかわからないとインパクトが把握できない
• エラーログ収集を通じて、rawデータとして保管して社内で解析できるようにするのを重要視した
  • 機械学習など他のチームと連携してより大きなデータ解析に臨んだ
  • 10億/日のイベントログが発生している
• 収集しているイベントログは、pageview / customevent / scroll / pageloadの4つのイベント
• ユーザの定義について、はlineとweb上のデータが直接結びついていると、データの取扱に大きな制限がかかってしまうので、それを疎結合にするためにすべてcookieベースにしている
• イベントカテゴリとしては、type/body/timeとわけることで、他の情報を追加しやすくしている
• elasticsearchでは3TB/dayのデータを処理している
• 1日のイベントログを時系列で可視化したところ、ニュース系のコンテンツがとても多い
  • 秒間で3万5千を超えるリクエストがきたこともあった

データの収集と活用

• データの活用には収集蓄積活用の3段階があるが、web tracking systemでは収集蓄積を常に行っているため、いつでも活用できる

LINE analytics

• 企画者などが簡単に分析できるツールを作成した
• web面だけでなく、native clientからでも収集した情報を閲覧できるようになっている

Mochigome(error reporting)

• エラーイベントの収集でキバナを使っていたが、どういったデータがはいっているかを理解しないと効果的に活用できない、ダッシュボードの調整がしづらいという問題があった
• elasticsearchのダッシュボードとして特化したものを作った
  • エラーイベントの内容をコードのどの部分に該当するかを表示したり、notifyに通知したりしていた
• mochigomeはインターンによる作成が大きく貢献してもらった

なぜweb tracking systemに取り組み続けているか

• DBのデータをただ表示したり、入力データをただ投げるだけだと思われるが、ユーザの手元で発生している課題を把握することで、質の高いものを得られる
• どんなイベントが発生するかを熟知しているのは開発者たち
• レコメンドデータを活用することで新しいサービスを作り出せる
• 各国の拠点やサービスをまたいで集約することで横断的にサービスに活かせる
• ユーザの見えないものを取得して次に活かし、よりよいサービスを作成していきます

@mogmetの所感

webviewとJSをがっつり使用していて、その内部で起こったエラーについてもきちんとすべて収集している点に驚きました。

エラーを減らしていくことで質の高いサービスを作っていくことができるんだなと感じました。