【ITニュース解説】My short link click-stats API taught me that 'last click time' is a lie you tell yourself

短縮URLは、長いウェブサイトのアドレスを短くする便利なサービスだ。特に、文字数制限があるSNSなどでよく利用されている。この短縮URLがどれくらいクリックされたかを測定し、その統計情報を提供するAPI（アプリケーション・プログラミング・インターフェース。プログラム同士が情報をやり取りするための窓口のようなもの）を構築する話から始まる。

筆者はまず、各短縮URLについて「総クリック数」「過去30日間のクリック数」「最後にクリックされた日時」という三つの情報を取得できるAPIを設計した。実装は非常にシンプルで、短縮URLがクリックされて本来のURLへリダイレクトされるたびに、クリック数を記録するカウンターを増やし、その情報をプログラム内のデータ構造（例えばマップと呼ばれる、名前と値のペアでデータを管理するもの）に保存していた。これにより、データの可視化画面（ダッシュボード）には、短縮URLごとのクリック統計がきちんと表示されるようになった。

しかし、このシンプルな設計では、後に重要な問題に直面することになる。このシステムを利用するエージェント（担当者）から、「私の持っている多数のリンクのうち、どれがもうほとんど使われていないのか（活動が停止しているのか、つまり『死んでいるのか』）を教えてほしい」という質問があった。しかし、筆者の作ったAPIは、この質問に答えることができなかったのだ。なぜなら、「総クリック数」と「最終クリック日時」だけでは、それぞれのリンクが「今、どれくらい活発に使われているか」という、より詳しい活動状況を正確に判断できなかったからである。

この状況を具体的に見てみよう。例えば、ある二つの短縮URLがどちらも総クリック数900回を記録しているとする。筆者のAPIの出力だけでは、両方のリンクが同じ「900クリック」として表示されるため、区別がつかない。しかし、もし一方のリンクの900クリックが、全て数カ月前に集中して発生し、それ以降は全くクリックされていないとしたら、そのリンクは「死んでいる」と判断できるだろう。一方で、もう一方のリンクの900クリックが、過去半年間にわたって均等に分散して発生しているとしたら、そのリンクは「今も活発に使われている」と言える。このように、総クリック数が同じであっても、クリックされた「時期」や「頻度」が全く違うのに、最初のAPIではそれらを区別する情報がなかった。これが「最終クリック日時」が単独では不十分である、という筆者の指摘の核心部分だ。単一の最終クリック日時だけでは、過去の活動がどうだったか、現在の活動状況はどうなのかという、時間軸に沿った詳しい情報は全く読み取れないのだ。

この問題を解決するための方法は、決して高度な技術を必要とするものではなかった。筆者は、各短縮URLに対して「過去30日間の日ごとのクリック数」を保存する仕組みを追加した。これは「リングバッファ」と呼ばれるような、限られた期間のデータを効率的に管理する方法に近い。特別な時系列データベースのような複雑なシステムや、Prometheusのような専門的な監視ツール、あるいは大規模なインフラストラクチャを導入したわけではない。非常にシンプルに、各リンクにつき整数（クリック数）の配列を用意し、現在の「日」のインデックスを計算する簡単な数式（現在時刻を日数に変換し、30で割った余りを使うことで、0から29までのインデックスとして循環的に使う）を用いて、日ごとのクリック数をその日の配列要素に記録するようにしたのだ。データの読み出し時に古いデータを新しい日で上書きするような仕組みを導入し、常に最新の30日間の日ごとのクリックデータが保持されるようにした。

この変更によって、APIは「日ごとのクリック数」の配列を返せるようになった。これにより、エージェントは自分たちで「クリックの勢い（速度）」「トレンド（傾向）」「衰退具合」など、本当に知りたかった情報を計算できるようになったのだ。例えば、「最近1週間でクリック数が急増しているか」「徐々にクリック数が減ってきているか」といった具体的な状況を把握できるようになり、どのリンクが「死んでいる」のか、あるいは「生きている」のかを正確に判断できるようになった。

この経験から得られた教訓は、システム開発において非常に重要だ。「集計カウンター」、つまり「合計でどれくらいか」という情報だけでは、「いつ、どのように」という時間的な質問には答えられないということだ。もし、誰かのためにデータ分析ツールを構築するのであれば、彼らは必ず「これはまだ機能しているか？」「最近のパフォーマンスはどうなっているか？」といった、「変化の割合」に関する質問をするだろう。これらの質問は、表面上は「合計」を尋ねているように見えても、実態は「変化の速さや傾向」を知りたい質問なのだ。

したがって、データを保存する際には、後からでもその「変化の割合」を計算できるように設計しておくべきである。単に「最終クリック日時」という一つのタイムスタンプだけを保存しても、その目的は達成できない。時間の経過とともにデータがどのように変化したかを把握できるような情報を保持することが、本当に役立つ分析機能を提供する上で不可欠なのだ。システムエンジニアを目指す上で、ユーザーが何を本当に知りたいのか、そのためにどのようなデータを、どのような形式で保存すべきかを深く考える重要性をこの事例は教えてくれている。