ウェブサイト分析ソフトウェア開発の舞台裏(後編)

ホーム » 開発者ブログ » ウェブサイト分析ソフトウェア開発の舞台裏(後編)

Koji Maruyama
Koji Maruyama

ウェブサイト分析ソフトウェア開発の舞台裏(後編)

こんにちは。QuarkAの丸山です。

前回はウェブサイト分析ソフトウェアの敵が「インフラコスト」であること、それが故、無料ヒートマップツールの実現が困難であったため、WordPressを利用したQA Heatmap Analyticsプラグイン開発に至ったという経緯をお伝えしました。

本日は、そのWordPressに手を出してから味わってきた開発の苦労話をいくつかお伝えしたいと思います。大きく3つあります。

  1. WordPress固有の苦労
  2. パフォーマンスと精度のチューニングの苦労
  3. データ容量削減の苦労

1.WordPress固有の問題

WordPressのライセンス

QA Heatmap Analyticsは、今のGPL公式版リリースの前にQA Heatmap β版を出していました。
その時に何人かの人から「野良アプリ感www」「ライセンスどうなってるの?」と指摘(バカに?)されたのですよね(汗)

確かに、β版ということもあってライセンスやWordPressのお作法やルールへの意識は甘いところがあってリリースしていました。それにβ版はもちろん自社サイトだけで配布していたので、まさに野良アプリといえばその通りでした。

たとえば、WordPressのプラグインには下記のようなライセンス規約があります。

WordPressでは、結構ライセンス違反をしているテーマやプラグインも多い(この場合、公式WordPress.orgサイトには掲載できません)ので、そういう指摘が入ったようです。

現在は100%GPLの公式版です

もちろん現在のQA Heatmap AnalyticsはWordPressコミュニティの審査の上、公式WordPress.orgに登録されています。つまり100%GPLの無料プラグインになります。

どんなサイトでも無限に自由に使ってもらうことが可能です。世界中の人に使ってもらいたいので、多言語化にもチャレンジしていきます。

WordPress標準関数の洗礼

WordPressでは、そのままPHPの関数を使うことが推奨されていないケースが多々あります。特にOSに近い命令に関しては、ラップする関数が用意されていることが多いです。セキュリティ問題もありますので。

ところがQAのようなウェブサイト分析ソフトウェアの肝はインフラですから、当然OS周りの処理が多くなりますし、シビアな処理も多くなります。WordPressはオープンソースですから、多くの人が開発に関わっていますし、そもそもそんなシビアな想定はされていないこともあり、特にファイルシステム周りでの処理では大変苦労しました。

そういう時はGoogle検索を頼りますが、まず日本語では情報が少ないです。あと英語だとしても、WordPressくらいメジャーだと今度は記事が多すぎて間違っている情報も多くひっかかり、混乱もします。

最終的には、WordPress本体のソースコード(Developersサイト経由)を見るしかないのですが、今度はソースコードを見て愕然とし、方針を転換したこともあります。

ということで、ワードプレスのプラグインを開発してみたいという方は、こういった本体のソースコードを見るとか、どこまでお作法で許されるのかとか、検索方法などのコツがあると思っています。

苦労した分、いつかこのあたりのナレッジをシェアする機会も作りたいなと思っています。

2. パフォーマンスと精度のチューニングの苦労


どこまでの精度でデータを取得し保存するか?

録画をイメージしてもらうとわかりますが、データ取得精度を細かくするほど、綺麗な動画できあがります。しかし、そうするとデータ容量がとても大きくなります。

WordPressというのは、一般的に安価なレンタルサーバーで稼働していることが多いです。しかし、そのような安価なサーバーでも月間30万PV近いアクセスを誇るブロガーさんもいます。

このような中で、QA Heatmap Analyticsのデータを取得するためにサイトが重くなっては本末転倒です。

いかにリアルタイムのデータ取得負荷を軽くし、かつ保存するデータ容量を削減するか。それでいて視覚化した時に正確性を損なわない精度で取得するか?というチューニングには苦労しました。

最終的には、クライアント・サーバー間の通信においては精度を損なわないようにクライアント側で0.3秒間隔でデータを保存しながらサーバーとの通信はAjaxで3秒間隔で行うようにしています。かつサーバー側の同時接続数が増えても重くならないようにデータ保存処理はDBを使わずファイルシステムで行っています。

その上でデータの集計作業については、夜間cron(正確にはwp-cron)を使ってバッチ処理的にDBにデータを集計しながらストックしています。

レンタルサーバー向けに低負荷で稼働させる苦労

各レンタルサーバーは負荷の高いプロセスを自動的にkillするという仕様のところもたくさんあるため、今度はcronのデータ集計処理中にプロセスが異常終了するということが発生します。これに対応するために、状態を保存しながら細切れにデータ集計処理を進めるという、case文を用いたトリッキーなプログラミングスタイルをとっています。

このインフラ制限がある中での処理は、私の父親が工作機器の制御系プログラマであり、私にもその経験があったこと、およびCTC(伊藤忠テクノソリューションズ)のインフラエンジニアであった経験が大きく役立っています。特に制御系のプログラミングは人命がかかっているなど、シビアさではウェブよりはるかにきついので参考になる箇所が多いです。

またレンタルサーバーの検証は、うちの会社がウェブコンサルティング会社であることが役立ちましました。自社サイトでもそれなりにアクセス数のあるサイトを複数所有しており、またいくつかのメジャーなレンタルサーバーと契約しているため(AWS含む)、たくさんの環境でどうなるか事前に把握することができたのです。

