まだプログラマーですが何か？

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ：console

マンホールマップを Google の Search Console に登録して、どんなキーワードで検索された結果としてマンホールマップが使われているのか？　を解析してみました。

使ったサービスはこれです：
Google Search Console

2016122700



ここにログインし、「検索アナリティクス」メニューから対象期間を選びます。また「クエリ」を選択して、検索キーワードごとに統計を出せるようにしました：
2016122705


ここで得られる結果はこのままだと取り扱いが難しいので CSV 形式でダウンロードしました：
2016122706



これで UTF-8 で書かれたクエリーごとの検索データを CSV で取得することができました。このファイル名を searchs.csv とします。

CSV のままだと取り扱いが不便なので、MySQL データベースに入れちゃいましょう。適当な（笑）MySQL データベースに、こんなスキーマのテーブルを作りました（CSV が UTF-8 なので、テーブルも UTF-8 指定しています）：
mysql> create table searchs( id int primary key auto_increment, query varchar(100), clicks int, shows int, ctr float, rank float ) default character set utf8;

mysql> desc searchs
+--------+--------------+------+-----+---------+----------------+
| Field  | Type         | Null | Key | Default | Extra          |
+--------+--------------+------+-----+---------+----------------+
| id     | int(11)      | NO   | PRI | NULL    | auto_increment |
| query  | varchar(100) | YES  |     | NULL    |                |←クエリー
| clicks | int(11)      | YES  |     | NULL    |                |←検索結果からクリックされた回数
| shows  | int(11)      | YES  |     | NULL    |                |←検索結果に表示された回数
| ctr    | float        | YES  |     | NULL    |                |←クリック率
| rank   | float        | YES  |     | NULL    |                |←平均掲載順位
+--------+--------------+------+-----+---------+----------------+

先程の CSV をロードします：
mysql> load data local infile 'searchs.csv' into table searchs fields terminated by ',' (query,clicks,shows,ctr,rank);

これでサーチコンソールから取得した情報が MySQL データベースに入りました。こうなると色々楽ちんです。とりあえず phpMyAdmin あたりを使って、項目ごとに上位クエリーを調べてみましょう。

まずは検索表示回数。要は「マンホールマップが検索結果に表示された時、どのキーワードで検索されていたことが多いか？」です：
2016122702


ある意味想定通りですが、圧倒的一位は「マンホール」でした。マンホールマップを知らない人も含めた多くの人が「マンホール」を検索した結果だと思います。２位が「マンホールマップ」、知名度上がってると解釈していいでしょうか。３位は「豊井 スライド」（間にスペース）でした。これは何？？ここからクリックされた形跡はなさそうだけど・・・いきなり深い謎に出会ってしまいました。。

面白いですね。では次はクリック回数。つまり検索結果に表示された回数ではなく、「検索結果に表示され、かつクリックしてマンホールマップに移動した回数」順です：
2016122701


これは「マンホールマップ」で検索した結果、マンホールマップに多く誘導できている、という当然の結果でした。そして「マンホール」で検索した人が「マンホールマップ」にたどり着いている、というパターンが２位でした。これも理想的で、いい結果です。その他地名との組み合わせで検索した結果が多くなっています。驚いたのは「さめがめ」で検索してマンホールマップにたどり着いた人がこの３ヶ月で３人いらっしゃったんですね。。。


次はクリック率（CTR=Click Through Ratio）、検索結果として表示されたうちの何％がクリックされたか、という数字です：
2016122703


いくつか 100% の例もありますが、嬉しいのは「マンホールマップ」で検索した人の 80%、「マンホール マップ」で検索した人の 60% が実際にクリックして訪れている、という結果です。マンホールファンはいい人が多いです（笑）。


最後に平均掲載順位。これは「検索結果の何番目にマンホールマップが表示されたか」の数字で小さいほど目立つ位置に表示されていることになります。そして 10 以下であれば検索結果の１ページ目に表示されていることになりますが・・・
2016122704


実はこの見方が僕もまだよく分かってなくて、例えば上記結果だけを見ると「ゆるキャラ」という検索結果に12回登場していて、その平均順位は 4.7 位（つまり最初のページに出ている）と読み取れます。マンホールマップがそんなに高い位置にいていいんだっけ？さすがにちょっと高すぎるような・・・

おそらくなんですが、実は検索時に "site:*****" とかの特殊なパラメータが付与された上での検索結果ではないかと想像しています。ただこの結果にそこまでの情報はないので、まあそのまま判断するしかないのかな、と。


ちなみにマンホールマップ全体としての平均 CTR は 8.07%、平均掲載順位は 14.3 でした。マニア向けのニッチな情報サイトから、より一般的なコミュニティサイトとして認知されるにはもう少し掲載順位を上げたい所ではあります。


