こんにちは。QuarkAの丸山です。 前回はウェブサイト分析ソフトウェアの敵が「インフラコスト」であること、それが故、無料ヒートマップツールの実現が困難であったため、WordPressを利用したQA Heatmap Analyticsプラグイン開発に至ったという経緯をお伝えしました。 本日は、そのWordPressに手を出してから味わってきた開発の苦労話をいくつかお伝えしたいと思います。大きく3つあります。 WordPress固有の苦労 パフォーマンスと精度のチューニングの苦労 データ容量削減の苦労 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（ウェブのパーツ）単位で把握することが可能になりました。 3.データ容量削減の苦労 … Continue reading ウェブサイト分析ソフトウェア開発の舞台裏（後編）