さらにβ版を先にリリースしたことで、サーバー環境依存する問題を事前にだいぶ改善することができました。これも大きなポイントだったと思います。

疑似アイトラッキングの難しさ

ヒートマップは、「ユーザーが見ているところ」を指し示しているように見えます。しかし、実際にはユーザーのアイトラッキング(視線を追う)ことをしているわけではないため、あくまでブラウザで取得できるデータから、ユーザーの注視箇所を推測する必要があります。

一般的に簡易で作成されたヒートマップツールというのは、ユーザーの行動をブラウザサイズと座標で取得するのですが、実際にはブラウザサイズは各ユーザーで違うため、本当に注視しているところを示すことができず、とてもアバウトな分析になってしまいます。(例えばレスポンシブでブラウザ幅によってレイアウトが変わる場合、座標でそれを把握するのは困難です。)

我々はマーケティングコンサルタントでもあるので、「ユーザーの注目箇所」を間違えると、判断を間違えてしまうということを重要視していました。たとえば「上級者はこちら」と「初級者はこちら」というテキストリンクが並んでいた場合、どっちがより注目されているかの判断を間違えるわけにはいきません。

そこで、QA Heatmap AnalyticsではDOMオブジェクトを取得した上で、「どの部分を見ているのか?」を再描画するようにしています。そうすることにより、より正しく注視されている箇所をDOM(ウェブのパーツ)単位で把握することが可能になりました。

QA Heatmap Analyticsは可能な範囲で正確な位置に描画します。

3.データ容量削減の苦労


サーバー環境がユーザー依存する中で、特に厳しいのはデータベース容量とファイル数の上限の問題です。

ヒートマップツールはそのデータ量の多さが精度のポイントですが、当然保存する容量が大きくなるとレンタルサーバー(特に共用サーバー型)では問題なため、制限をかけているレンタルサーバー会社がほとんどで、かつDBの上限は1GBなど小さいことが多いです。

そこでデータを圧縮するなどの方法が考えられますが、下手に圧縮した場合、今度は展開に時間がかかるようになり、データを閲覧する時にサーバーに負荷がかかってしまうので注意が必要です。また圧縮ではなく情報を欠落させてしまった場合は、将来のデータ分析に影響がある可能性があります。

上記のような事情を加味し、QA Heatmap Analyticsではかなり将来展開を見越した上で、データ容量の削減に効く部分に関してオリジナル方式でデータを圧縮し、展開に関してもパフォーマンスに影響がある部分は一時的なキャッシュファイルを用いるなどで高速化と容量の削減の両方を実現しています。

標準プラグインでは保存数を1ページにする

QA Heatmap Analyticsは、世界中の人に使ってもらいたいと思っていますので、さらに変わったサーバー環境のユーザーがいるかも知れませんし、アクセス数が凄まじいサイトもあると思います(英語圏になるので)。

ICTに詳しくない人も多いはずで、その全世界中の人達に、データ容量のことを気にしながら運用してもらうことは不可能だと思っています。そう考えると、最初からある程度のクォータ制限をかけた方が安心です。

そこで公式サイトからダウンロードできるプラグインでは、ヒートマップデータの保存数を1ページのみに限定しています。お友達紹介をしてもらった方で最大3ページ取得できるようにしました。また標準のデータ保存期間を2ヶ月間にしています。

この方式により、下記を実現できました。

一方で、有料プランを契約する人は、ウェブサイトについての本腰をいれているプロが多いだろうという想定をし、マニュアルやヘルプも読んでもらえる前提にたちました。
そこでマニュアルに注意事項などを記載した上で、ページ数の取得制限をとり払うことにしました。また有料プランではサーバーのことがよくわからない方向けに導入サポート(サポートチーム直通の問い合わせフォーム)もつけるようにしました。

これで、各ユーザーの状況にあわせたヒートマップツールを提供できたと思っています。

ページビューは全アクセスを保存する

余談ですが、実はプラグインをインストールした時点で、無料・有料関わらず全てのページビューは記録しています。2つの理由があります。まずページビューだけであればそれほどデータ容量を食わないので、ある程度の期間のデータ保存が可能なこと。もう一つはQA Heatmap Analyticsは、ヒートマップではなく、アナリティクス。つまり本質的には行動分析ツールだからです。

前編にも書きましたが、QA Heatmap Analyticsはイベントとページビューの両方を計測しています。従来GAと新GA4が合体したイメージに近いかも知れません。

このことにより、世界初のツールを開発している我々らしく、面白い進化をお見せできると思いますので、これからのバージョンアップにぜひご期待ください。

まとめ


今回は、前編、後編に渡って、サイト分析ソフトウェア開発の舞台裏についてお話してきました。

我々は、今までのPV計測型のアクセス解析の時代が終わりを告げようとしていて、これからは新しいサイト分析の時代が訪れようとしていると考えています。

その中で、最終的にQuarkAは自立分散型行動分析プラットフォームを目指していて、その意味は、だんだんとお見せできると思っています。

しかし何より、苦労はしましたが、誰でも手軽にインストールして使えるのがWordPressのプラグインの良さで、その中で頑張って作っていることにやりがいも感じます。

日本から世界へ羽ばたき大成功したソフトウェアって「スーパーマリオブラザーズ」などのゲームだと思っており、マニュアルなど読んでもらわなくても世界中の人がプレイできたその偉業をとても尊敬しています。

我々もそれに倣い、QuarkAとはに記載しているように「すべての人にデータに基づくインスピレーションを」を合い言葉に、誰にでもデータ分析を楽しんでもらえるようなソフトウェア開発を続けていきたいと思っています。