カテゴリー: 開発者ブログ

QuarkAプロダクトの開発者ブログです。開発秘話や日々の取組などをご紹介しています。

  • QA Heatmap Analyticsの負荷対策やプラグインの競合について

    QA Heatmap Analyticsの負荷対策やプラグインの競合について

    開発の丸山です。
    こんにちは。

    今日は多くの人が気にされる

    1. データ容量大丈夫?
    2. プラグインの競合は?
    3. プラグインは重い?サイトの表示速度は遅くならない?

    の3つに対し、QA ヒートマップアナリティクスがとっている対策についてお話しします。

    1.データ容量について

    GDPRなどプライバシー保護の問題から、GoogleアナリティクスやMS Clarityなどの外部サービスにアクセス解析データをためることが難しくなってきています。事実iPhoneなどのアップル製品では、ITPと呼ばれる仕組みでGoogleアナリティクスでのユーザー追跡をブロックしてしまいます。

    https://webtan-tsushin.com/itp-idfa-google-analytics

    上記の事情から、QAはデータオーナーシップを大切にしています。データは自社のものとして、皆さんのWordPressサーバーにファーストパーティデータを保存し、我々が閲覧することは不可能にしています。

    しかしその事により、レンタルサーバーのデータ容量は大丈夫なの?と不安になる方もいらっしゃると思います。

    これに対する直接のご回答は、今後のバージョンアップで、使用しているディスク容量について表示する予定です。ですので、より安心して使って頂けると思います。

    ただ基本イメージとしてもって頂きたいのは、QAを使うことで問題は発生しないということです。なぜなら、QAは多くの人が利用する無料プランについて「絶対に問題が発生しないデータ容量にする」という考え方をしています。

    具体的には、無料プランでは、アクセス数データは全ページ取得しますが、容量の大きいヒートマップや録画再生データについては初期1ページのみ取得できるようにし、保存期間も2ヶ月間にしています。

    これにより、月間数十万PVがあるサイトでも、QAのデータ容量は最大で数百メガバイト程度になり、一般的なレンタルサーバーでも50GB以上のデータ容量があることから安心して使って頂けるようにしています。

    ということで、データ容量については安心して頂ければと思います。
    有料プランはどうなるの?といったより詳しいことは、下記をご覧ください。

    データ容量について(詳細)

    前提:共用レンタルサーバーには2つの上限(ディスク容量とDB容量)がある

    意識はされている方は少ないと思いますが、ほぼ全ての共用レンタルサーバーにはディスク容量とは別に、DB容量の上限があります。
    一般的にディスク容量の上限は数十GBから数百GBと大容量なのに対し、DB容量は1GBが上限、下手をすると500MBなどすごく少ないです。

    万が一データ容量が溢れると何が発生するか?というのは各レンタルサーバーによって違いますが、多くの場合、「データが多すぎるので消してくれ」と警告が出ます。ただし、DBが上限を超えた場合、厳しい会社では警告と同時にサーバーが強制停止します。

    したがって、QAの第一優先事項は「データ容量(特にDB)を絶対に溢れさせない」ということになっています。
    ※厳密にはファイル数も上限があるのですが、複雑になってくるためここでは触れません。考慮済みであることだけお伝えしておきます。

    QAのデータ容量に対する設計ポリシー

    前述の事情から、QAはデータをDBとディスク(ファイル)に巧みに使い分けながら稼働します。
    具体的には、DBに保存する容量を少なくし、ディスク(ファイル)に保存する期間を長くしています。このことにより、データ容量の節約と有効活用、およびサーバーのスピードアップの一石二鳥を実現しています。

    どんなデータを保存しているのか?

    具体的には、QA ヒートアップアナリティクスは、MS クラリティ+Google アナリティクスの二つの膨大なデータを保持しているイメージに近いです。二つを保持するのでQA “Heatmap”+ “Analytics”といいます。

    このうち、圧倒的にデータ容量が大きくなるのはHeatmapの方のデータです。そこで、なるべくHeatmapの方のデータを削減する工夫が求められます。

    実はQAプラグインを導入する方で、一番多い目的は「今、何人の人が来ているか?」「1ヶ月で何人訪れたのか?」「サイトをどのように閲覧しているのか?」を手軽に知りたいというものです。これはGoogleアナリティクスと同じです。

    そこで、私たちは、無料でお使いの方にはより使いやすいGoogleアナリティクスのような機能と、ヒートマップの一部機能を提供することにしました。一方、有料でお使いのプロレベルの方には、ヒートマップも全ページ取得できるようにして有料レベルのサポートサービスをつける、ということを行っています。

    これが、QAが無料でもGAのようなレポートは出るけど、ヒートマップ計測が1ページだけになっている理由です。このことで容量を削減できるので、無料でお使い頂いている分には、サーバーのことは何も心配せず運用できるようにしています。

    一方、よりビジネスユースや、プロの方は過去データも含め多くのデータが必要になって来ます。しかし、ビジネス畑の方全員がサーバーに詳しいわけではないので、全ページのデータをレンタルサーバーに保存することが不安な方もいらっしゃると思います。そこで有料プランの人には、サーバー環境事前調査など、よりきめ細やかなサポートサービスも用意しています。

    このことにより、プロの方はよりブログ読者様も喜ぶコンテンツ作成ができるようになり、かつサポートが付きますので安心してQAをお使い頂くことができます。

    そして有料プランをお使い頂くことにより、我々QAチームは開発原資を得ることができますので、どんどんバージョンアップもできます。これは三方よしのアイディアだと思っております。

    2.プラグインの競合について

    よく「あるプラグインを入れたら、別のプラグインが動かなくなった」という話を聞かれると思います。この現象は一般的にプラグインの競合と言われています。

    QA ヒートマップアナリティクスは、なるべく競合が発生しないように作成していますが、それでも以下のプラグインと同時に使う場合には問題が発生する場合があります。

    1.表示速度UPのためのキャッシュ系のプラグイン(WP Fastest Cacheなど)
    2.全ファイルをチェックするセキュリティやバックアップ系のプラグイン

    上記それぞれの原因と対策について詳しくはFAQに掲載していますのでご覧ください。

    プラグイン競合の根本原因とQAがとっている対策

    そもそも「なぜプラグインの競合が現象が発生するのか?」、また「既存プラグインや既存テンプレートと、高精度かつ膨大なデータをもつQAの相性が悪いことがあるのか?」というと、主には3つの原因があります。

    1. WordPressの共通の関数(フックやフィルターと言います)を様々なプラグインが使い回すため
    2. JavaScriptやCSSなどのネーミング被りや、勝手にJavaScriptやCSSを書き換えてしまうプラグインがあるため
    3. QAほど高精度でデータを保存するプラグインは今迄存在せず、多くのプラグイン制作者の想像を超えているため

    この中で、1の共通関数については、なるべくQAでは使用しないことで競合を避けています。したがって、QAを入れた時に問題となるのは主に2と3です。

    2については、まずQA側では必ず他と被らない名前をつけるようにしています。しかし、例えばJavaScriptを圧縮し勝手に書き換えてしまうようなキャッシュ系のプラグインについてはQA側では対策の打ちようがありません。従って、この対策は、キャッシュ系(書き換える側)のプラグインの設定を変更して頂く必要があります。

    3については、多くのプラグイン製作者の想像外ということが問題になるケースがあります。特に下記2つのプラグインに気をつけてもらいたいです。

    • バックアップ系プラグイン
    • セキュリティ系プラグイン

    たとえばバックアップで有名なUpDraftプラグインなどは、バックアップする容量に10MBという制限が設けてあります。従ってアクセスが多いサイトでQAを使った場合には容量がその制限を超えてしまうことがあります。

    このように、QA側ではなく、既存のプラグインやテンプレート作成者の想定外が発生し動かなくなることがあります。主な対策はこちらの記事をご覧ください。

    3.プラグインは重い?サイトの表示速度は遅くならない?

    最後にプラグインが重いかどうかですが、QAプラグインはとても軽く作っています。
    実際にP3という、プラグインの重さを診断するプラグインがありますが、そちらを利用して頂いてもQAは表示されません。

    ※参考記事

    https://mem.quarka.org/manual/page-speed-impact/

    そもそも、プラグインが重いとは、具体的には下記を指します。

    1. プラグインのせいでサイトの表示速度が遅くなる(SEOやブログ閲覧者にとって大問題)
    2. WordPressの管理画面を操作した時に、表示が遅い(サイト表示には問題なし。多くは管理者のパソコンの問題)
    3. データ容量が大きすぎて、なんか不安(サーバーが止まることがあるので大問題)

    上記のうち、一般的には1番を「プラグインが重い」と表現します。
    前述したP3という診断プラグインは、このサイトの表示速度に影響を与えるプラグインを特定します。そのP3でQAが出てこないのは、サイトの表示速度に影響を与えないようにQAを設計しているためです。

    具体的には、どれだけ多くのユーザーがアクセスしてきても、QAはデータベースへのアクセスを行いません。またアクセスの記録も3秒毎に行うことで、サーバーへのリクエスト数を少なくしています。

    また夜間の集計処理の時にはデータベースにアクセスしますが、そちらもバルクインサートという一括処理を使うことで負荷を極力減らしていますし、万が一夜間集計処理に時間がたくさんかかってQA側の不具合が出たとしても、サーバーの閲覧速度には影響が出ないようにしています。

    1点だけ、AWSやGCPなど「専用サーバーでWordPressを構築されている」場合は、気をつけて頂きたいです。その理由は、毎月の費用を抑えるためCPUやメモリなどサーバースペックをギリギリにされていたり、実はサーバーセッティングに不備がある場合があるからです。詳しいことはサポートサイトのインストール時の注意点をご覧ください。

    総じて、普通のセキュリティプラグインなどと同等レベルの負荷しかしないので「QAはサイトの表示速度には関係ない」「QAは軽い」と思って頂ければと思います。

    しかし、なんとなくQAが重いのでは?と心配になる人もいらっしゃると思います。
    そこで2番、および3番についてご説明します。

    2番のWordPressでQAのデータを閲覧した時に、表示が遅いことがあるので心配になる方も多いと思います。
    実はQAは、管理画面においてもサーバーに負荷をかけずに、なるべく皆さんのパソコン側に負荷をかけるように設計しています。
    具体的には、データを皆さんのパソコンに一旦ダウンロードしてから、集計処理などはみなさんのパソコンでほとんど行うようにしています。

    ですので、データ表示に時間がかかっていたとしても、それは皆さんのパソコン側の処理に時間がかかっているだけで、サーバー側には一切負荷がかかっていないのです。仮にQAの管理画面でぐるぐるマークで止まったとしても、ブログ閲覧ユーザーはその間も快適にサイトを閲覧できています。ご安心ください。

    最後の3番については、この記事の冒頭「データ容量について」でご説明した通り、絶対にサーバーに問題が発生しないように設計しています。
    ですので、データ容量の問題も発生しません。

    まとめ

    今回の記事では、QAプラグインの負荷や重さについてご説明してきました。
    まとめると「QAプラグインは軽く設計しているので、安心してご利用ください」ということになります。

    QAはグーグルアナリティクスなどと違い、面倒なタグの設定などをせずともインストールするだけで必要なデータ収集を行います。

    ぜひ安心してQAをサイト改善のお供として役立てて頂ければ嬉しいです。

  • サイト分析をゲームのように楽しく!QAがバージョン2.0になりました。

    先日8月17日、QAヒートマップアナリティクスがメジャーアップデートし、Version2.0になりました。

    メニューとして大きく変わったのは、「ホーム」が新設されたこと。
    旧新相対は以下の通りです。
    ・リアルタイムビュー    ⇒ ホーム『リアルタイム』
    ・サイト統計情報(グラフ) ⇒ ホーム『全体推移』
    ・サイト統計情報(PV一覧) ⇒ ホーム『見たいデータを探す』(セッション一覧として)

    使い方について詳しくは、サポートサイトに記載しています。
    ▼ホーム
    https://mem.quarka.org/manual/adminpage-home/

    この記事では、今回の更新内容がなぜメジャーアップデートなのか?などをご説明し、このブログのタイトル「ゲームのように楽しく!」に込めた思いなどをお話したいと思います。

    なぜ今回の更新内容がメジャーアップデートなのか?

    今回はversion1.0と決定的に違う箇所があります。
    それは、QAが本質的に「現行GA+MS Clarityというダブルデータ」を保持しているツールだから実現した機能が入っているということです。
    具体的には、下記の2つができるようになりました。

    1.utmパラメーター付きの全PV一覧をcsvダウンロードできる

    「全体推移」というホームに新設されたタブメニューでできるようにしています。

    ピンと来る人には説明不要だと思いますが、これはGAのユーザーエクスプローラーのデータを全て一括ダウンロードできるイメージですね。広告運用とかでやりたかった人が多いと思いますし、私も欲しかった機能です。

    2.「目標達成したセッションのみ」を抽出して、そのヒートマップと再生ができる

    「ヒートマップを探す」というホームに新設されたタブメニューでできるようにしています。

    ・「目標達成した人(任意のページを見た人)のセッション抽出」(GA)
    ・「ページ内部をどのように閲覧したのだろう?(ヒートマップ+セッション再生)」(Clarity)

    のダブルデータを保持しているからできる機能です。

    他のツールにはない「便利」のはじまり。だから2.0

    ずっとこういった機能を作りたく、初期の設計思想から入っていました。
    これを一般的なレンタルサーバーでも、容量や速度など気にせず安心して使ってもらうため、今まで頑張ってきたという感じです。イメージというと、ver1.0とver2.0の違いは下記です。

    1.0・・・GA+Clarityという膨大なダブルデータを取得するバックヤード部分の構築
    2.0・・・そのデータをもとに分析ツールとして新体験を増やしていく。楽しい部分。

    今まで使いやすいと評判を頂いているQAですが、実はバックヤード部分の構築が多かったです。
    これからは、画面周りの機能が増えていきます。だからver2.0になりました。
    (高速化とデータ量のために、QA独自のlow-layerのDBを作ったので、まだバックヤード部分は継続してやっていく必要があるのですけどね)

    新しいイメージは、動画でもご説明しています。

    サイト分析ツールの課題

    今までもしばしば書いていますけど、多くのサイト分析ツールには下記の課題があると思っています。

    • 直感的に使えない
    • 今一歩、欲しいデータが見れない(落とせない)
    • ユーザーの行動の細部がわからない(インサイトに辿りつきづらい)

    これを解決するために作っているのがQAです。

    操作感へのこだわり

    QAって機能が少ないので、機能を単純比較すると全負けするのすけど(苦笑)、これにも少し理由があります。

    たとえば今回は「サイト統計情報」というメニューを削除し、ホームに機能を集中させています。これも機能拡充の面でいったらマイナスです。マーケティング的にもよくないでしょう。

    でも、ユーザーインタビューを行っていく中で、サイト統計情報を使っていなかった人が多かったんですよね。中には気づいていない人も(汗)

    そこで、このメニュー自体が混乱を生んでいると考え、仮説とモックによるユーザーテストを繰り返しながら「直感的に操作できる/意味がわかる」メニューに変更したのです。

    そのため機能は減っているのですが、自然に、新しい機能を使ってもらえるのではないかと思います。

    サイト分析をゲームのように楽しく!

    先ほど、サイト分析ツールの課題と書きましたが、端的にいうと

    • タグ設置とか、サーバーサイドとかいろいろめんどくさい!
    • なんかいちいち時間もかかる!
    • 分析業務への負担が重い!

    私達としてはQAを使ってもらうだけで

    • とりあえずプラグイン入れておくだけで
    • なんかツールがいろいろ裏でやってくれていて
    • やりたかった分析が高速かつ直感的にできる

    としたいと思っています。
    目指したいのは、ゲームのような操作感です。初心者のみならず、プロこそ「時間」が大切だと思っていますので。

    ver2.0になったことで「これすごい!」という新しい体験を作っていけると思いますので、ぜひ期待してもらえたらと思います。

    追伸:

    9/17まで新規インストールキャンペーンを行っています。
    https://quarka.org/oishii-kobe-campaign/

    無料のQAプラグインを入れるだけで、全員に3万円相当のプレゼント。
    さらに抽選で「神戸の美味しいもの」があたるというお得なキャンペーンです。
    応募方法も簡単。こんな感じです。

    csv一括ダウンロードは無料でも使えますし、とりあえずプラグインを入れておいてもらえばデータ溜まりますのでお勧めです。もし役立ちそうな案件やお友達がいれば、ぜひこの機会にインストールお願いします!

  • QA 1周年記念ありがとうWキャンペーン「Twitterフォロー&RT」コース

    QA 1周年記念ありがとうWキャンペーン「Twitterフォロー&RT」コース

    \日本から世界へ!観察が楽しくなるアクセス解析WordPressプラグイン/

    Twitterフォロー&RTで世界一しあわせな動物クオッカステッカープレゼント!

    Twitterフォロー&RTで
    世界一しあわせな動物クオッカステッカープレゼント!

    「世界一しあわせな動物クオッカ」オリジナルステッカー(5枚セット)を抽選で39名様にプレゼント

    \Wチャンス!/

    さらに当選された方の中から1名にQA Heatmap Analyticsパーソナルライセンス3か月分(1万円相当)をプレゼント!

    [応募期間:2021年3月12日(金)23:59まで]

    「お友達紹介でQAライセンスGet」コースの応募はこちらから

    QA 1周年記念ありがとうWキャンペーン「Twitterフォロー&RT」コース概要

    2020年2月12日にβ版をリリースして1年。
    みなさんに感謝をこめて「QA 1周年記念ありがとうWキャンペーン」を開催します。

    参加方法は、TwitterのQA Heatmap Analytics公式アカウント(@QuarkA_JP)をフォローし、「QA 1周年記念ありがとうWキャンペーン」の対象ツイートをリツイートするだけ。

    「世界一しあわせな動物クオッカ」オリジナルステッカー(5枚セット)を39名様にプレゼント
    PCやタブレット・スマホなどに可愛く貼って、邪魔にならない大きさ(約5cm×5cm/1枚)です。

    「お友達紹介でQAライセンスGet」コースの応募はこちらから

    応募手順

    • QA Heatmap Analytics公式アカウント(@QuarkA_JP)をフォロー
    • 「QA 1周年記念ありがとうWキャンペーン」の対象ツイートをリツイートして応募完了
    https://twitter.com/QuarkA_JP/status/1360092014759448589

    すでにQA Heatmap Analytics公式アカウント(@QuarkA_JP)をフォローしていただいている方は、手順2のみで応募完了です。

    抽選・当選連絡・プレゼントのお届け

    キャンペーン応募期間終了後、厳正な抽選を行ないます。
    当選された39名様に、QA Heatmap Analytics公式アカウント(@QuarkA_JP)からDMでご連絡いたします。
    当選発表連絡までに公式アカウントのフォローを外さないようご注意ください。

    また、当選された方の中から1名にQA Heatmap Analyticsパーソナルライセンス3か月分(1万円相当)がWチャンスで当たります。
    こちらもTwitter DMでご連絡いたします。

    当選連絡のDMで、ステッカー発送(39名様)およびパーソナルライセンスキー発行(1名様)のために必要な情報入力フォームをお知らせします。

    ステッカーの発送は2021年3月下旬頃を予定しておりますが、諸事情により発送が前後することがございます。ご了承ください。

    応募期間

    2021年2月12日(金)~2021年3月12日(金)23:59まで

    応募資格・注意事項

    応募資格

    • Twitterのアカウントがあり非公開設定されていない方
    • Twitterのアカウントがあり QA Heatmap Analytics公式アカウント(@QuarkA_JP) からのDMが受け取れる方
    • 日本国内にお住まいの方
    • 注意事項にご同意いただいた方

    注意事項

    • 当選結果のお問い合わせにはお答えできません。
    • ご当選された商品の交換・換金およびご当選権利の譲渡はできません。
    • ご当選された方でお知らせいただいたご住所等の間違いにより、賞品がお届けできない場合には当選無効となります。
    • ご当選された方にお送りする情報入力フォームには入力期限がございます。期限内にお手続きをいただけない場合、当選が無効となります。
    • ご当選された方にお送りするクオッカステッカー(5枚セット)はすべて応募されるご本人様の住所1箇所にお送りいたします。
    • 応募者がキャンペーンへ応募した場合、この応募要項ならびに注意事項に同意したものとみなします。
    • リツイート投稿により発生したトラブルにつきましては、一切責任を負いかねますのでご了承ください。
    • Twitterのシステム障害や通信回線等の障害、瑕疵等により本キャンペーンの提供が中断もしくは遅延し、または誤送信もしくは欠陥が生じた場合に応募者が被った損害について、一切の責任は負いかねますのでご了承ください。
    • Twitterのポリシーに反する不正なアカウントを利用して応募があった場合、事務局の判断により当該アカウントからの応募を無効とさせていただく場合がございます。
    • 応募期間は諸事情により変更する場合がございます。その場合に、QA Heatmap Analytics公式アカウント(@QuarkA_JP)より事前に通知いたします。
  • QA 1周年記念ありがとうWキャンペーン「お友達紹介でQAライセンスGet」コース

    QA 1周年記念ありがとうWキャンペーン「お友達紹介でQAライセンスGet」コース

    \日本から世界へ!観察が楽しくなるアクセス解析WordPressプラグイン/

    お友達紹介でQAライセンス総額10万円分プレゼント

    お友達紹介でQAライセンス総額10万円分プレゼント!

    \全員に当たる!/

    お友達を1人紹介で、QA フレンドライセンスを全員にプレゼント

    \先着で当たる!/

    お友達を5名紹介で、QA Heatmap Analyticsパーソナルライセンス3か月分(1万円相当)を、先着9名様にプレゼント

    \抽選で当たる!/

    お友達にブログやTwitter等で QA Heatmap Analyticsを紹介してくれたら、「世界一しあわせな動物クオッカ」オリジナルステッカー(5枚セット)を、抽選で9名様にプレゼント

    [応募期間:2021年3月12日(金)23:59まで]

    QA 1周年記念ありがとうWキャンペーン「お友達紹介でQAライセンスGet」コース概要

    2020年2月12日にβ版をリリースして1年。
    みなさんに感謝をこめて「QA 1周年記念ありがとうWキャンペーン」を開催します。

    参加方法は、QA Heatmap Analytics(WordPress 公式プラグイン)をあなたのサイトにダウンロード/インストールするだけ。

    プレゼント内容

    特典1.全員に当たる!お友達を1人紹介でフレンドライセンス
    特典2.先着で当たる!お友達を5人紹介で有料ライセンス
    特典3.抽選で当たる!お友達に紹介してくれたらクオッカステッカー

    【特典1】全員に当たる!
    お友達を1人紹介で、QAフレンドライセンス

    QA Heatmap Analyticsはアカウント登録不要・無料で、インストール初期は1ページのみ計測可能です。

    お友達に紹介すればするほど計測ページを増やすことができる「QA フレンドライセンス」を、キャンペーン参加された全員にプレゼントします!

    【特典2】 先着で9名様に当たる!
    お友達を5人紹介で、QA パーソナルライセンス3か月分(1万円相当)

    QA Heatmap Analyticsはアカウント登録不要・無料で利用できます。
    無料版と有料版の大きな違いは、計測できるページ数と今後拡張される追加機能。

    QA Heatmap Analytics(WordPress 公式プラグイン)をあなたのサイトにダウンロード/インストールして、お友達を5名以上紹介してくれた方から、QA Heatmap Analyticsパーソナルライセンス3か月分(1万円相当)を先着9名様にプレゼント

    【特典3】抽選で9名様に当たる!
    QAオリジナルクオッカステッカー(5枚セット)

    QA Heatmap AnalyticsをブログやTwitter等でお友達に紹介してくれたら、「世界一しあわせな動物クオッカ」オリジナルステッカー(5枚セット)を抽選で9名様にプレゼント

    PCやタブレット・スマホなどに可愛く貼って、邪魔にならない大きさ(約5cm×5cm/1枚)です。

    応募手順

    STEP1

    QA Heatmap Analyticsを
    あなたのサイトにダウンロード/インストール

    WordPress公式プラグイン
    STEP2

    お友達紹介プログラムに参加する

    お友達紹介
    STEP3

    発行された「あなたの紹介URL」を
    あなたのブログ・Twitter・メール・チャットなどに貼り付けて、お友達にQA Heatmap Analyticsを教える

    すでにQA Heatmap Analyticsをインストールしてご使用いただいている方は、2以降の手順で応募完了です。

    すでにQA Heatmap Analyticsをインストールしてご使用いただき、かつお友達紹介プログラムにご参加いただいている方も参加できます。
    2021年2月12日(金)から紹介いただいたお友達の数でカウントします。

    当選連絡・プレゼントのお届け

    全員にプレゼントする特典1「QA フレンドライセンス」のライセンスキーは、お友達紹介プログラムに登録いただいたメールアドレス宛にQA Heatmap Analytics事務局からメールでお送りいたします。

    特典2「QA パーソナルライセンス」は、お友達紹介プログラムに登録し、紹介したお友達がQAを使い始めた人数が5名に達した方へ、先着順に9名様に当たります。
    先着9名様に発行されるライセンスキーは、登録いただいたメールアドレス宛にQA Heatmap Analytics事務局からメールでお送りいたします。

    特典3「クオッカステッカー」は、QAをブログなどで紹介いただいたことをQA事務局が確認した方から厳正な抽選を行ないます。
    当選された9名様に、お友達紹介プログラムに登録いただいたメールアドレス宛にQA事務局からメールでご案内をお送りいたします。

    特典2、特典3に当選された方にお送りするメールで、パーソナルライセンスキー発行(9名様)およびステッカー送付(9名様)のために必要な情報入力フォームをお知らせします。

    ステッカーの発送は2021年3月下旬頃を予定しておりますが、諸事情により発送が前後することがございます。ご了承ください。

    応募期間

    2021年2月12日(金)~2021年3月12日(金)23:59まで

    応募資格・注意事項

    応募資格

    • QA Heatmap Analyticsをご使用いただいている方
    • 日本国内にお住まいの方
    • 注意事項にご同意いただいた方

    注意事項

    • 当選結果のお問い合わせにはお答えできません。
    • ご当選された商品の交換・換金およびご当選権利の譲渡はできません。
    • ご当選された方でお知らせいただいたご住所等の間違いにより、賞品がお届けできない場合には当選無効となります。
    • ご当選された方にお送りする情報入力フォームには入力期限がございます。期限内にお手続きをいただけない場合、当選が無効となります。
    • ご当選された方にお送りするクオッカステッカー(5枚セット)はすべて応募されるご本人様の住所1箇所にお送りいたします。
    • 応募者がキャンペーンへ応募した場合、この応募要項ならびに注意事項に同意したものとみなします。
    • ブログやTwitter投稿により発生したトラブルにつきましては、一切責任を負いかねますのでご了承ください。
    • WordPress・ブログ・Twitter等のシステム障害や通信回線等の障害、瑕疵等により本キャンペーンの提供が中断もしくは遅延し、または誤送信もしくは欠陥が生じた場合に応募者が被った損害について、一切の責任は負いかねますのでご了承ください。
    • QA Heatmap Analyticsのポリシーに反する不正なアカウントを利用して応募があった場合、事務局の判断により当該アカウントからの応募を無効とさせていただく場合がございます。
    • 応募期間は諸事情により変更する場合がございます。その場合に、QA Heatmap Analytics公式アカウント(@QuarkA_JP)およびQA Heatmap Analytics公式サイトで事前に通知いたします。

    →もう一つのコースも同時エントリ可能です「Twitterフォロー&RT」コースの応募はこちらから

  • QAは2月12日に一周年を迎えます

    QAは2月12日に一周年を迎えます

    QA Heatmapがβ版として本サイト内で産声をあげた2020年2月12日。

    それからコロナの本格化など、予想もしていなかった形で世界が大変になり、急速なオンライン化が進む中、せっせとチームで開発し、名前のお尻にAnalyticsがついてWP公式プラグインとして正式にリリースできたのが昨年8月27日。

    それからも平均1.5週間に一回のペースで改善を重ねたQA Heatmap Analytics(日本名:QA ヒートマップアナリティクス)は、今週末2月12日(金)に一歳の誕生日を迎えます。

    おかげさまで最近はブログ記事などでも少しずつ紹介していただけるようになりました。QA利用者からは「使いやすさに驚いた!」といったご意見をいただく事が多いです。

    しかし逆に「有益すぎてライバルが増えそうなのであまり教えたくない!」という声もちらほら聞こえてきていまして(汗)、むしろ知る人ぞ知るという感じになっています。

    お友達に紹介してもらえたらスタッフ一同泣いて喜びます

    今回の1周年を記念して、今日からお友達にQAをご紹介をして頂くと、無制限で計測ページ数が増えるようになりました。

    これで無料で十分使えるツールになりましたし、本当に多くの方にプラグインを入れるだけで、手軽に行動分析の面白さを味わって頂きたいと思っています。

    改めてQAを試して頂き、もし気に入って頂けた方は、お友達紹介プログラムを活用してブログやTwitter、 Facebookなどでご紹介頂けると嬉しいです。

    正直、今は少ないですけど^^;ブログやTwitterで紹介されるとチームは盛り上がったりして、やはり開発のモチベーションになっています。

    それに多くの方に使って頂くほど、バグをはやく潰せたり、開発のスピードを早めて、新機能を予定より早くお届けすることができます。

    無料だからといって今年も手を抜くことなく、より多くの方に知って、使って頂く一年にしたいので、より良いツール開発のためにも、ぜひご協力頂けたら嬉しいです。

    QA 1周年記念ありがとうWキャンペーン

    ※有料との違いについて

    ちなみに有料との違いについて気にされる方もいらっしゃると思いますが、無料で十分に使えるようにしたのですが、有料はビジネスユーザーのためのツールといいますか、圧倒的に時間が節約できるように設計しています。当然、我々自身も有料ライセンスを自分達で使ってそのメリットを享受しています。

    そのあたりのポリシーなどはFAQに記載していますので、興味のある方はご覧ください。

    現QA Heatmap Analyticsの5つの特徴

    1.お友達紹介で計測ページ数の無限アップ

    多くのヒートマッププラグインは計測ページが1ページだけのことが多いですが、QAは、お友達紹介プログラムを活用して頂くと、ご本人とお友達のお二人にお友達ライセンスが届きます。

    このライセンスにより計測ページ数が増えるのですが、本日リリースしたバージョンから、ご紹介があるたびに、ご紹介者の計測ページ数が勝手にどんどん無限に増えるようになりました。

    これにより、例えばブログやSNSなどで一度ご紹介しておいて頂ければ、勝手に計測ページ数が無限に増えていきます(その都度メールで通知が行きます)。もちろん先ほどお伝えしたように、そこから申込んだ人にもライセンスが届きますので、閲覧者にもメリットがあります。

    これで、ほぼ無料でかなりのことができるようになると思います。

    2/12からのキャンペーンでも、お友達紹介プログラムの参加者は自動エントリーされてお得なので、QAをご紹介くださる方はぜひご利用ください。

    2.録画再生機能

    ブログなどでQAをご紹介頂く時に、すごくフィーチャーして頂ける機能です。ユーザーが閲覧した行動をその場で録画し、すぐに再生することができます。

    自分たち調査ですが、現時点で、QAは世界中もっとも正確にリアルタイムで全ページの録画データを記録する無料ソフトなので、例えば広告キャンペーンを開始した当日に「この広告LPの反応どうかな?」などを見る場合に便利だと思います。

    こちらもプラグインインストールをするだけで、リアルタイムですぐに計測が始まるので(今から入れれば30分後には見れます)、まだの方はぜひ体験して頂きたいな、と思います。

    なお、察しの良い方はお分かりだと思いますが、QAは旧GAと同じデータを持っていて、さらにこのような録画(イベント)データを同時に記録しています。つまり旧GAと新GAの計測を自動で同時にやっているようなもので、この二つが融合することによって実現できるQAならではの機能を今後お見せ出来ると思います。

    3.サイト統計情報

    サイト統計情報

    2/12にリリース予定の新機能です。

    上記画像を見てもらったらおわかりの通り、Googleアナリティクスのような画面なのですが、Excelのフィルタのようにデータを簡単に絞り込んでグラフを確認できます。日付時刻も出ますしユーザーも絞り込めますので「この日に申し込んだ人はどのページから来たの?」もすぐにわかります

    実はQAはプラグインインストール直後から自動で全ページビューのデータを記録しています(無料版で全ページ取得していています)。GA4ではなく、旧Googleアナリティクスと同じです。細かいですがutmパラメータにも対応しています。

    「実は」というのは、今まで表示画面がなかったので、おそらくDBを見た人以外、誰も気づかなかったと思うからです。

    今までプラグインを入れていた方は、データが溜まっているので、すぐに使い始めることができます。ぜひ2/12にアップデートしてお試しください。弊社内でもすごく好評の機能です。

    余談ですが、QAは根幹のデータを早めに溜めておいて、表示画面はユーザーテストに時間をかけてからリリースすることが多いので、今すぐ使う予定がない人も、とりあえずプラグインだけ入れておいて頂くとデータが溜まるのでいいかな、と思います。

    4.投稿、固定、カスタム投稿一覧に各ページのアクセス解析を表示

    わざわざQA Heatmap Analyticsの画面にアクセスしなくても、普通にワードプレスの投稿画面から各ページの状況が一目でわかるようにしました。

    これにより、記事のリライトをする時や、最近書いた記事のアクセスに自然に気づけるようになりました。記事って書いた後、ほったらかしになりやすいですからね。。

    5.データの改善

    最後は画面がなくわかりづらいのですが、β版と比較して大きく変わったデータについて。

    この1年運用する中で、内部のデータ構造を見直したりして、とにかく「速く、軽く、正確に!」動けるように対処していっています。

    以前の記事でもご説明しましたが、世界のウェブサイトの三分の一のシェアを占めるWordPressにおいて、その世界中の未知のサーバーを相手に正確かつ速くて軽いデータ分析ソフトを作るというのは大きなチャレンジなのですが、ほぼ完成形に近づいたと自負しています。

    いくつかの条件が重なったエンタープライズのケースでは、どうしてもワードプレスの公式プラグインとしては使えない軽量化の手法もあるので、ある特定の機能は有料サポート付きで出すしかないとは考えていますが、それでも現時点でほとんどの世界中のサイトを「無料プラグインを入れるだけで計測できる」状態にできたかと思います。

    QA Heatmap Analyticsは、ヒートマップではなく、今まで存在しなかった「自立分散型行動分析(アナリティクス)プラットフォーム」であり、多くの方に使ってもらうほど、より進化するように設計しています。今後も改善を続けて行きますので、楽しみにして頂けたらと思います。

    最後に。これからのQA

    今日は、QAが生まれて最初の一年を新しい5つの機能で振り返ってみました。

    今週末2月12日の誕生日から、こちらのページで一周年記念キャンペーン(2/12公開)を行います。祭りみたいなものなので、ぜひ楽しんで頂けたらと思います。

    「Twitterフォロー&RT」コース
    「Twitterフォロー&RT」コース
    「お友達紹介でQAライセンスGet」コース
    「お友達紹介でQAライセンスGet」コース

    これからのQAなのですが、ロードマップにあるように今年の春夏ごろにver2.0になる予定です。ver2.0はサイト統計情報の拡張がメインになってくると思います。過去PVデータを検索して録画再生ができたり、ですね。これが無料でできる解析ツールは世界初かと思います。

    また今年はこのロードマップには出ていない形で、別の観点で喜んで頂けるモノをリリースする予定です。これはちょっと驚かれるかも知れませんが、その時のお楽しみということで笑。

    また来月くらいからnoteでQAについての情報発信をまずは月1本くらいのペースで行います。

    noteの記事は我々がインタビューを受ける形で進められており、また違った角度でQAについて知ってもらえるのかな、と思っています。

    それでは、また1年後に二周年を振り返る記事を書くと思いますが、良い意味で期待を超えたというご報告をできるよう頑張ります。

    今後ともQAをよろしくお願いいたします。

  • 1億件のデータをJavaScriptで処理した時の所要時間

    ※この記事は備忘に近いので、今後テストの度にこのページを改訂していく可能性があります。

    QA Heatmap Analyticsは膨大なデータを処理することを想定しているので、仮に月間1000万PV近いサイトを分析する場合、1億件以上のデータを処理しなくてはなりません。

    この処理に時間がかかるようでは、実用的ではなく、どのようなクライアントスペックが必要なのか、またどのくらい速度がかかるのかを簡単に検証したいと思いました。

    そこで、シンプルなテストで、まずはChromeブラウザがどれくらいの速度で1億件のデータを処理するのかを計測してみました。

    検証方法

    Chromeを使用し、ある程度QA Heatmap で実際に想定している配列データ(ほとんどInt型で構成。一部文字列。通常DBであれば1レコード最低70Byte程度は必要)を1億件構築し、簡単なテキスト検索を行ってみました。詳しくはテストコードをご覧ください。

    特に検証したかったこと。

    • 1億件の配列の作成にどれくらい時間がかかるか
    • 全てオンメモリするのか
    • ループの書き方でどのくらい速度の違いがあるか?

    検証環境

    • iMac OS macOS Big Sur
      • CPU 3.4GHz クアッドコア Intel Core i5
      • メモリ 40GB
      • ディスク HDD(ただしフュージョンドライブなので一部SSD)
    • Chrome バージョン: 87.0.4280.67(Official Build) (x86_64)
    • メモリ利用量の確認方法
      • Chromeタスクマネージャーでタブに割り当てられたメモリを確認

    結果

    速度について

    作業方法速度
    1億件の配列作成forループ5609ms
    作成直後に文字列検索forループ3964ms
    forEachメソッド※1回目メモリーリーク発生
    5296ms

    速いのはforループです。また5秒程度で1億件処理するのは、結構速いな、と思いました。しかしそれより問題なのは後述するメモリーリークです。

    メモリ利用量について

    フェーズメモリ量
    配列作成前18.4MB
    作成後2.6GB
    10分ブラウザ放置後1.9GB

    普通に計算すれば1億件で700MB程度は最低必須のデータです。こちらをforループで配列作成したところ、ある意味想定通り、数GBのメモリを確保しオンメモリしました。

    あと面白いのは、ブラウザを放置するとメモリ確保量が減っています。ヒープで余分に確保していたメモリなどを最適化できるのだと考えています。しかし今回はその程度のガベージコレクションがあっても、そもそも後述するメモリーリークが大問題なので、どうでもいい話だと思います。

    メモリーリークの発生!

    一回目のforループが終わったあと、すぐにforEachをかけると、22584ループ目で「Paused before potential out-of-memory crash」が発生しました。いわゆるメモリーリークです。

    下記のChromeDevToolの公式サイトを参考に原因の解明を行おうと思ったのですが、、

    ▼メモリ問題の解決(Chrome DevTools)
    https://developers.google.com/web/tools/chrome-devtools/memory-problems/

    なにせ1億件もあるとデバッグも大変で、Heapのスナップショットの取得、描画だけでも異様に時間がかかります。下記のように40GBのメモリを積んでいても関係ないくらいメモリを喰い、スワップ発生しまくりです。

    130GB!?恐ろしい。。

    結局、数時間まっても動かず、どちらにせよ、下記のブラウザのメモリ限界に達した可能性が極めて高く、所感にも記載しますが、そもそも数GBのメモリ確保は現実的ではないので原因の追及はやめることにしました。

    Chromeのメモリ最大容量は4GBらしい

    すごく参考になる検証をされている方がいたので下記にリンクを記載しますが、そもそもChromeのメモリの最大容量は4GBのようです。さらに他のブラウザも検証されていて、Safiriでは1.4GBあたりでクラッシュ。それを考えても数GBのメモリを確保して処理させるのは危険すぎます。

    ▼ブラウザで扱えるメモリ上限の確認 -nodachisoft
    https://nodachisoft.com/common/jp/article/jp000005/

    所感

    メモリ容量が大きいパソコンを使えば、想定通り1GBを超えてもオンメモリはできました。

    しかし、その後が悲惨で、そもそも各ブラウザのメモリの上限が1〜4GBでばらついていることを考えてもメモリリークしないように管理するのは至難の業だと思われます。

    結論として、使用するメモリは合計で1GB以内で想定した方がよさそうですし、できるだけ小さくする方が良いでしょう。

    そうなると、数億というデータ分析は、BigQueryや、TresureDataなどのCDP、クライアントであればTableauなどの専用ツールに任せるのがベターです。そもそも数億のデータを持ちうる企業でデータ活用の文化がないことは考えづらいので、生データをうまくひけるAPIを整備する方が現実的でしょう。

    ちなみにGoogleスプレッドシートの最大処理件数が500万行、Excelで100万行程度らしいので、やはり一億どころか一千万という単位からデータ活用は別次元で考えた方が良さそうです。

    なお今回のテストの副産物として、処理速度を見ると、巨大な配列になるほどforEachなど配列メソッドは遅くなりそうなので、なるべく避けていき、forループなど、ネイティブに近そうなシンプルな処理を組み合わせるのがよさそうだと思っています。

    過去にSafariのDate.Parse()の遅さ(微妙な差なのですがループが多いと効く)でハマったことがあり、なるべくブラウザ依存しなそうな処理を使い、メモリとCPUを想像しながらプログラムを書くことが求められそうです。

    テストコード

    <h1>1億件の配列作成</h1>
    <input type="button" value="start" onclick="datamake();">
    <br>forLoop<input type="text" onchange="findtext(this)">
    <br>forEach<input type="text" onchange="findtext2(this)">
    <script>
        let ary = [];
        function datamake() {
            let now = new Date();
            console.log(now.getTime());
            for (let iii = 0; iii < 100000000; iii++) {
                ary.push([1,	1,	1,	1,	190,	0,	0,	2,	'2020-11-15 13:30:23',	1,	0,	45,	0,	0]);
            }
            let end = new Date();
            console.log(end.getTime());
        }
        function findtext(obj) {
            let findtxt = obj.value;
    
            console.log('for loop');
            let now = new Date();
            console.log(now.getTime());
            let findidx = [];
            for (let iii = 0; iii < ary.length; iii++) {
                //indexOf が一番早い http://oredon.guitarkouza.net/blog/2017/03/javascript-string-match.php
                if (ary[iii][8].indexOf(findtxt) > -1) {
                    findidx.push(iii);
                }
            }
            let end = new Date();
            console.log(end.getTime());
            console.log(findidx.length);
    
        }
        function findtext2(obj) {
            let findtxt = obj.value;
            console.log('for Each');
            now = new Date();
            console.log(now.getTime());
            let findidx2 = [];
            ary.forEach( (rowary,idx) => {
                if (rowary[8].indexOf(findtxt) > -1) {
                    findidx2.push(idx);
                }
            });
            end = new Date();
            console.log(end.getTime());
            console.log(findidx2.length);
        }
    </script>
  • ExcelみたいなフィルターをJavaScriptで。QAフィルターを作成しました!

    2021年8月16日追記。Ver.2.0.0.0より、使い心地はそのままにQAフィルターのデザインが新しく使いやすくなっています。たとえば「どのLPがよく読まれていのか?」をすぐに判断できます。ぜひ活用ください。

    QA Heatmap Analytics Ver.1.0.1.0よりQA Table Generatorを使ったQAフィルターが使えるようになりました。
    表示されているデータの絞り込みがより直感的にできるようになっています。
    詳しくはこちらの動画をご覧ください。

    ※字幕をONにすると説明が表示されます

    解決したかった課題

    一般的なアクセス解析ツールで表示データを絞り込む時には、下記のような課題がありました。

    • 昇順降順ってどっちだっけ?
    • フィルタの存在に気づかない
    • 複数条件で絞り込む方法が直感的ではない。どこにあるかわからない

    優れているExcelのフィルタ

    このようなデータ絞り込み機能の課題を解決している最も優秀なツールはExcelだと思っています。
    Excelのフィルタ機能は直感的で、一度人から教われば誰でも使いこなすことができます。

    私はExcelの構築に関わったJoel Spolskyをとても尊敬しており、Excel自体も尊敬しているので、ぜひこの慣習にならいたいと思いました。

    とはいえ、Excelのフィルターにもいくつかの弱点があります。

    • フィルタ機能の存在を知らないと使えない
    • あまりに高機能で、少しわかりづらくなってきている
    • 複数条件で絞り込んだ時に、どの条件で絞り込んだか迷子になりやすい

    これら全ての課題を解決するために生み出されたのがQAフィルターです。

    QAフィルターの主な特徴

    • 知らない人でも直感的に触れる
    • 必要十分な作業だけ残したフィルタ
    • 全てのフィルタを同時にオープン・クローズできる
    • ウェブ上の操作に特化している(JSONやJavaScriptのデータ配列から動的にTableを生成する)

    現在の仕様

    現在の仕様では、クライアント環境に依存するデータ処理の負荷を下げるため、QA Filterに表示されている領域のみがフィルターの対象になります。例えば、3万件のデータがあるとして、1万件が初期表示されている場合、フィルターの対象はその1万件のみとなります。

    今後この仕様は改訂になる可能性があります。

    使ってみたい方へ

    ぜひQA Heatmap Analyticsプラグインを導入ください。

    プラグインの新規追加で「QA Heatmap」と検索するとみつかります。
    導入するとすぐに表示される「ダッシュボード」のリアルタイムビューにてQAフィルターを活用することができます。

    QAフィルターは100%GPLなので、どなたでも使えます。

    我々はこのQAフィルターをQA Heatmap Analyticsの統一の操作として活用していきたいと思っています。しかしQAフィルター自体は、汎用的なJavaScriptライブラリとして開発していきます。(その方が我々も使いやすいので)

    まだまだ汎用的ではなく突貫的に対応している箇所もありますので、しばらくはQA専用で開発していきますが、現時点でもGPLが適用されていますので、どなたでも利用は可能ですし、自由に改変もできます。※GPL適用が必須です。

    cssも現在はソースの中に記載しているので、「table.js」だけで利用できます。
    ソースはWordPress公式サイトのこちらにあります。

    https://plugins.svn.wordpress.org/qa-heatmap-analytics/trunk/js/

    なおライセンスはGPL2.0ですので、それに従う必要があります。
    GPLについて詳しく知りたい方はこちらの記事をご覧ください。

    ただ今のところQAフィルターはQA Heatmap Analytics向けに最適化していきますし、Font Awesomeを利用しているのでそのクレジットも必要です。ですから、しばらくして汎用化したら、そのタイミングでGitHubで公開し、ライセンス関連も整理したらMITライセンスによるオープンソース化も検討しています。

    もしバグなど見つけた方は、教えて頂けると助かります。(修正コードがある方は教えてもらえるともっと助かりますw)

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

    こんにちは。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ヶ月間にしています。

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

    • 誰でもデータ容量を気にせずヒートマップを活用してもらえる
    • 手軽に計測ページを変更できるので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は大幅に進化したように思えますが、今まで使っている側からすると手放しでは喜べないところもあります。ご紹介する衣袋さんや森野さんや村山さんのツイートのように、わかりづらくなってしまった部分や、できないこともあるからです。

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

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

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

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


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

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

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

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

    今は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の開発の舞台裏(苦労話)をお伝えしたいと思います。

  • QA Heatmap Analytics Our Story


    先輩達が世界から勝ち取った「MADE IN JAPAN」の称号。
    私たちもその精神を受け継ぎ、日本のソフトが世界中を驚かすことを夢みています。

    私たちの目標は、サイト運営に携わる世界中の全ての人(以下サイト運営者)に、手軽で簡単にサイト訪問者(以下ユーザー)の行動分析ができるツールを提供することです。

    ユーザーの行動分析というと、何やら難しいことをするように思われがちですが、私たちは「ユーザーとコミュニケーションを取るはじめのステップ」だと思っています。

    Webの世界は対面での接客と違い、ユーザーとコミュニケーションを簡単には取ることができません。
    「ユーザーが何を思い、何を感じているのか?」ユーザーの顔色を見ることも意見を聞くこともできません。

    日本には、相手の心情を察し気遣う「思いやり」という言葉がありますが、ユーザーのことを何もわからない状態では適切な「思いやり」ができません。ましてや、一方通行の思いやりは、大きな誤解や勘違いをも生み出します。

    そうならないためには、定期的に行動分析をし、ユーザーの意思を確認していく必要があります。

    この「QA Heatmap Analytics(キューエーヒートマップ アナリティクス)」は、まさに、ユーザーの意思をサイト運営者に届ける最良のツールです。

    そして、このツールの特筆すべき点は、「導入が驚くほど簡単だ」ということです。

    多くの場合、ユーザーの行動分析をしようとしても導入までの手順が多く、しかも専門知識まで必要なケースがありますが、これまでの常識を覆すほどの簡単さを実現しています。

    サイト運営者にプログラミングの知識が全くなくても、簡単に導入し、活用することが可能です。

    しかもツールは原則無料でご利用いただけます。

    このツールを多くの方に活用していただき、Web上に溢れるコンテンツが、常にユーザーの意思を取り入れたものになっていくことで、より便利で豊かな社会の実現につながることを確信しています。

    将来像


    このツールは、インストールするだけで、以下の分析が簡単に行えるようになります。

    • ユーザー行動のヒートマップ表示
    • ユーザーのクリック数の計測
    • 過去24時間のセッションデータの表示

    将来的には、「ユーザー行動の再現動画の再生」や「多角的な行動分析」、「テストを自動で行い、最適な答えを導き出すオートメーションツール」へと変貌を遂げるべく開発を行っています。

    これらが実現することで、まさに「MADE IN JAPAN」の称号に相応しい、世界を驚かせるツールとなるでしょう。

    ユーザー行動のヒートマップ表示(無料)(一部有償)

    ユーザー行動のヒートマップ表示については、すでに実装されていますので、こちらをご確認ください。

    過去24時間のセッションデータ(無料)

    ユーザーがどこから、どのページに訪れ、どのページで離脱したのか。滞在時間などのデータを取得し、一覧表示します。

    ユーザー行動の再現動画(無料)

    ユーザーがどこのページのどの部分をみているのか、スクロールのスピードや動きを解析し描写する機能です。
    スクロールのスピードや、上下への動きなどを見ることで、ユーザーの感情を把握しやすくなります。

    再現動画の保存期間の延長及びセグメントわけ(有償)

    上記のセッションリプレイ情報をデータベースに保存し、いつでも閲覧できるようになります。

    → 開発ロードマップ

    ポリシー


    すべての機能は以下のポリシーに従って開発されています。

    • ユーザー情報の非独占
    • 個人情報保護への対応
    • バージョンアップ

    ユーザー情報の非独占

    蓄積されるユーザー情報は、「サイト運営者の資産」であると考えています。QA Heatmap Analyticsが取得するユーザー情報は、サイト運営がなされているサーバー内に、個人が特定できない情報かつ外部から閲覧できない形で安全に保存されます。
    外部企業に干渉されることなく大切な資産を守ります。

    個人情報保護への対応

    すべての機能は、日本の個人情報保護法のガイドラインに準拠しながら実現します。ユーザーの特定につながる個人情報を保持することなく、すべての機能をご利用いただけます。

    上記の点から、不測の事態が起きQA Heatmap Analyticsのユーザー情報が第三者に流出したとしても、大切なユーザーの個人情報が流出することはありません。

    バージョンアップ

    現在もさまざまな方からいただくご意見を取り入れ頻繁にバージョンアップ行なっています。
    これからもより良いツール、より使いやすいツールへと進化していきます。

    コミュニケーション


    最後になりましたが私たち自身も、このQA Heatmap Analyticsをご利用くださるサイト運営者(以下 ご利用者)とのコミュニケーションを非常に大切にしています。そしてツールは導入して終わりではなく、ご利用者に十分な結果を出していただいてこそ意味があると考えています。

    • QAM(ユーザー会)の開催
    • フィードバックの重要視
    • サポートサイトの充実
    • 勉強会コミュニティのサポート
    • サポーター制度の導入

    QAM(ユーザー会)の開催

    不定期ですが、QAM(ユーザー会)を実施しています。より良いツールにしていくために、開発者とご利用者が直接顔を合わせ、意見交換などをおこなっています。
    → QAM(ユーザー会)

    フィードバックの重要視

    ご利用者からフィードバックしていただいた情報への対応は、できるだけ開発の優先度を高く設定し対応しています。
    フィードバックは以下より簡単におこなっていただけます。
    → フィードバック

    サポートサイトの充実

    QA Heatmap Analyticsをご利用いただきユーザー行動分析を行うなかで出てくる疑問や課題解決にお役に立てる情報を発信してまいります。
    有料版をご購入いただきました方は、サポートサイト内フォーラムよりプライベートの質問を行えます。

    ※勉強会コミュニティおよびサポーター制度は順次ご案内いたします。

  • MySQLのパーティショニングの使い方とエラー対策

    MySQL(※1)にはパーティショニング機能があります。

    これは、一つのTableで膨大なデータを管理しなければいけない時に使える手法で、論理的に1つに見えるTableを、内部的にはわけて管理(=パーティショニング)することができます。

    しかしMySQLの公式ページが一番詳しいものの、いまいち分かりづらかったり、かといって日本語でまとまった情報がなかったりしますので、構築時に困りがちです。

    例えば、パーティショニングで作成方法を間違えると下記のようなエラーがでます。
    A UNIQUE INDEX must include all columns in the table’s partitioning function

    この対処は後述しますが、そもそもパーティショニングの概念をおさえておくと早いと思いますので、ここで簡単にまとめておきます。

    ※1 正確にはOracleなど他のRDBMSにもあります。

    パーティショニングとは

    冒頭でも触れましたが、パーティショニングは膨大なデータ量を1つのTableで扱いたい時に使える手法です。

    そもそも1つのTableに数百万行といった量のデータが入る場合、ちょっと速度や容量などが怖いですよね。しかし、QA Heatmap Analyticsもそうですが、ウェブ行動データのような膨大なデータを長期間扱おうとすれば、どうしてもTableサイズは膨大になってきます。

    こういった時に、例えば毎月ごとにTable名をわけて管理することが考えられます。
    例えば202001_log、202002_log、202003_log、、といったTableをどんどん作っていくという手法です。そうすれば1つのTableサイズは小さくて済みます。

    しかし、この手法では同じ意味のTableが無駄に多数できてしまい、月またぎのSQLも難しくなってきて、管理もしづらくなってしまいます。このような時にパーティショニングが有効です。

    パーティショニングは、内部的にはTableがわかれるものの、Table名は一つです。例えば先ほどの例では以下のようになります。

    Table名:log
    ※内部パーティション
    p202001
    p202002
    p202003

    このようにすると、SQLはもちろんTable「log」に対して行えるので月またぎのSQLも今までどおりシンプルになりますし、場合によってパーティションを指定して検索することもできます。
    またDropもパーティション単位で行えますので、膨大なデータを管理する場合に検討の余地のある方法になります。

    パーティショニングの使い道。メリットとデメリット

    パーティショニングのメリットは、前出のように膨大なデータを管理する場合に管理がしやすくなることです。具体的には下記のメリットがあります。

    • パーティション単位でデータを移行する、Dropするなどの操作が簡単にできる
    • 内部的には分かれているものの、1つのTableとして扱えるのでSQLはいままで通り使える
    • データが小分けに管理されるので、それを意識したクエリであれば速度が早くなる

    デメリット

    一方で、デメリットとして

    • 内部的にデータがわかれてしまうので、クエリによっては速度が遅くなる
    • 後からTable構造を変更しようとすると大変なので、初期設計が重要となる
    • クエリーキャッシュがサポートされないなど、いくつかの制約がでる
    • パーティショニングに対して慣れていないプログラマに啓蒙が必要となる
    • パーティション全体を通してユニークなキーは作成することができない

    総じて、やはり管理ルールが変わりますから、今までとまったく一緒というわけにはいきません。ですから、やはり膨大なデータを扱いたいときに採用を検討すると良いと思います。

    制約については公式ページが詳しいです。
    https://dev.mysql.com/doc/refman/5.6/ja/partitioning-limitations.html

    パーティショニングの作成方法

    パーティショニングの作り方は、CREATE TABLE時にやる方法と、後からALTER TABLEでやる方法の二種類があります。

    具体的なクエリは後述しますが、例えばlogファイルで行う場合は、月ごとにわけることが一般的で、コツとしては最初から一気に未来日付分まで作ってしまう方がよいです。
    例えば2038年くらいまで作っておけば、あとはMySQLがデータインサート時に勝手に振り分けてくれるので、しばらく日付判定なども不要で楽です。

    パーティショニングとユニークキーについて

    これが最も大切な考え方です。

    仮に下記のようなTableがあったとします。

    CREATE TABLE ids_log (
        uid INT AUTO_INCREMENT,
        another_id INT UNIQUE NOT NULL,
        insert_time DATETIME NOT NULL
    )

    another_idがユニークになっています。

    このようなTableで、仮にinsert_timeで判定し、各月ごとにパーティションを作ったとします。この状況で問題となる例をあげます。

    まず最初に2020年1月にanother_id = 5の人をINSERTしたとします。
    その3ヶ月後に、今度はanother_id = 5 の人に重複INSERTがあったとします。

    重複と簡単にいいましたが、実はここがパーティショニングのデメリットとなる部分です。結論からいうと、パーティショニングを使う場合「another_idという単一カラムのみで重複を判断することはできません。つまりanother_id = 5を全パーティションをまたいでユニークにはできません。

    その理由ですが、そもそもMySQLのパーティショニングとは、各パーティションごとにTable(インデックス付き)が作成されるようなイメージです。そうするとanother_id = 5というデータだけを挿入する場合、どのパーティションに入れてよいかわからないと思います。従って、another_id = 5は、必ず日時(insert_time)とセットで挿入の指示が必要です。

    この現象をMySQL側からみると、ユニークなのは「another_idと日時(insert_time)の複合の組み合わせ」ということになります。逆にいえばanother_id=5だけではユニークではありませんし、ユニークにすることができません。従って、パーティショニング時にユニークキーを使う場合は、必ず複合キー、今回でいえば日時(insert_time)と組み合わせないといけないのです。

    別の言い方をすると、「パーティションでユニークを使いたいなら、必ず、あるカラムとパーティションで使うカラムとの複合インデックス(複合キー)を作らないといけない。」ということになります。

    パーティションを作成する時にエラーが出ることがありますが、その殆どがこの問題です。

    そもそもユニークキー、プライマリーキー(主キー)、インデックスって?

    念のため、ユニークキーやインデックスなどについてもここで簡単に整理しておきますね。

    そもそもMySQLなどのRDBMSではカラムにいろいろな属性などをつけれますが、大雑把に以下にわかれます。

    • インサート時に簡単に判断できる条件・・・NOT NULL、CURRENT TIMESTAMPなど
    • そもそも索引(インデックス)がないとMySQL側で判断が付かない条件・・・UNIQUE(固有性)
    • 検索に便利な管理手法・・・INDEX(索引)。キーとも言われる。

    並列ではなく、後者2つが特別なんですよね。

    まずユニークは、重複を許さないということです。
    ここで重要なのは、重複を許さないということは、MySQLは自動的に索引(インデックス)を作る必要があるということです。
    そうでなければ、毎回、全件検索しなくてはいけなりません。
    ということで、ユニークキーを作るとは、ユニークを担保するためにキー=インデックスが自動で作成される、という意味です。

    プライマリーキーは、ユニークキーの特殊形態です。
    Nullを許可しないこと、および各Tableで1つしか作れないこと以外はユニークキーと一緒なので、ユニークキーの一種だと思って問題ないでしょう。

    最後にインデックスは、上記でも書きましたが「索引を作る」ことです。
    索引を作ると、クエリで意識すれば当然検索が早くなりますし、必要なデータだけとってくるので、メモリの使用量も抑えやすくなります。
    ユニークキー(主キー含む)を作れば、自動でインデックスが作成されます。もちろん手動でINDEXを作ることもできます。

    詳しくはこのあたりが参考になると思います。

    https://www.it-swarm.dev/ja/mysql/mysql%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%82%AD%E3%83%BC%E3%80%81%E4%B8%BB%E3%82%AD%E3%83%BC%E3%80%81%E3%83%A6%E3%83%8B%E3%83%BC%E3%82%AF%E3%82%AD%E3%83%BC%E3%80%81%E3%82%A4%E3%83%B3%E3%83%87%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E9%81%95%E3%81%84/971121099/

    複合キーって?

    複合キー = 複合インデックス。つまり、二つ以上(複合)のカラムを結合して索引を作ることです。

    パーティショニングでは、この複合キーをうまく使う必要があります。

    例えば、社員番号と入社日のTableがあったとします。
    ここで例えば入社日でパーティションをわけた場合、いつものように社員番号だけにユニーク属性をつけることはできません。
    なぜなら、社員番号だけにユニーク属性をつけると、索引が自動で作成されますが、それだけだと、どのパーティションにその社員番号が格納されているかわからなくなるからです。

    これを解決するために、社員番号と入社日をあわせて複合キーを作る必要があります。そうすれば総合的なインデックスが作成されるので、MySQLとしても社員番号を指定された時に、どのパーティションに格納されているか、また重複があるかどうか瞬時にわかるからです。

    パーティションとインデックスは関係ない?

    はい。インデックスは関係ないです。

    インデックスただの索引ですし、もちろん重複もOK(管理しない)です。ですからパーティションにかかわらず自由につけることができますし、複合にする必要もありません。
    そこは勘違いしないようにしましょう。

    パーティションの最大数は8192

    MySQL 5.6.7 以降は、最大8192 パーティションまで作成できます。

    CREATE PARTITIONの例

    create table table
    (
        id int auto_increment,
        aid varchar(28) not null,
        primary key (id, update_date),
      hizuke date not null,
      unique key (aid, update_date)
    )
    partition by range COLUMNS(hizuke) (
      partition  p202001 values less than ('2020-01-01 00:00:00'),
      partition  p202002 values less than ('2020-02-01 00:00:00'),
    );

    hizukeで判断するパーティションを後半につけてコミットします。
    ユニークが必要な箇所はすべてhizukeと複合キーにします。
    前出のようにインデックスはパーティションと無関係なので、Table作成後に自由につけることができます。

    ALTER PARTITIONの例

    alter table table partition by range COLUMNS(hizuke) (
      partition  p202001 values less than ('2020-01-01 00:00:00'),
      partition  p202002 values less than ('2020-02-01 00:00:00'),
    );

    ALTERの場合もCREATEの時とほとんど構文は変わりません。

    A UNIQUE INDEX must include all columns in the table’s partitioning functionへの対処

    前出しましたが、ユニークキーはパーティションではとても重要です。
    全てのユニークキーは、パーティション全体でユニークになるよう複合キーにしなくてはいけません。

    例えば下記のようなTableでinsert_timeを判断してパーティションを作るとします。

    CREATE TABLE ids_log (
        uid INT AUTO_INCREMENT,
        another_id INT UNIQUE NOT NULL,
        syain_id INT UNIQUE NOT NULL,
        insert_time DATETIME NOT NULL
    )

    上記では、uid(auto_incre,ent),another_id、syain_idの3つは全てユニークになっています。
    この時、必ず下記3つの複合キーを作る必要がある(作らないと、パーティションをまたがったユニークが担保できないから)ということになります。

    UNIQUE KEY (uid, insert_time),
    UNIQUE KEY (another_id, insert_time),
    UNIQUE KEY (syain_id, insert_time)

    パーティショニングの速度アップのコツ

    パーティションへのクエリを速くするには、当然、分かれている単位でクエリを出すのが得策です。
    例えば、毎月のパーティションを作ったならば、その一ヶ月で収まるような範囲でクエリを投げれば、速くなることは想像しやすいですよね。
    これはパーティションプルーニングと言われています。

    https://dev.mysql.com/doc/refman/5.6/ja/partitioning-pruning.html

    また、インデックスの仕組みを考えれば、DBにとっては索引で収まる範囲でのクエリを投げてもらうと、いち早く目的のデータを探し出し、オンメモリすることができます。
    この時はメモリ使用量も全件検索と比べてはるかに小さくなりますから、サーバー側でSwapが発生する確率も低くなり、パフォーマンスを維持しやすくなります。

    そう考えると変にSQLのWHERE句で細かく指定をして全件検索をさせるより、インデックスをうまく使って一部をメモリにとってきて、あとはプログラム側で配列処理した方が速くなることも多いです。
    そのような考え方で運用するようにすると、うまく活用できると思います。

    まとめ

    以上、パーティショニングについてまとめてみました。
    うまく使えば膨大なテーブルの管理がしやすくなるのでおすすめです。

    最後に、パーティショニングは公式ページが一番詳しいので、参考URLを貼っておきます。

    https://dev.mysql.com/doc/refman/5.6/ja/partitioning.html

  • PhpStormでXdebugのリモートデバッグを設定したがwaiting for incoming connection with ide keyのまま動かない場合の対処

    今日は雑記のような内容なのですが開発者ブログということで大目にみてもらって。

    現在はテレワークの問題もあり、自宅で作業している人も増えていると思います。そこでタイトルのままなのですが、下手にググってはまったので対処をメモしておきます。きっとこれでほとんどの人が解決するのではないかと思います。

    サーバーとPC間の通信の問題

    リモートのXdebugの設定もちゃんとしてあって、Validateも通っているのにwaiting for incoming connection with ide keyが出てうまくデバッグが動いてくれないならば、たぶん、あなたのPCとサーバー間通信の問題です。

    どこかで通信が断絶しています。でもwating…というメッセージをみて、たぶんそれは予測されていますよね。

    まずこちらの親切なサイトで、Xdebugのremote debugはサーバーからもあなたのPCに直接アクセスしてコネクションをはる必要があるということを押さえましょう。

    多くの人の環境で直接通信は不可能

    当然、プロバイダとの契約次第になりますが、多くの人のPC環境では外部からグローバルIPで直接ポートをあけるなんて設定はしていないはずです。従って、そもそもXdebugのリモートデバッグ設定は無理です。

    しかし、そのための対処としてsshトンネルという手法が使えます。

    sshトンネル(ポートフォワード)を使う

    sshトンネル(ポートフォワード)とは、サーバーと自宅PCを通常通信ができるssh(port22)でつなぎ、通信確立後、ローカルPC、サーバー共に任意のポートに転送する仕組みです。こうすることで、途中のルーターやファイアーウォールに邪魔されずにデバッグ通信が可能になります。

    ローカルのPCに仮想環境を構築せず、AWSやさくらVPSなどで検証サーバーを構築し、リモートデバッグしたい方は、どうしてもプロバイダ経由のインターネット通信を挟みますから、ほぼこのsshトンネルを使うことになると思います。

    sshトンネルの設定方法

    詳しい設定方法は下記PhpStormの公式サイトに記載があります。

    SSHトンネル経由のリモートデバッグ

    macの場合はターミナルで実行します。

    ssh -R 127.0.0.1:9000:127.0.0.1:9000 user@example.com

    上記コマンドを実行すると、example.comにssh接続され、パスワードを要求されます(パスワード認証の場合)。一旦接続が確立されればトンネルが完成します。

    上記コードの意味は、サーバー(example.com)のlocalhost:9000番ポートをローカルPCのlocalhost:9000番ポートに割り当てる(フォワード:転送する)という意味です。2つのポートがssh通信を介してリンクする(同一になる)ようなイメージです。

    -RはリモートのRで、下記のようにも書けます。

    ssh user@example.com -R localhost:9000:localhost:9000

    -Rの後ろは一緒で <サーバーIP>:<転送ポート>:<ローカルIP>:<受信ポート>という構成です。こっちの方がわかりやすいかも知れません。

    ポートフォワードについて、詳しくはこの方の記事がわかりやすいと思います。
    SSHポートフォワード(SSHトンネル)【ローカル・リモート・ダイナミック総集編】

    サーバー側で xdebug.remote_host = localhost などを設定

    sshトンネルを設定したら、サーバー側の/etc/php.d/15-xdebug.iniファイル内で下記を設定します。(コンフィグファイルは違う場合もあります)

    xdebug.remote_enable=1
    xdebug.remote_autostart=1
    xdebug.remote_host=localhost
    xdebug.remote_port=9000

    上記により、サーバー側にアクセスがあるとデバッグセッションが始まります。その時サーバーはlocalhost(自分)の9000番ポートに接続します。そうすると、sshトンネルを介してあなたのPCの9000番ポートにそのまま情報が届きます。

    PhpStormが正しく設定されていれば、その9000番ポートを待ち受けているはずですので、デバッグセッションが正しく開始されると思います。

    それでもダメならファイアウォールなどを疑いましょう。有名な通信パケット閲覧ソフトであるWIRE SHARKを使えば、どんな通信が届いているのか確認できますので、トラブルシューティングに役立つと思います。

    以上、今日は細かい話ですが、共有でした。