URLパラメーターの処理

QA Heatmap Analyticsでは、URLパラメーターが違うURLは別のページとみなします。 しかし、下記のいくつかの特別なURLパラメーターについては、特別な処理を行います。 QA Heatmap Analyticsで特別なURLパラメーターと判定される一覧 URLパラメーター 意味 処理 ?s WordPressの標準サイト内検索 キーワードを保存し、?sページへのアクセスとみなす ?utm_xxx Google AnalyticsのURLパラメーター Google Analyticsと同じ判定を行い、utmパラメーターを除いたページへのアクセスとみなす ?gclid Google広告からのアクセス Google広告からのアクセス(cpc)とみなし、gclidパラメーターを除いたアクセスとみなす ?_ga Google Analyticsのクロスドメインで付与されるURLパラメーター _gaパラメーターを除いたページへのアクセスとみなす

Ver 0.8.3.0を公開しています。

QA Heatmap Analyticsのご愛顧ありがとうございます。 10月15日にVer0.8.3.0を公開しています。 * 特定の環境で管理画面が正常に表示されない不具合を修正 * データ保存期間のデフォルト値を3から2に変更 * 一部のデータを軽量化

ドメインの複数登録の際の差し替え方法について

Q;現在5つのドメインを所有しています。今回はライトプランに登録しようと思うのですが、上限は3ドメインです。仮に今後、初めに登録したドメインの一つを新たなものに差し替えることは可能なのでしょうか? A:はい、可能です。 ライトプランでは同時に認証(有効化)できるサイトが3つになります。従って、おっしゃるように、初めに登録したサイトで不要になったら、違うサイトに差し替えることは可能です。 手順は、古いサイトのラインセンス認証画面で認証を解除し、新しいサイトで新たに認証します。

Google Analytics(GA) にできなくてQA Heatmap Analytics にできることって何ですか?

一番わかりやすいQA Heatmap Analyticsだけができることは、再現動画です。これはどうやってもGoogle Analyticsではできません。 また設定の簡単さにも大きく差があります。仮にGoogle Analyticsでスクロール計測を行う場合、その設定は有識者でないと難しいですが、QA Heatmap Analyticsは、プラグインをインストールするだけで自動計測されます。 しかし、このご質問に対しては、どちらを使うか?ということではなく、我々としては両方使って頂くことを強くおすすめします。 うまいたとえではないかも知れませんが、このご質問は、健康になるために、血液検査と尿検査どちらが優れていますか?というご質問に似ています。 両方とも同じこともわかりますが、そもそもの目的も違っており、わかることも違います。かつ無料なわけなので、両方とも使わない手はないと思います。

QA Heatmap Analyticsが行う通信について

QA Heatmap Analyticsが行う通信は、主に「サイト読者(閲覧者)と行う通信」と「管理者と管理画面で行う通信」と「ライセンス認証で行う通信」の3つにわかれます。それぞれご説明します。 サイト読者(閲覧者)と行う通信 読者がQA Heatmap Analyticsがインストールされたサイトにアクセスすると、読者のブラウザ上でQA Heatmap AnalyticsのJavaScriptが稼働し、WordPress標準のAjax通信を数秒おきに非同期で行います。 Ajax通信で読者ブラウザから送信されてくるデータは、スクロール位置やクリックしたDOMのデータなどです。その内容は主にテキストでサイズは数十〜数百バイト程度であることが多く、通信帯域を占有したり、負荷がかかるようなことはありません。 管理者と管理画面で行う通信 管理画面における処理の概要 管理画面では、サイトのアクセス状況やヒートマップを表示するためにQA Heatmap Analyticsが主にDBに格納しているデータにアクセスし、グラフなど可視化するための処理が行われます。 この処理容量が多いとDBに負荷をかける可能性があるので、QA Heatmap Analyticsではよく使う機能に関してはキャッシュファイルを作成して対応しています。 通信について キャッシュファイルから読み込まれた描画に必要なデータは、サーバから管理者のブラウザに送信され、描画処理は主に管理者のブラウザのJavaScriptで行われます。 従って、一般的な処理においてはサーバーに負荷がかかるようなことはありませんが、データ容量が大きくなると、管理者のブラウザとの通信量が多くなりますので、表示に時間がかかることはあります。しかしその間も複雑なデータ表示処理を行わない限りはサーバーのDBにアクセスすることはありませんので、どのようなタイミングで閲覧しても大丈夫なようになっています。 ライセンス認証で行う通信 QA Heatmap Analyticsにラインセスをインストールした場合、一日に一回、サーバーごとに決まった時間にライセンス認証を行うようになっています。ライセンスをインストールせずに普通に使用している場合は、まったく通信は行われません。 ライセンス認証で行われる通信は主にテキストデータのやりとりで、数キロバイトの通信となり容量も小さく、一日に一回ですので特に問題となるようなことはありません。

Ver 0.8.1.0を公開しています。

