お知らせ・日記
2010/03/07
wordpressのサイトの方のテンプレートを変えた。ついでに、ABテストの項目も変えた。 露出をどう高めるかを考えて、とりあえずadwordsに入札したが、クリックしてもらう広告文は、一人で考えても難しいので、テンプレを探す必要がある。 このGoogle Sitesのgoogle analytics wikiも、wordpressの方も、それなりに良いコンテンツとなってきた。google analyticsの使い方はとりあえず、良いところまで来たので、テストを廻したい。ABテストなら、早期に50回くらいのコンバージョンが取れる方法を考える必要がある。ユーザーの強制的に二者択一を迫る方法はないものか、、、迷惑を掛けずに。 参照元の積み重ねの記録は、ユーザレベルの変数を細かくとれば、簡単にいけそうな気がするけど、やりたくないので、当面やらない。 Google AnalyticsのHow Toは、そろそろ限界なので、違う分野と絡める必要がある。テストだ。 勉強会をやるためにも、データが必要。どういう人にどういうニーズがあるのだろう? 関係性の構築がゴールなんだよな。関係性っていうのは、コンタクトリスト? 明日は、広告の方法など、マインドマップにリーチするツールを書き出してみよう。それが、ToDo. |
2010/03/05
アドバンスセグメントのセグメントのテスト機能は、とても有効な機能だと理解した。apiでも結構使えるし、自動化すれば、それなりの遷移図が作れそうな気がした。でも作らない。僕自身にニーズはない。だれかのリクエストがなければ、いらないものだ。 また、google apps scriptの文字化けが直った事も確認した。こちらは、スモールビジネスでもニーズがありそうだ。たぶん、レポーティングに相当使えると、個人的には思う。相当、認知は低い感じだけど、ポテンシャルはでかい。フィーが取りにくそうなのは分かるが。 そろそろ、自分の興味より、世の中のニーズに重心を移さねば、、 |
2010/03/04
アクセス解析のワークショップにいった。 前回は、サイト全体の指標をあれこれみたんだけど、今回は、セグメントしてデータ。 グループごとに一つのセグメントを決めて、このセグメントのセッション(ひいてはユーザー)への改善策まで練るという流れ。 改善策は、 1. 入力フォームの改善だった。僕は、あまり意識していなかったけど、やはり気になる場所だ。離脱が数字で出る以上、改善したい。フォームの適正化は、一つのトピック(EFO)になってたと思うので、議論になりやすいのだと思った。個別箇所で、計測データを埋め込めば、詳細なデータが取れるけど、手を入れられない以上しかたがない。ポイントは、ナビゲーションと、情報の圧縮度みたいだ。ラジオボタン(低い)、プルダウン(高い)。ナビゲーションは、テキストボックス入力でも欲しいし、フォ-ム全体でも欲しいと、カーナビばりの機能が求められている。 2. ページ数の多いサイトで、情報提供と会員募集(など)の二つの役割が課せられているサイトがある。情報提供側のコンテンツにも、会員募集の流れを作っておきたい。CMSで、導(動)線を確保はしているが、、、今思うに、文章の最後に、アドセンスのリンクユニットみたい感じの、テキストリンクの導線があるといいのかもしれない。テストしてみたい。 あと気がついた事。 Google Analyticsで、目標達成プロセスを見る時に、アドバンスセグメントが切れないのは痛い。今回のワークショップでは、紙のデータ(たぶん、ページ別セッション数として)として予めもらっている形だった。ファネルの絵がないせいか、参加者の注意を引かなかったきがした。たぶん、エクセルので、自動ファネル図生成マクロとか作ればいいのかもしれない。ウェブサービスでもありそうだ。 また、字と画像のバランスの指摘も出ていた。ウェブは情報提供するものという考えは、数字の前で否定されるべきかもしれない。テストして試して見たいと感じた。 あと、単価UPやクロスセルみたいなのは、つい忘れてしまう。現状、自分のサイトにはそういう商品が存在しないけど、thanksページでは、なんらかのpromotionが必要かも。キャッシュポイント(リンク)の置き方の話かな。僕の場合なら、フォーム完了後の手直しか。 なので、次のblogのテーマは、
|
2010/03/03
tracking api の イーコマースの部分を書いた。 asyncとjqueryの併存に関するベストプラクティスが分からないので、結局、asyncを最後に置いた。 今までは、適当にやっていて、計測できていたと思うけど、シンプルで漏れがない方法が知りたい。 _gaq プロパティなしで、ga.jsを実行すると?? 特に問題ない。中で_gaq作るわけで、問題ない。 jQueryからのloadingのdrawbackは何?
google に jqueryをhosting してもらう効用は、
同一セッションでの、複数の参照元についてアクセス解析イニシアティブのフォーラムに、いろいろ書いた。わかりかけてきた気がするけど、眠いので、寝る。 |
2010/03/02
blogの方に、導入支援や勉強会の講師をやりますという告知をだした。料金などは、あまりよく考えずに付けたので、上げたり、下げたりしそうだ。 フォーラムの質問にキチンと答えられなかったので、テストして確認しようと思ったら、ゴールの設定を忘れていて、メンテだったので、明日にする。 blogの申し込み画面のフォームの調整に時間がかかった。世の多くのサイト制作の人も、細かい点で時間を食っているんだろう。 素直に、contact-form7を使えば良かったのかも。 導入支援で、自分が作ったものより、実績のあるもののがみんないいだろうし。とりあえず、エラーやfoucsごとにanalyticsの計測タグは入れて置いた。 明日の午前中は休む。明後日も日程が詰まってる。アンケートも実装してみたかったけど、できそうにない。 |
2010/02/28
サイトの移転と、手直しをした。 dreamhost,sharkspaceと来て、国内のcoreserverになった。coreserverが軽いか重いかは、同居人次第みたいなので、何ともいえないけど、一応、体感的には速くなった。 今後の作業としては、
順番は、こんな感じ。 検索バーを長くしたテストをしてるけど、全く効果がないようだ。かなり重厚なサイトでないとだめなのかも知れない。 よく考えれば、僕自身も人のサイトでサイト内検索なんてしない。 よほど、注意を引かないと、数字としての違いは出せない。取れるサンプルが多ければ、わずかな違いも検証できるんだけど。 |
2010/02/25
アクセス解析のワークショップに行ってきた。 僕は、google analyticsのツールを賢明にいじっているだけで、数字をまとめる作業(レポーティング)をしていなかったことが分かった。別に大した事をやってるわけではないのだが、抑えるべき数字が頭に残っていなかった。一人でやるときと違って、マルチタスク処理を上手く休ませないといけないのだが、それができなかった。 近い未来に、僕自身で、ワークショップ形式の解析ライブみたいなのをやりたいと思っていたけど、イメージの練り直しが必要なのかもしれない。ペアプログラミングみたいな効果を期待していたけど、同じイメージではないのかも、、、 明日は、jQueryを勉強する。終末にアンケートをテストを含めた形で実装したい。 あとは、キーワードを丹念に拾って、ニーズに答えるエントリを書こうかと思う。 でも、それはできないので、書きたい記事を微調整する方針。 昨日寝る前に速攻で書いた記事はアクセスを集めた(リンクがあったので)。他の記事はもっと価値が高いと、僕自身は思っているのだけど、、、こういう考えがまずいのだ。外部からの評価を評価というのだ。 |
2010/02/25
wordpressの方では、新規のABテストを入れた。検索バーの長さを変えたもの。 あと、重複記事かもしれないけど、外部リンクの計測の話もデータ付きで書いた。 google sitesでは、analyticsのapiが使えないので、やはりアクセスをwordpressの方に誘導しないといけない。 あとは、記事評価やら、アンケートみたいなものを実装して、それとABテストを結びつけたい。 また、カスタム変数で、ユーザレベルと、セッション・ページレベルの変数を合わせて、分析できそうな気がしてきたので、それも考えたい。行動ターゲティングは、ユーザの行動を、サイトの閲覧ページの性質で属性わけするもの? それなら、なんかやれそうな気もしてきたけど、深夜の妄想かもしれない。 |
2010/02/23
wordpressの方に、異常値を削って指標を見る話を書いた。 いろいろAPIをいじると、どうしても変な値がでてしまう。そういう値をどうクレンジングするかは、テクニックがあるんだろうけど、今回のはあまりにも簡単な話だった。でも、僕が知る限りそういう話はweb上ではあまり見ない(アドバンスセグメントでのクレンジング)。 デ-タの不正確さと、考え方の混乱は、本人には見分けが付かない。混乱してるのだから、当たり前だけど。他の人と対話しながらやれば、もっと効率良くできるのにといつも思う。 今日の日記でした。 |
2010年2月18日
ペ-ジ別セッション数の話をもう少し、分かり易く書けないかと、構成をいじってみたけど、できなかった。 途中で、思いついたように、ディレクトリ別セッション数のコンセプトが出て、ディレクトリ内でのペ-ジ数が少なければ、アドバンスセグメントで、"or" を使えば、セッションを適切に絞れる事は確認した。 コンテンツ画面の詳細で、ディレクトリ別にペ-ジ別セッション数をみるのと、数値的には変わらない事が多いかもしれないけど、ディレクトリ単位では、サマリと同じように、ペ-ジ別セッションが足されているだけなので、数値としては適切でないと思う。 上のアドバンスセグメントの方法は、個々のペ-ジ名で絞る事になるのだが、ダイナミックセグメントをexport apiで使った場合に、どれくらいの文字数?まで可能なのか、不明? 手を動かさずに放置してしまった。ToDoに上げる。 Forumで、アドバンスセグメントをAPIで作成できないか?という要望が出てて、開発者が、なんでいるの??みたいに返していたが、個別ペ-ジの集合でセグメントを切りたい時には、そんな機能があればいいなと思った。思った、だけ。 あと、uniquePageviewの定義文だけど、Data Export APIの方にもあった。こっちは納得できる文だ。一般向けの定義文と全然違う内容に見える。 残りの課題は、
ぐらいが、頭の中。番号順が優先順位だけど、2が簡単かも。 |
1-10 of 24