こういう話は DeNA が詳しいのかな（苦笑）。

タグ ：
#google
#search
#console
#manholemap
#ctr

IBM Bluemix 上の Node.js ランタイムアプリを効率的にデバッグしたり、コンソール画面にアクセスする方法を紹介します。

まずは Bluemix 上にデバッグ＆コンソールアクセスの対象とする Node.js のランタイムアプリケーションを作成します：
2016042401


ここではアプリ名を dotnsf-nodejs-debug と設定したと仮定して以下を続けます。実際の名前に置き換えて読み替えてください：
2016042402


Bluemix 上のランタイムアプリをデバッグおよびコンソールアクセスするには、このランタイムの環境変数を設定します。ユーザー定義環境変数を１つ追加します：
2016042403


環境変数名は BLUEMIX_APP_MGMT_ENABLE 、その値に devconsole+shell+inspector を指定して保存します。ちなみに devconsole を追加することで（この後にアクセスする）管理用ポータル画面が有効になります。そこから呼ぶためのシェル(shell)とデバッガ（inspector）の両方を有効に指定しています。シェルだけが必要であれば inspector は指定しなくても構いません：
2016042404


そしてランタイムを再ステージングすると、管理ポータルが有効になります：
2016042405

管理ポータルにアクセスする前に一度アプリケーションの挙動を確認しておきます。ランタイムが稼働中であることを確認し、また少し多めにメモリを割り振っておきます（図では 512MB）。そしてランタイムの URL にアクセスします：
2016042507


Node.js の標準ランタイムでは "Hi there" というメッセージが単純に表示されます。これが初期状態の画面ということを確認しておきましょう（後で直接書きなおして変更します）：
2016042407



再ステージング完了後、ブラウザで以下の URL にアクセスします：
（元のランタイムの URL）/bluemix-debug/manage/


Basic 認証のダイアログが表示されるので、自分の Bluemix ID とパスワードを指定します：
2016042501


正しく認証が行われると、管理ポータルの画面が表示されます。ここからシェルやデバッガーにアクセスできます。では最初にシェルにアクセスしてみましょう。"Open Shell" と書かれたボタンをクリックします：
2016042502


すると新しいタブが開き、bash が起動したシェルが動いているはずです（動いていない場合は "+NEW WINDOW" と書かれたボタンをクリックして開きます）：
2016042503


この画面は bash のシェル画面なので普通に標準コマンドが動きます。例えば "ls" 入力すると、カレントディレクトリのファイル一覧が表示されます：
2016042504


では試しにこの場でファイルを編集してみましょう。コマンドラインで以下のように指定して、vi で public/index.html ファイルを開きます：
$ vi public/index.html


vi 内で適当にファイルを編集して保存します。以下の例では "Hi there" と書かれていた部分を "Hello there" に書き換えています：
2016042505


こうして改めてランタイムにアクセスすると、画面内の表示が書き換わっていることが分かります。再デプロイや再ステージングなしにファイルを書き換えることができました：
2016042506


もう１つのデバッガの方も試してみましょう（こちらは FireFox ではなく Chrome 限定で使える機能です）。Chrome ブラウザで管理ポータルを開き、"Open Debugger" と書かれたボタン部分をクリックします：
2016042501

するとデバッガっぽい画面が表示されます。ここで JavaScript にブレークポイントを指定したり、変数の値を確認したりすることができるようになります：
2016042502


ブレークポイント設定は JavaScript コードの一部をマウスでクリックします。これでブレークポイントが設定できました：
2016042503


開発ポータルの画面で、該当アプリをサスペンドします：
2016042505


サスペンド後にデバッグ画面を見るとデバッグモードになっています。下図赤枠の部分をクリックして、デバッグモードで起動します：
2016042506


すると指定したブレークポイントまで実行されてコードが止まります。画面右ペインを見ると、この時点での変数とその値が一覧で表示されているはずです。この例では appEnv 変数を取得する行にブレークポイントを設置しているので、止まったこの時点ではまだ appEnv 変数は undefined と表示されています。下図赤枠部分（さっきの隣のボタン）をクリックして、一行だけ実行してみましょう：
2016042507


一行先に進み、appEnv 変数が設定され、その中身を確認することができるようになりました：
2016042508



以上、簡単にですが、Bluemix 上の Node.js ランタイムでシェルコンソールを使ったり、デバッガを使ったりする方法を紹介しました。詳しくはこちらのドキュメントも参照ください：
https://console.ng.bluemix.net/docs/manageapps/app_mng.html#app_management


タグ ：
#ibm
#bluemix
#node.js
#debug
#console

このページのトップヘ