投稿者: 丸山耕二/QuarkA・ウェブジョブズ

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

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

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

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

1.WordPress固有の問題

WordPressのライセンス

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

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

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

【クオッカでもわかる】ワードプレスのGPLライセンス。有料テーマ、自作プラグイン販売時の考え方

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

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

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

QA Analytics – with Heatmaps & Replay, Privacy Friendly

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

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.データ容量削減の苦労

---

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

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

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

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

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

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

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

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

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

• 誰でもデータ容量を気にせずヒートマップを活用してもらえる
• 手軽に計測ページを変更できるので1ページずつ集中してサイトを改善してもらえる（自然とそういう運用になる）
• A/Bテストなどを実施している人でも3ページあれば事足りる

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

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

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

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

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

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

まとめ

---

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

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

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

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

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

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

ウェブサイト分析ソフトウェア開発の舞台裏（前編）

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

QA Heatmap Analyticsは、もうすぐVer.0.9の録画再生機能がリリースされる予定です。
最近Google Analytics 4もリリースされたこともあるので、このあたりで「データ分析ソフトウェア開発の舞台裏」について書いてみたいと思います。

ウェブサイト分析はイベント計測型へ

---

もともとGoogle アナリティクスはUrchinというアクセス解析ソフトウェアを2005年にGoogleが買収したところから始まりました。もう15年も前の話です。

それから現在に至るまで、スマートフォンの登場などもあってやユーザー行動自体は大きく変化していますが、計測の仕組み自体はずっと当時の原則を守ったままでした。

しかしここに来て、Googleアナリティクス 4が登場しました。今までとの大きな違いはデバイスまたぎの計測（アプリ含む）に対応できるなどですが、従来のウェブサイト分析という範囲において大きな変化の一つは「ページへのアクセスではなく、イベントを計測するようになった」になったということです。

Google Analytics 4のイベントって何？

イベントについて耳慣れない方もいるかも知れません。より正確に表現するならば「イベントとは、ブラウザ上で取得もしくは設定できる何らかのアクション」ですが、これでは何のことやら？です。

ウェブサイト分析で使うイベントについて、おおよそのイメージでいえば「イベント＝ユーザーの行動」と捉えていいと思います。

たとえば、ページを閲覧しただけでなく、ページをスクロールした、動画を再生したといったユーザーの行動を指します。実際、Google Analytics 4ではページのスクロール情報なども取得してくれるようです。

スマートフォン時代に入り、ユーザーの行動は、以前ほどシンプルではなくなってきています。その中で、イベントを計測するようになったというのは理にかなっていると思います。

イベント計測は簡単ではない

これだけ見ると、Google Analytics 4は大幅に進化したように思えますが、今まで使っている側からすると手放しでは喜べないところもあります。ご紹介する衣袋さんや森野さんや村山さんのツイートのように、わかりづらくなってしまった部分や、できないこともあるからです。

機械学習でよく出てくるこの話（ゲームアプリみたい場合に、ユーザーがそろそろ解約するよ見たいな予測）は、殆どのサイトでは関係ないからねえ。あと、機械学習が得意なのは、分類なので、「この人は買いそうみたいな」やつ。そんなのさ、今でもある程度可能じゃんね。カートに入れて買わない人とか https://t.co/Lb8BGKFf3p

— 衣袋宏美（イブりん） (@hibukuro) October 21, 2020

あ、さっきの上手く上がってなかった。GA4の画面から別サービスのタグが配信できるようになる感じです。今のところは設定できるけど機能していないようです。

何ともややこしい。 pic.twitter.com/FmEsRsoICM

— 森野誠之 (@uneidou) October 21, 2020

ga.js から analytics.js の移行時もイベントヒットとかのデータ移行に関する話があったけど、結局は何もなかったから今回の analytics.js から GA4 の移行も何も信じられない。おそらく自身で計測実装対応するしか解決策はないはず。そこでイベントパラメータの制限にぶつかるわけですね、わかります

— ムラヤマ　ユウスケ (@muraweb_net) October 21, 2020

なので、今すぐ安易に飛びつかない方がいいというのは私自身も完全同意です。そもそも多くの中小規模サイトにとっては不要の機能だったり、以前からのWeb+Appプロパティを導入した人はわかると思うのですけど、少なくとも現状は決して使いやすいとはいえないからです。

ただ、先ほど申し上げた通りイベント計測型という点においては、これからのウェブを見渡せば理にかなっていると考えています。なぜなら、ユーザーの行動＝イベントであり、ブラウザ上の行動分析の行き着く先は「イベント」の分析であるからです。

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

データ分析の最大の敵は「インフラコスト」

---

さて、Google Analytics 4はイベント計測型に進化したわけですが、それならば、なぜわかりづらい部分や、使い勝手がわるい部分が出てしまったのでしょうか。

この件については、a2iの大内さんのコラムがとても参考になるのではないかと思っています。

【コラム】Googleアナリティクスの新バージョンの隠れた目的

要はどうにかして インフラコストを下げたい っていうことですよね。だからこそ、旧来のデータをそのまま引き継ぐわけにはいかなかったと。

大量のデータ処理はお金がかかる

今はAIの時代などいろいろ言われますけど、最終的にそれらは全て「データ処理」です。精度をあげようと思えば、良質な推測と設計のもと、大量のデータを保存し、そのデータを演算する必要があります。

これはディスク容量、メモリ、CPU（AIならGPU）パワーを大量に食いますから、いわゆる高スペックのゲーミングPCをたくさん買うようなもので、とてもお金がかかります。

