PageAnalyticsでページごとにどこへ遷移してるかチェック
サイト内でどのページからどのページへ遷移したか、アナリティクスで出すこともできるのですが、ブラウザのページ上で確認できる「PageAnalytics」という拡張機能があります。
若干のクセがあって使えるシーンは若干選びますが、使いどころのあるツールです。
PageAnalyticsでできること
PageAnalyticsのインストールはこちらから。
インストール後、PageAnalyticsのアイコンをクリックしてONにするとリンクごとに数値が出ます。
上部にPVなどの数値が出てきて、ページ内にはオレンジの枠で各リンクごとに何％という数値が出てきます。
画像の数値で言うと
- サイトタイトル：6.0％
- パンくずの「トップ」：6.0％
- 記事タイトル：75％
となっています。
ここで注意点が、サイトタイトルとパンくずのトップが同じ数値ですがそれぞれが6％クリックされているわけではないです。
このリンク先はどちらもブログトップページです。
このようにリンク先のURLが同じ場合に数値がまとめられてしまうのでページ内にあるブログトップページへのリンクどれかの合計で6％クリックされているということです。
これはGAのデータを参照しているので仕様上、仕方ないと思います。
どうにか解決したい場合は、各URLにパラメータを付けてURLを変えるとかになりそうですが、手間がかかるしGA上でのデータもそれぞれ集計が変わるので微妙かなと思います。
ページ内に同じリンクが複数ある場合は、どれがクリックされているのかは計測できないためいくつも同じリンクがある場合は％が大きく見える可能性があります。
誘導したいページに向けてリンクをいくつか入れている場合は、合計でどのくらい遷移しているか確認するような使い方をするのがいいと思います。
もちろん、1つしか入ってないリンクについてはそのまま参照できるので便利に使えます。
外部リンクのデータは表示されない
検証してみたんですが、外部リンクのデータは表示されないようです。
デフォルトでは外部サイトへの遷移データは取得できないので、イベントトラッキングを設定して計測しましたが数値は表示されませんでした。
イベントトラッキングのデータとPageAnalyticsのデータは別物みたいです。
まとめ
％で表示されるので具体的に何回遷移されてるかパッと見で分からないのですが、誘導したページへ少しでも遷移しているのか、どんなリンクがクリックされてるのかをざっとチェックするために使えるツールです。
リンク1つしかないと思ってたら関連記事にリンクがあったとかで気づかない場合もあるのでちょっとクセがありますが、感覚的に把握するためにビジュアルでチェックできるので気になる方は使ってみてください。
リダイレクトチェックは拡張機能「Redirect Path」で一発
ＵＲＬ変更や重複ページ、最近だとSSL化とかでリダイレクトした際に正しいリダイレクトがなされているかチェックするなら「Redirect Path」がかなり楽なのでおすすめです。
一部注意が必要な点があるので併せて紹介します。
リダイレクト前のURLにアクセスするだけ
リダイレクトのステータスコードをチェックするには、「リダイレクト前」のURLにアクセスしてください。
もちろん、リダイレクト後のURLが表示されるのでそしたらウィンドウ右上のRedirect Pathをチェックします。
すると、ステータスコードが表示されているので想定しているコードが表示されていればOKで、違っていれば修正します。
これで、301で設定したかったのに302になってたー！とかの事態に気づくことができます。
通常ならDeveloper Tool開いて〜みたいなことをしなければいけないのでこれはかなり楽です。
SSL化時のリダイレクトで違うコードが表示される
サイトによりますが、httpからhttpsへんリダイレクトでは、「301」にしたはずが「307」と表示されることがあります。
これは、HSTSを設定しているとブラウザがリダイレクトするために表示されるもの
らしいのですがよくわかってないので以下の記事を見てください！！！（）
https://webtan.impress.co.jp/e/2016/01/08/21883/page/1
※「307リダイレクトって何？ サーバーでは301を設定してるのに？」の箇所
結論としては、問題ないよ！とのことです。
404もチェックできる
404ページで実は404が返ってない、みたいなこともないわけではありません。
というか、実際にありました。（そのときは、Redirect Path使ってませんでしたが）
404ページ風に作られてはいるけど、ステータスコードが200だった…という場合にこれで気付けます。
まとめ
301と302で間違えたから大問題が起きるわけではないですが、恒久的な対応と一時的な対応で意味が異なるので設定したい方法と間違いないかは一応チェックしてます。
307については、別のステータスコードチェックツールとかで確認すると301で返ってきます。
念のため確認したい方は、以下のツールなどでチェックしてみるといいと思います。
HTTPステータスコードチェッカー｜複数URL一括検索&転送経路調査もOK
Redirect Pathのインストールはこちら
複数のURLを一気に開けるChrome拡張機能の「Pasty」
スプレッドシートなどにリスト化されたURLを開いてはチェック、開いてはチェックという作業をせずにエイヤ！で一括で開ける「Pasty」という拡張機能があります。
リストから一気にコピーしてポチッとするだけで各URLのページがタブで開くので複数URLをチェックする際の便利機能です。
開きたいURLをまとめてコピーして使う
Pastyをインストールしたら、開きたいURLをまとめてコピー（Ctrl+CやCommand+C）してください。
コピーできたらウィンドウの右上からPastyのアイコンをポチッ。
するとタブが一気にずらーっと開きます。
当然ですが、（Pastyの問題ではなく）一度に開きすぎると動作が重くなるのでPCのスペックによっては開きすぎないようにしたほうがいいです。
これでスプレッドシートを行ったり来たりしなくてすみます。
ちなみに1つのセルに複数のURLを記載していても大丈夫です。
もちろん、スプレッドシート以外でも使えるのでチャットなどでURLをまとめて渡された際にも使えます。
URL以外は無視してくれる
間にテキストだけのセルがある場合、まとめてコピーしてもURLだけを認識して開いてくれます。
5つのセルをまとめてコピーしても3つしかタブは開きません。
テキストリンクも無視されてしまう
これは若干残念ですが、テキストにリンクを挿入しておいても無視されるので開きません。
URLが表示されていることが条件になるのでここは少し注意が必要です。
まとめ
2、3個のURLなら1つずつ開いても手間ではないと思いますが多くなると面倒ですし、特にスプレッドシートだと1クリックで開かないのでPastyがあると便利です。
参考サイトの候補や修正したいページやらで確認してください〜って、まとめてドバッとURL渡されたときがあったら使ってみてください。
拡張機能「image size info」ならブラウザ上の画像サイズ確認が簡単
記事に挿入した画像サイズが気になったことってありませんか？
入稿を他の人にお願いしていたり、ページが重くて画像が大きくないか確認したいときなんかに「image size info」という拡張機能が便利です。
確認したい画像を2クリックで画像サイズ（px）とファイルサイズ（GB、KBとか）が、わかるので簡単にチェックできます。
画像を右クリックしてサイズチェック
「image size info」をインストールしたら、チェックしたい画像を右クリックすると「View Info」という項目が追加されています。
この「View Info」をクリックすると画像の情報が表示されます。
クリックするとポップアップが出てきます。
表示される情報は4つ。
- 画像のURL
- Dimensions：実際の画像サイズ
- Displayed：表示されている画像サイズ
- File Size：ファイルサイズ（容量）
「Dimensions」を見ればサイズが大きい画像をアップしていないか、「File Size」を見れば重い画像を上げてないか確認できます。 これをチェックして修正が必要なら画像URLをコピって修正内容と一緒に伝えればOKです！
たとえば、Dimensions：3000とかになっていたら単純に縮小し忘れだと思うので
https://expanle.com/image/hogehoge
この画像がサイズ大きいままなのでリサイズお願いしますー
みたいなことを伝えます。
また、Dimensionsは大丈夫そうだけどFile Size：2Mとかでやけに重いファイルだったら、リサイズ時にdpiの変更忘れとかだと思うので
https://expanle.com/image/hogehoge
この画像、リサイズするときに解像度変えましたー？
と伝える感じです。
伝え方は、「どこどこの見出しの最初のやつが～」とかでもいいと思いますが、URLと一緒に修正内容を渡せば細かいことを書かなくていいですし、画像の間違いもなくなるのでいいと思います。
（URLと一緒に渡せばいいのは、このブログを書きながら気づきましたｗ）
こんな感じに2クリックでさくっとチェックして修正依頼なり自分で直すなりできるので、これを使ってからとても楽になったし、ミスにも気づきやすくなったので愛用してます。
画像が引きのばされててるときにも活躍する
これは結構まれですが、diplayedよりdimensonsのサイズが小さいときにも役立ちます。
画像が荒くなってて変だな？って思ったらcssで横幅600pxになるように指定されているのに横幅600px以下の画像をアップしちゃってたとかです。
大体このパターンは、縦長の画像だったから縦が大きくなりすぎないように縦を基準にリサイズしているときです。
これは、
- cssを変更する
- 画像の横に余白を入れて余白部分を透過してしまう
- 縦が長くなるのは諦めて横に合わせる
- 別の画像を使う…
みたいな調整を行うことになると思います。
displyedは使わなそうと最初は思ってたのですが、ふとした場面で活躍してくれます。
まとめ
これを見つけたときは、画像に関するミスがちょこちょこと発生することがあったので、この拡張機能入れてからはとても助かりました。
これを見つける前は一個一個チェックするのは大変だったので、読み込みが遅い画像があることに気づいたときくらいでした。
リサイズ前の画像を間違えてアップしちゃってても、ざっとチェックしてミスがあれば修正のお願いをしていました。
最近では使う頻度は減りましたが、今でも便利だなと感じています。
画像のサイズチェックとかをすることが少しでもあるなら「image size info」を試しに入れておくのをオススメしたいです！
エディターをATOMからVSCODEに変更して拡張機能「テキスト校正くん」でブログを書いてみた
自分で書いた文章ってチェックしても誤字脱字や表記ミスなどに気付きにくくはないですか？
以前、ある程度ツールで判断したくて、校正ツールを試したこともあったのですがいいものを見つけられませんでした。
ところが、最近知った、VSCODEで使える拡張機能「テキスト校正くん」が気になったのでこの記事を書きながら試してみました。
アラートの内容も適切な印象で、インストールから実際の使い方も簡単でしたのでおすすめです。
ATOMからVSCODEに変更するキッカケ
これまでエディターは、ATOMを使ってたのですがVSCODE（Visual Studio CODE）も良さそうだなと思っていました。
とは言え、日々コードを書いてるわけではない自分にとっては、わざわざ変更するほどのメリットはないので興味本位で触ってみようかどうしようか程度でした。
そんな中、TwitterでVSCODEに「テキスト校正くん」という拡張機能があることを知って変えようと決めました。
（そのツイートは見失いました）
ICS MEDIAさんが作成された拡張機能です。
使い方とかの細かいことは、こちらの記事を参照してください。
Adobe XD用もリリースされていたのでXDを使用している方はこちらもチェックしてみてください。
ics.media
校正ツールにも色々ありますが、無料のものはあんまり役に立たなかったりもするし、有料のものを使うほど文章も書かないので悩ましいと思っていました。
そんな自分にとっては、テキスト校正くんは無料で使えてしかもエディターの中で使えるのでコードを書くときも文章を書くときもエディター1つあればOKというのはメリットでした。
さらに、リアルタイムで校正してもらえる点もかなり便利なのでは？と思い、早速このブログをVSCODE上で書いています。
VSCODEとテキスト校正くんのインストール方法
まずは、VSCODEをインストールが必要になります。
Visual Studio Code - Code Editing. Redefined
こちらからダウンロードできます。
インストールは基本的にそのまま進めていけば大丈夫です。
気になる方はVSCODEの詳しいインストール方法や設定について、こちらの記事を参考にしてください。
続いてテキスト校正くんのインストールです。
VSCODEを開いて左のナビから上の画像の赤丸部分をクリックしてください。
入力欄に「テキスト校正くん」と入れると入力欄の下に拡張機能が現れるのでインストールボタンをクリックすると「インストールしています」に変わるので完了するまで待ってください。
文字が消えて歯車マークが出てきたらインストール完了です。
これでテキスト校正くんが使用できるようになりました。
テキスト校正くんをテスト使用
そもそもテストの前に早速怒られましたｗ
すぐ直しました。
～テスト文～
敢えて、難しい漢字を使用してみます。
テキスト校正くんは検知されるか教えて下さい。
何故かすぐには、校正されません。
ご飯を食べれる。は、どうなんでしょうか。
ちょっと遅れて校正されるみたいです。
Javascript
Jabascript
Github
口調の混在はどうか。
私はテストしているのだ。
訂正してくれないのと困るのである。
赤線がつきました。
エラー文はこんな感じです。
～修正後～
敢えて、難しい漢字を使用してみます。
テキスト校正くんは検知されるか教えてください。
なぜかすぐには、校正されません。
ご飯を食べられる。は、どうなんでしょうか。
ちょっと遅れて校正されるみたいです。
Javascript
Jabascript
GitHub
口調の混在はどうか。
私はテストしているのだ。
訂正してくれないのと困るのである。
判定は条件があるみたいだけどチェック内容はいい感じ
テストしてみた感じは、ですます調とである調の混在の判定は難しそうですね。
って打ってたら出てきました。
前だけでなく、前後両方を加味して判定してくれる感じなのでしょうか？
「Javascript」→「JavaScript」のような表記統一は一定の条件があるのかGitHubでは出だけどJSは判定が出ないという結果でした。
と思ったら上の文章でチェックされました。
やはり一定条件があるようで「Javascript」「JavaScript」の両方があると正しい表記に統一するよう判定されるようです。
あとは、「敢えて」はチェックしてほしかったところですが、全体としては悪くない感じはして満足です。
無暗にチェックを入れるわけではなく、一定条件下で校正されため邪魔になりにくい仕様という感じがして良好です。
上記テスト以外にも書いていて校正されて実際になかなか便利です。
一文で2回同じ助詞が使われてるとかの判定もされるので「～で～で～で」のように冗長な文章になることも防げそうでした。
（判定される文章をあえて書いてるので今VSCODE上は赤線でいっぱい…）
テキスト校正くんを使う上での注意点
使用していて注意したいところがありました。
- txtファイルで保存が必要
- <br>とかを使うと対になるものがないと言われる
文章を書きながらpタグなどを入れたりするのでHTMLファイルとして保存したらエラー文が消えてしまいました。
文章校正用のツールなのでtxtファイル以外には反応しないようになっているみたいです。
たしかに、ほかのファイルにまで反映されると邪魔になることもありそうなので当然なのかもしれません。
また、brなどの閉じタグのないものを入れてしまいと対になるものがないよ！と永遠言われ続けるのでエラー文が大量になります。
無視すればいいのですが、邪魔になって大事なエラー文を見落としてしまいそうなので文章を書くときは文章だけを書く、と割り切ってしまった方が良さそうです。
まとめ
ひとまずこのまま使い続けてみようと思います。
そして、VSCODEも使いやすいように環境整えていかねばですね。
何を入れるのがいいのかまだ全然調べてないのんで、とりあえず定番やおすすめを探してみてガシガシ使ってみます。
もし何かおすすめの拡張機能などがあれば教えてくださいm(__)m
週1ブログ更新するslackに参加してみて
9月から週1でブログを書くというルールのslackグループに参加しました。
参加したグループについてはこちら
ブログ書こうと思いながら、そのうち～そのうち～って全然やらなかった自分ですが、Twitterで「こういうの需要ある？」っていうつぶやきを見つけて、本当に作られたら参加しよう！って思ってたら結構すぐに作られていて（行動力がすげぇ）そのままの勢いで参加しました。
slack使い慣れてなくてどうやって参加するん…ってググりつつ、なんとか心折れずに参加できましたｗ
たぶん、結構早い段階で参加できたと思う。
1週目から早速書けなかったｗ
このブログも参加したことをきっかけに用意したのですが、ネタも思いつかず。
とりあえずやってみようと思ってたことを実践しながら書いてみたのですが思ったより時間かかって0時になって過ぎちゃいました。
勢いで参加してもブログは勢いでは書けなかったです…
それでも、書ききれたのは、このグループがあったからだと思ってます。
ありがてぇ。
書けなかった場合は、翌週は2本あげるのがルールなのですが、
1週目分として書いたけど0時すぎた分は敢えて計算せず、翌週なんとか2本あげました。
その後は、順調に…と言いたいところですが、このブログを日曜の23時から書いてるのでまたも危険な状態ですｗｗｗ
とにかく参加してみて良かった
このグループ、エンジニアの方が主催なのもあってエンジニアの方が多い（というか自分以外エンジニアさんですかね？）のですが、職種とかではなくて意欲的な人が集まっているという空気感がすごくいいです。
最初は、ちょっと場違いか？って思ったけど、こんなブログも見ていただけていてありがたいです。
皆さんのブログももちろん見させていただいてますが、プログラミングの話ばかりではないので普通に楽しく読んでます。
コードとかの内容については正直、自分には分からないのですが理解できなくても読むのは楽しかったりします。
（少しでも勉強して分かればもっと面白いんだろうな。）
プログラミングもいつか勉強したいと思ってるけど、全然やれてないのでいいキッカケになりそうではあります。
サーチコンソールのAPIとかもやりたいけどPythonでうんぬんて出てきてそっ閉じしたんですよね…
何かにつけ、自力で火をつけれない自分ですが、こういう場があって非常にありがたいです。
今回、参加したのも知ってる人だったからっていうキッカケはあったんだけど良い場に参加できて本当に感謝。
来週は、早めにブログ書くぞ！
そしていつか「サーチコンソールのAPI接続して〇〇したで」ってブログも書こう！
Google Analyticsでサンプリングされてるか確認できないと思ったらできた
Google Analytics（アナリティクス）で選択している期間中のデータ量が多すぎると「サンプリング」されてしまうんですよね。
データ全体の何％かを使用して予測した数値を出してくるんですが、とってもブレブレ…
同じ数値が並んでたり、ものすごく数値が良く（大きく）なってたりして参考にしちゃいけないのでは！？というレベルで困りますｗ（無料で使わせていただいてるので仕方ないですね…）
データのサンプリングについてはGoogle公式を見てみてください。
数値を見てるとおかしいなとはなるのですが、気付かずに「めっちゃうまくいってるやん！」みたいになったことが何度あったことか…（途中で気づいて心が折れてます）
サンプリングされてるかチェックできなくなった！
以前のアナリティクスのUIでは、右上でサンプリング状況と何％のデータを使用するか調整できたる項目がありました。
と言っても、自分はわざわざサンプリングすることはありませんでした。
一応、サンプリングデータを使用すればデータの表示速度は早くなるっていう微妙なメリットはあったんですけどね。
それが、いつの日か「精度優先」か「速度優先」の2択になっていました。
それも別に問題はなかったんです（精度優先しか使わない）が、さらにその項目すら右上から消えてしまったときは衝撃だったことは今でも忘れられないです。
サンプリング状況すらそこから消えてしまって、サンプリングされてるのか分からなくなった…と、ちょっと文句言いたかったレベルで悲しい変更でした。
90％みたいな若干のサンプリングになると気づきにくいので、つらいです。
と思ったらあったよ！
アナリティクスを見てたら偶然見つけました！
ここにマウスオーバーすると
ちゃんとサンプリング状況と「精度優先」「速度優先」の選択肢も出てきましたｗ
残っててよかった！と、これ見つけたときは歓喜しました。
半年以上？1年近く？ずっと見ていなかったので、これまで見てなかった分も存分に見ます！（そんなに見ても意味ないですがｗ）
まとめ
さっさと文句言えばよかったかもしれません。
「あるけど？」言われて恥ずかしい思いをするハメにはなってましたが。
もし、自分みたいに知らなかった人がいて喜びを分かちあえたら嬉しいです！
※このブログはサンプリングされるほどのデータが無いので確かめられませんでしたが、先ほどの画像で「緑のマーク」だったところって、サンプリングされると色変わったりするんですかね？知ってる方いたら教えてください。
