https://www.shortnote.jp/view/notes/APbqCRpG
Google アナリティクスのフィルターでページタイトルの置き換え
Analytics でリファラスパム用のためのフィルターがほとんど必要がなくなってきていたので、除外という目的以外なフィルターの使い道はないのか模索していたところ ——
Analytics のiOS用アプリで縦画面で使っていると、ページタイトルの長いものが隠れて見えない、ということがあります。例えば、タイトルの先頭に接頭辞などがある場合は、この文字は毎回先頭に入ってきますから、ようするに場所をとります。
この接頭辞はフィルター機能を使って置換(というか、実際はリムーブですが)することができます。
- 適用したいビューのところで、フィルターの作成をします
- フィルター名 :任意
- フィルターの種類:カスタム / 検索と置換
- 検索文字列 : 任意
- 文字列の置換 : 空白で検索文字のトリム 、任意文字で置換
- フィルターの確認で確認する(集計データによってはしめされないことがあります)
といったように設定しておけば、次からフィルターで置き換えされて、モバイルアプリでみたときも長いタイトルがみやすくなります。
GAリファラスパムその後
Google Analytics のリファラスパムというのがあって、GAの利用者が参照元確認するのを利用して、アクセスを得るという手法のスパムらしい。
それらは、カスタムフィルターというもので対処するのがよいとされている。これはアクセスせずに、GAスニペットのコードを利用した方法によりデータをおくってるから、というのが先人たちによって明かされてきたのだ。
しかしながら、フィルターの情報が共有されれば、相手にもすり抜ける手だてを教えているようなもの。なので、あの手、この手と変えてこられたら都度対応ということになる。
ここみたいにアクセスが少なく個人のサイトであれば、WordPressのStats 等で十分。むしろGAはアクセスのみをみるだけならばオーバースペック。
ここではないけど、トップページのみスニペットを設置しない、というのを数週間続けている。ここまでのところスパムらしいアクセスは全くといっていいくらいない。
oEmbed 対応テスト
https://www.markdiary.com/archives/2014/06-12215500.php
メモ
- Movable Type version 6.1
- Movable Type DATA API v1
-
Data API PHP Cache 使用
メモ:GA リファラスパム対策
Googleアナリティクスで、主にロシアからのリファラスパムを除外する、とかいった話
根本的には、GA側が対策してもらわないことにはどうしようもないと思う。
基本としては、参照元とされるサイトへは不用意にアクセスしないことです。
まとめると、ビューの設定でフィルターを作成して、自分のところのドメインで絞り込みかければよい、ということのようです(リファラもとのフィルター作成だと、日本国外のサイトのほうでもrefスパム情報は紹介されてるんで変えてこられるとキリがない)。
想像だけども、機械的にGAのトラッキングIDを生成するか収集しては、ダミーなページとかから呼び出ししてる感じじゃないでしょうか。たいていサイトのトップ(/)にしかつかなみたいだいし。あと、比較的最近に作成したほうのIDにはこないみたい
その割には、滞在時間の記録が残っているようなので、自分としては、サイトのトップだけトラッキングスニペットを外す、で記録されないようになったみたい。
このブログでは、GA設定してないけど、それほどアクセスないところだったら、GAだとオーバースペックで WordPress の Stats で十分だとおもいます。
追記
トップページで、 ルート / へのリクエストをフィルターするという方法が紹介されていました。
フィルタは、リクエストURL で、^/$ を除外にすることで、サイトのトップページ(/)へのアクセスは集計されないようになります。このあと、ga() に、ページのデフォルト値上書きによって、実際のアクセスのあったものをカウントさせるという方法のようです。
Google Analytics で自分のアクセスをカウントしないやり方
http://www.koikikukan.com/archives/2015/01/13-005555.php
まあよくやるパターンなので、説明はいらないかとおもいますが
(自分含めた解析のビューとフィルターのあるビューと使い分けるのがよいとされている)
因に、プライベートIPで変動がおきるような場合は、先頭の2つくらいにして、「前方が一致」みたいにしておけば、一往は使えます(変動によって効かなくなったら修正する必要があります)。
それでは、自分をカウントしない、他のやり方で自分がよくやるものを書いときます。
1. JavaScript の動作を見なくてよい場合
ブラウザのスクリプトを切った状態でページを開く(自分ではOperaとかを常時JS切ってるのでそれ専用にしてる)
JSオフのときどう見えるのかの確認にもいい
2. JavaScript の動作も確認したい場合
Movable Type だと プレビュー機能があるので、そこで確認する。
その際、「preview_template」といった予約変数があるんで、それを使って振り分けする、みたいなことが検索すると出てきます。
でも、そのためだけにテンプレートに条件式組むのは(見通しが悪くなる)自分は嫌なので、Google Analyticsのコードはファンクションタグにしてしまって、プレビューページのクエリのときは表示しないようにしています(6.xで同梱されてるGoogleAnalyticsのプラグインのファンクションタグはどうなってるかは未確認です) 。プレビューでみればスニペット自体が表示されない仕様になるから、何回見てもカウントはされません。
BitbucketリポジトリにAnalytics設定メモ
ディレクトリ型のページなので、リポジトリごとにプロパティを作るのが分かりやすいとおもう(いちおう、複数のリポジトリに同一のプロパティIDをいれても動作するらしい)。(追記:作成数に上限があるので、データをとりたいものだけに絞るのがいいように感じます。)
リポジトリの設定ページ( /admin) の、Google Analytics key (Google Analytics キー : in Japanese) の入力欄に、UA-から始まるプロパティIDを入力して、保存する。
GAの アナリティクス設定のところの、「ビュー」で、すべてのウェブサイトデータの他に、フィルターを施すための新しいビューを作成。
作成したビューで、自分からのアクセスを除外するなどのフィルターを設定しておく。
確認
ビューで「すべてのウェブサイトデータ」(初期で設定されている名称。あとで変更可能)のほうを開いて、リアルタイムのレポートを出しておく。
自分で Analytics 設定したリポジトリのデフォルトページ等を開く。
Analytics のリアルタイムレポートにアクセスが記録されているようならば、設定はは完了している。この時点では、トラッキング情報のところでは、未設定の旨の文言が表示されているが、時間が経てば、受信しています、の文言になっている。
メモ:Coreserver のGNU bash 脆弱性は対応済みに
- 障害情報 (CoreServer 全体・複数)
[2014/09/26 16:00] 平素は弊社サービスをご利用いただき誠にありがとうございます。 コアサーバーは、GNU Bash の脆弱性(CVE-2014-6271、CVE-2014-7169)に対して対応済です。
Yahoo 検索へのPingがとおらなかった件
プログ登校時にYahoo へのPing送信で失敗するようになっている。
以下はMovable Type のログから
http://api.my.yahoo.co.jp/RPC2へトラックバックできませんでした: HTTPエラー: 500 Can’t connect to api.my.yahoo.co.jp:80 (Bad hostname)
まあY!検索はGoogleベースに変わったとかいう件からして、送信されても効果のほどは如何なものかとおもうんで、送信先から外した。
ブログの空き地利用に関して
上記のような質問があがっていたけども、こんなものは、検証するまでもなく、ほったらかしにしておくのが最善策に決まっている。
- 自分が見ている環境と同じ条件ですべてのひとが見ているとは限らない (ある人はウィンドウサイズを最大にせず右サイドバーが隠れる状態でみているかもしれない)
- 希望する動作は、読んでいる途中から段落の文字数が変化するけれど自分で読んでいてどうなのか?
- サイドバーの状態に本文をあわせるのは逆だとおもう
- 見せ方の部分に JavaScript とか jQuery とかであてる価値のあるものかどうか
- 質問サイトだから、質問者の希望を叶える回答されるのは当然あるべきだが、それはひっくり返せば、閲覧者側にとっては最良のものではないかもしれない
という理由からなのだけど、結局のところブログで主となる部分は記事部分なので、たとえ空きがあっても、表示として問題がないのならばそれでいいと思ってます。