QA Heatmap Analyticsのご愛顧ありがとうございます。 10月5日にVer0.8.1.0を公開しています。このバージョンから各ページのヒートマップビューに平均滞在時間の表示が行われます。これはGoogleアナリティクスでは取得できないリアルに近い数値です。ぜひ新機能をお試しくださいませ(プラグインを更新してもらうだけでOKです)。 ※主な変更点 1. ダッシュボードにて参照元がノーリファラーの場合、directと表示2. 管理画面、ヒートマップビューのUI変更(平均滞在時間)3. リファラースパムなどへの対応

インストール時の注意点

QA Heatmap Analyticsは一般的なレンタルサーバーでうまく稼働するように設計されていますが、自社サーバーや特殊な設定が行われているレンタルサーバーに設置する場合は、QA Heatmap Analyticsの仕様をよく把握し、場合によっては設定を変更する必要があります。 特に「PHPとWordPressのバージョン」と「PHPの設定」と「ファイル作成」と「DBの容量」に関して注意が必要です。 PHPとWordPressのバージョン サーバーのPHPのバージョンが5.6以上。WordPressのバージョンが4.5以上をサポートしています。また推奨のサーバースペックとしてメモリは4GB以上搭載し、ハードディスクはSSDであることが望ましいです。 PHPの設定 max_exection_timeは240秒(4分)以上を推奨 QA Heatmap Analyticsは、バックグラウンドでサーバーに負荷をかけないように細切れで集計処理を行います。この集計処理は通常2分以内に終わるように設計していますが、やはりページ数が多かったりアクセス数が多い場合には、時間がかかり、最大10分間かかることを想定しています。 mixhostなどのレンタルサーバーはphp.iniで設定されているmax_exection_timeの初期値が30秒と短い場合があり、その場合は集計処理が完了しない可能性があり、不具合が発生する可能性があります。 max_exection_timeは240秒以上に設定頂くと安心です。 post_max_sizeは10MB以上が推奨 QA Heatmap Analyticsはajaxで表示データのやり取りを行います。基本的にダウンロード方向で容量が発生するので、post_max_sizeは各レンタルサーバーの標準値で稼働するはずですが、クライアント側でajaxエラーが発生する場合、post_max_sizeは10MB以上を指定頂くと安心です。 ファイル作成 QA Heatmap Analyticsはなるべく負荷を低くするように下記のように設計されています。 リアルタイムのデータ保存はファイルシステムで行う DBへの集計処理は負荷の低い時間帯(夜間など)にcron(wp-cron)で行う データファイルはajaxを用いて3秒程度の非同期通信でwp-content/の直下のqa-heatmap-analytics-dataにセキュリティに配慮した形で保存されます。従って、wp-content以下にウェブサーバーから書き込める必要があります。 admin-ajax.phpの許可 QA Heatmap AnalyticsではWordPressの標準ajax通信を使ってデータを保存します。従って、admin-ajax.phpが正しく稼働する必要があります。一般的なレンタルサーバーではWordPressの標準のAjax通信は気にしなくても行えますが、もし特殊な設定でAjax通信を止めている場合は、通信可能な状態にして頂く必要があります。通信について詳しくはこちらをご覧ください。 サポートされるFS_METHODについて WordPressには、FS_METHODと呼ばれるWordPressによるファイル書込をサポートする権限が4種類あります。FS_METHODはwp-config.phpにて定義できます。 このうちQA Heatmap Analyticsでサポートされるのは、直接書込を行うdirectおよびftp経由で書込を行うftpextのみです。標準ではdirectが選択されています。その他のssh2とftpsocketsについてはサポートされません。下記はftpextを定義した例です。詳しくはこちらをご覧ください。 なおftpextについては、ftp経由になるため、どうしてもdirectに比べてパフォーマンスの劣化が見られます。安定稼働のためには、なるべくウェブサーバーからdirectで直接書込が行えるようにすることをおすすめします。 メモリとSwapについて 一般的なレンタルサーバーにおいては、ウェブサーバーから起動されるphp-fpmプロセスの数は静的(static)で制限がかかっています。CPUのコア数以上に稼働させることはできないからです。 しかし、まれに同時接続数によって動的(dynamic)にプロセスが起動する設定のサーバーがあります。たとえばkusanagiなどのWordPressのインストールパッケージにおいては、設定がdynamicになっていることがあります。 その場合、同時接続数が増えると、メモリの消費量が増え、Swapが発生することがあります。 SwapはIOWaitを発生させますので、ファイル書込を行うQA Heatmap Analyticsにとっては大変よくない状況となり、IO Waitが頻発してサーバーに多大な負荷をかけてしまいます。 メモリSwapはQA Heatmap Analyticsに関わらずユーザーに待ち時間を与えるので避けるべきであり、たとえばphp-fpmの同時起動数はメモリおよびCPUが潤沢でない限り、静的にした方が一般的にも安全で意味のある設定になります。 【参考サイト】 DBの容量 QA […]