【ITニュース解説】Your dev.to analytics as JSON, and the number in it that lies

ソフトウェア開発者にとって、自分が作成した記事やコンテンツがどれくらい読まれているか、どのような反響があるかを知ることは非常に重要である。ウェブサイトのダッシュボードで提供される情報は、手動で確認するには便利だが、もしそのデータを自動的に取得し、自分独自の分析ツールやレポート作成に活用したいと考えた場合、プログラムから直接データにアクセスする必要が出てくる。これは、システム開発の現場で、様々なシステムからデータを連携したり、自動でレポートを生成したりする際に頻繁に用いられる技術の一つだ。

dev.toのような開発者向けプラットフォームでは、自分の記事のアクセス解析（アナリティクス）情報をウェブブラウザ上で確認できるが、これをプログラムから利用可能なJSON形式で取得する方法がある。JSONはJavaScript Object Notationの略で、人間にとっても機械にとっても読み書きしやすいデータ形式であり、ウェブAPIを通じてデータをやり取りする際の標準的な形式として広く利用されている。

具体的にdev.toのアナリティクスデータを取得するには、curlというコマンドラインツールと特定のアドレス（エンドポイントと呼ばれる）を利用する。エンドポイントとは、APIが提供する機能にアクセスするためのURLのことだ。今回のケースでは、https://dev.to/api/analytics/dashboardというエンドポイントが使用される。このコマンドを実行する際には、ログイン情報が必要となるため、ウェブサイトにサインインした際に取得されるクッキー（セッション情報）をcookies.txtのようなファイルに保存し、curlコマンドに渡す必要がある。これは、APIキーを使って認証する一般的な方法とは異なり、現在ログイン中のユーザーとしての権限でデータにアクセスしていることを意味する。もし特定の一記事のアナリティクスデータだけが欲しい場合は、その記事のIDをURLのパラメータとして追加する。記事IDを指定しない場合は、自分のアカウント全体のデータが取得される仕組みだ。

このエンドポイントから取得できるJSONデータには、大きく分けて「日ごとの履歴データ」「合計データ」「参照元データ」が含まれている。例えば、日ごとのデータを見ると、特定の日付に対して「ページビュー数」「平均読了時間（秒）」「合計読了時間（秒）」といった情報が格納されている。これは、自分の記事が日々どのように読まれているかを詳細に追跡するための貴重な情報となる。

しかし、ここで得られる数字には注意が必要な点がいくつかある。システムエンジニアとしてデータを扱う上で最も大切なことの一つは、数字を鵜呑みにせず、その数字がどのように算出されているかを理解することだ。このdev.toのアナリティクスデータには、特に初心者が誤解しやすい「落とし穴」が存在する。

一つ目は、「読了時間はサインインしている読者のみをカウントする」という点だ。例えば、ある日に記事が10回表示されたにもかかわらず、読了時間がゼロ秒と表示されたとする。一般的な感覚では、「10人の読者がすぐに記事を閉じてしまった（直帰した）」と解釈してしまいがちだ。しかし、このアナリティクスの仕組みでは、それは「サインインしている読者が一人もいなかった」という意味になる。記事を開いたもののサインインしていなかった読者の読了時間は計測されないため、もしあなたの記事の読者のほとんどがサインインしていない場合、実際の読了時間はもっと長くても、データ上はゼロと表示されてしまう。これは、記事の内容に問題があったのか、それとも単に読者の層が異なっていたのか、といった分析を行う上で非常に重要な区別である。

二つ目は、合計ブロックの数字、特に「合計読了時間」が「嘘をつく」という点だ。このアナリティクスデータが提供する合計読了時間は、実際の日ごとの読了時間を全て足し合わせたものではなく、「平均読了時間 × 総ビュー数」という計算で導き出されていることが多い。例えば、実際には計測された読了時間の合計が150秒だったとしても、システムが報告する合計は900秒といった大きく異なる数字になる可能性がある。これは、データが表示を良く見せるために、算術的に単純な乗算を行っているためだ。もしあなたが信頼性の高い、公開の場で提示できるような正確な合計読了時間が必要な場合は、日ごとのデータを一つずつ自分で足し合わせて計算し直す必要がある。システムが提供する「合計」という数字をそのまま信用すると、誤った分析をしてしまう恐れがあるため、注意深くその算出方法を確認することが肝心だ。

三つ目は、「ビューは遅れて、不定期に到達する」という点だ。記事を公開した直後の24時間で数字を確認し、その時点で分析を終了してしまうと、後から追加されるビューを見逃し、不正確な結果を得ることになる可能性がある。例えば、公開初日はほとんどビューがなかったのに、数日後に突然ビューが増えるといった現象は珍しくない。これは、検索エンジンのインデックス登録やSNSでの拡散が遅れて発生したり、特定の曜日や時間帯に読者がアクセスしたりする影響によるものだ。したがって、記事のパフォーマンスを正確に評価するには、ある程度の期間を置いてからデータを収集し、分析する必要がある。

これらの「落とし穴」を回避し、正確なデータを取得して分析するためには、提供される生データを自分で加工する能力が求められる。記事で紹介されているスクリプトの例では、curlコマンドでJSONデータを取得した後、jqとawkという強力なコマンドラインツールを組み合わせて利用している。jqはJSONデータを処理するためのツールで、取得したJSONの中から必要な情報（日付、日ごとのビュー数、日ごとの合計読了時間）を効率的に抽出できる。その後、awkを使って、抽出された日ごとのデータを基に、自分で正確な総ビュー数と合計読了時間を計算しているのだ。

このスクリプトによって算出された合計読了時間については、「サインインしている読者のみ」という注釈を必ず添えるべきだと述べられている。これは、先述したように、この数字が全ての読者の活動を反映しているわけではないという事実を明確にするためであり、データに対する誠実な姿勢を示す上で非常に重要だ。

システムエンジニアとして、データを扱う際には、表面的な数字だけでなく、その数字の背後にある意味、算出方法、そして潜在的な制約を深く理解することが不可欠だ。今回のdev.toのアナリティクスデータの例は、一見するとシンプルな数字に見えるものでも、その内実を深く掘り下げてみれば、多くの「嘘」や「誤解」が含まれていることを教えてくれる。このような経験を通して、データの真価を見抜き、信頼できる情報に基づいて意思決定を行うスキルを磨いていくことが、これからのキャリアにおいて非常に役立つだろう。