これを無料で提供するというのは、そもそも一般の零細企業には不可能ですが、あのGoogleでさえも、厳しくなってきます。おそらくGoogle Analyticsは、世界の数億程度のサイトに入っていると想定しており、現状でもとてつもないデータ容量のはずです。

▼Google Analyticsはサイト分析ツールとして圧倒的なシェアを誇っており、世界中のサイトの54.8%に導入されています。

https://w3techs.com/technologies/overview/traffic_analysis

そんな全サイトで、今までのデータに加え、さらにその数十倍となるであろう全てのユーザーの行動データを詳細に長期間記録するというのは、さすがのGoogleといえどもちょっときついはずです。

そもそも、なぜGoogleアナリティクスは無料で提供されているのか？

もともとはUrchinを買収して提供が始まったGoogleアナリティクスですが、一石二鳥ではないですけど、下記のような狙いだったと思っています。

• Google側のメリット
  • 世界中のサイトの傾向を把握、分析できる
  • 世界中のサイトを通じて全世界のユーザーを把握（追跡）できる
• ユーザー側のメリット
  • アクセス解析ツールで傾向がわかれば改善点がわかる
  • 世界の傾向を分析したGoogleから良質な情報をもらえる

その目的は既に達成されたわけで、それにしては現状が高コスト体質という状態なのだと思います。

加えて、これからはiOSが採用しているITPなどプライバシーの問題が出てきますので、今のGoogle アナリティクスだけでは限界も出てきます。

ですからGoogle Analytics 4は現状のデータ構造を引き継がず、新しく設計されたというわけです。

ヒートマップもまた「膨大なイベントデータ」が必要

---

さて、ここでQA Heatmap Analyticsも採用しているヒートマップ関連の話になります。

ウェブ分析をしている人、特にLP改善などを行う人であれば、ヒートマップが強力なツールであることは疑いようがないと思います。

もしかしたら「なぜGoogleは無料のヒートマップツールを出さないのだろう？」と思っていた人もいるかも知れませんが、それは先ほどの理由と照らし合わせるとわかってきます。

ヒートマップというのは、ユーザーのアイトラッキングに近いことを行います。イメージでいうと、画面キャプチャの録画をずっと貯めているような感じで、おわかりのように、ものすごいデータ容量になります。我々の想定でいえば、そのデータ容量はおそらくGoogleアナリティクスが現状保持しているデータの数十倍になるはずです。

そうすると、そもそもGoogleはインフラコストを減らしたいわけですし、ヒートマップを追加でリリースしたところで彼らのメリットは特に増えないので、無料でヒートマップツールを出す理由は全くない（※）ということになります。

※唯一私が想定している手を出す理由はありますが、その場合は、Googleアナリティクスの製品群の一部に組み込むとしても、今までとは全く違う手を打ってくると思っています。

自社の解析サーバーを構築する？

もしGoogleがヒートマップやってくれないとすると、利用を諦めるか、どこか別のツールを使うしかありません。しかしヒートマップ描画を含むユーザー行動分析は高コストであり、他の会社がリリースしたとしても事情はまったく一緒。むしろGoogleよりお値段は高くなるはずです（実際、月額数万円〜と高いです）。

ヒートマップは、ユーザーの行動分析2.0と呼んでもいいくらい示唆を与えてくれるものであり、なんとかしたいところです。そう考えた時、クラウドベンダーが無理なら、自社のウェブ分析サーバーを構築し、そこにデータを貯めればいいのでは？という解決策が見えてきます。それならレンタルサーバー代だけですみます。

しかし自社専用の解析サーバーを構築するのは少なくともサーバーエンジニアのノウハウが必要であり、一般的には現実的でありません。ただ一つ例外があります。

WordPressのプラグインという解決策

---

WordPressのプラグインであれば、誰でも手軽にサーバーにソフトウェアをインストールすることができます。そこで開発されたのがQA Heatmap Analyticsプラグインになります。

とはいえ簡単ではない

理屈はそうなのですが、まともに動かすのは簡単ではなく、我々も相当苦労しました。

まずWordPressは様々なレンタルサーバーで稼働しているため、各ユーザーの環境が違います。CPUやメモリやディスク容量にもどのような制限がかかっているかわかりません。そのような環境で大量のデータ処理を行うには、様々な想定を行う必要があります。

また様々なプラグインをいれている人もいますから、まともに動くかも保証できません。よくWindowsのソフトウェアで、ウィルス対策ソフトが入っていてまともに動かないなどという話がありますが、それと同じ現象が発生します。サポートがとても大変です。

またWordPressのプラグインはオープンソースライセンス（GPL）ですので、ソースコードの公開義務があり、これをコピーした人にもソースコード公開の義務があります。これは一般的な商業ソフトウェアを想定した場合、まったく相容れないポリシーです。

次回後編

ということで、そんなWordPressで頑張って、データの正確性が求められるサイトデータ分析ソフトウェアを開発しようというのは、ちょっと変人かも知れません。そもそもWordPressのプラグインにQAと同じ行動データ分析ソフトウェアがない理由だと思います（我々が世界初です）。

ただ、これが中小企業でも気軽にヒートマップを含む行動データ分析を使えるようになる、唯一の解決策でもあったのですよね。ですから、我々としてはチャレンジをすることにしました。

その結果、お伝えしたように山あり谷あり。いろいろ苦労があり、予定よりだいぶ開発にかかったわけです（涙）。
さて、明日は後編として、開発者ブログらしく、QA Heatmap Analyticsの開発の舞台裏（苦労話）をお伝えしたいと思います。

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