シアターオーブのスケジュールアラートをopen&shareします。

ざっくり言うと

  • シアターオーブ公演前後は普段より遙かに混雑する
  • 公演スケジュールを取得して、ircに通知するスクリプトを書いた
  • ヒカリエに入っている:D社にもニーズありそうだからOpen&Shareする

背景

去年10月から勤務地が渋谷ヒカリエになりました。渋谷駅直結で雨に濡れずにいけるので大変ありがたいのですが、ヒカリエには一つ頭を悩ませることがあります。

それはオフィス入り口が11Fにあるため、11Fまでは一般の利用者とバッティングしてしまいます。普段はそんなに気になることは無いんですが、11Fにはシアターオーブというシアターがあって、公演前後は普段より遙かに混雑します。残業後にバッティングすると、見事に心が折れます。

事前に公演スケジュールが解っていれば、時間をずらせば良いだけなので、怒りにまかせてシアターオーブの公演スケジュールを取得して、ircに通知するスクリプトを書いたところ、なかなか評判がよかった&同じビルに入っている、某:D社にもニーズあるんじゃないか?ということで、Open&Shareしようと思います。

コードについて

コードはgistに置いておきます。

構成としては、Web::Scraperでシアターオーブの公演スケジュール(http://theatre-orb.com/lineup/calendar/)から情報を取得してApp::Ikachanを経由してircに投げています。

開始時間の1時間前と、公演時間が解っていれば、公演終了30分前にircにポストします。開始時刻の方が早めにアラートだしているのは、開始時刻の30分前ぐらいが開場なので、少し早い時間に混雑するからです。公演終了の方は、公演終了10分前~終了時間15分後ぐらいが混雑する時間の様です。(実際観察した)

特殊な構成として、シアターオーブの公演スケジュールからは公演時間が取れないので、Webataデータを持つことにしました。手動メンテですが、そんなに公演の種類ないし、とりあえずの実装です。

シアターオーブに問い合わせしたら、スケジュールの方に乗せてくれそうな雰囲気でもあったので、そうなったらスクレイピングに切り替えます。

使い方はこんな感じで、cronなんかで10分おきに起動するのを想定しています。

 $ orb-rush-timer.pl -i [ikachanのurl] -c [ポストするチャンネル]
ex) orb-rush-timer.pl -i "http://ikachan.hackmylife.net/notice" -c "#orb"

注意点

ちなみに、幾つか注意点として、公演終了のアラートを投げるのは、公演時間が解っているときのみです。また、時間の比較にTime::Pieceを使っているのですが、古いバージョンだとタイムゾーン反映してくれなかったりするので、新しいバージョン(おそらく1.17以降)を使う必要があります。


[6/24 14:17追記]
toku_bassさんよりコメントでuse Time::Pieceでバージョン指定しては?とご意見頂きました。1.17以降で正常な動作を確認したので、バージョン指定を追加しました。ありがとうございます!


それでは快適なヒカリエライフを!



このエントリーをはてなブックマークに追加

ずっと待っていた女神転生Ⅳの3DS同梱番が届きました。

IMG_6453
もうちょっと大きい箱で来ると思っていたら、ほんと本体が入って居るだけの外装。普通の3DS LLがこのケースなのかな。

IMG_6454
初回限定なのでアートコレクションとサントラCDがついてきました。これ同梱されてるとおもったら本体の箱に輪ゴムで止められてました。ソフトは付属のSDカードのプリインストールされています。このCDはシリーズファンなら思わず「おっ!」と思うアレンジが入っていて良いですね。Ⅳの音楽も凄くいいのでテンション上がります。

IMG_6457
限定デザインの3DS。サンプル画像で見てたよりマット感があってカッコイイ。こちらがカオスサイドで

IMG_6457
逆さまにするとロウサイドが出てくるというトリックアート仕様。白と黒のコントラストカッコイイ。

最初に有った方が良さそうなものも一緒に用意しました。

IMG_6458
折角の限定版だし、保護するものが欲しいとおもっていたので、このTPUやわ硬カバー for ニンテンドー3DS LL クリアを購入しました。シールのが良かったんだけど、あまり良さそうなのが無かったのと、普通のプラスチックケースは手触りが好きじゃないので、これを選びました。

IMG_6461
任天堂公認 アイテムらしく、フィット感はかなり良いですが、うっすら白みがかっているのがちょっと余計。3DSのロゴはほんといらなかった。手触りは噂どおり良かったです。

BlogPaint
後ろ側は素晴らしく良いです。フィット感あるし、ペンやジャック類もピタリとあう。少し厚みがでるけど、気になるほどではないです。

IMG_6459
画面の保護フィルムはつけやすさで空気ゼロ ピタ貼り for ニンテンドー3DS LLを選びました。素晴らしくつけるのが簡単でした。

IMG_6463
フィルムつけてる感じはほとんどないので、全然問題なしです。むしろ貼りやすいことの方が重要。

IMG_6460
一応カバンの中でいれるのにポーチがあったほうが良いかと思って3DSLL用ソフトポーチ『ジャスト・イン・ワン3DSLL(ブラック)』を買いました。安い割にいろいろ入れられて良いです。

CYBER・USB充電ケーブル(3DS用) 【3DS LL対応】CYBER・USB充電ケーブル(3DS用) 【3DS LL対応】 [Video Game]
商標:サイバーガジェット
(2011-02-28)
あと、充電用のコードがついてないの届くまで知らなくて慌ててこれを買いました。USBの方が何かと便利だし、安かったのでコレにしました。

女神転生Ⅳ自体は、絵の感じとか初期の設定とかみてて、どうかなー?と思っていたけど、流石にそこはアトラス。メガテンの雰囲気をまったく損なうこと無く作り込まれています。

難易度は口コミで言われているとおりかなり辛口。メガテン史上でもかなり上位と思われます。(偽典がいろんな意味でヤバかったので、一番ではないと思う)。 難易度調整はすぐ出来るようになるので、まぁそのあたりは親切設計ですね。どこでもセーブできるし、ボスだけ難易度替えるとかも可能なので、普通にプレイには困らなそう。

今回は仲間に誘うのがかなりしんどいのと、デビルサマナーばりに悪魔とのトークが楽しめたらよかったなぁ・・って所がちょっと残念。今のところずっと金欠なんだけど、これはやり方次第でなんとかなるんだろうか・・?いずれにせよ、かなり根気が要りそうです。 

トータルでみると、従来のメガテンファンなら買って損はないというか、すぐ買うべき。すれ違い通信もあるし、今が一番もりあがっているので、このタイミングでプレイした方が良い。3DSないなら即買えばいいと思います。

真・女神転生IV真・女神転生IV [Video Game]
商標:アトラス
(2013-05-23)

このエントリーをはてなブックマークに追加

サイトを改善する上で重要になるものにABテストがあります。

これは違うデザインのサイトパターンAとB(2つ以上でも言い)を実際にユーザーに使って貰って、より効果の高い方を採用するというテストですが、ABテストを実施する上で考えないといけない厄介な事が幾つかあります。

  1. ユーザーを振り分けて違うデザインを見せる必要がある
  2. 効果測定を行うための仕組みが必要になる
  3. 各パターンのview数にばらつきがでるので補正する必要がある

特に1が厄介で、単にランダムで見せれば良いわけではなくて、一度テストパターンを見せたユーザーにはテスト期間中ずっと同じページを見せる必要があります。

細かく言っていくとキリがないのですが、この辺りの悩ましさはGoogle Analyticsでまとめて解決してくれます。

AnalyticsによるABテストのメリット

凄く簡単に言うと楽だって事ですが、ちゃんと書くと以下のメリットがあります。

  1. jsを貼るだけでユーザーの振り分けをしてくれる
  2. ユーザーを振り分けるロジックが柔軟(多腕バンディットテストを採用)
  3. 効果測定がAnalytics標準的な機能が使える
  4. 集計から判定までAnalytics任せに出来る

デメリットはというと、jsかつ一般的に公開されているので、ABテストを実施していることがバレバレっていう所があります。


実際に設定する所を見てみる

AnalyticsでのABテストはウェブテストという名称で、「標準レポート」→「コンテンツ」→「ウェブテスト」にあります。

25)

クリックするとまず始めにテストを実施するページのURLを入力します。後述しますが、このURLは絶対ではなく、IDなどURLの一部が動的に変わるページでも大丈夫です。

54)

次はテストの基本設定です。

18)

名称はわかり安いものならなんでもOKだとして、ちょっと解り辛い項目を説明しておきます。

このテストの目的

これが成果ポイントとなります。シンプルにPVや直帰率、滞在時間などの指標の他、イベント数や特定URLへのフロー、商品の販売数などかなり柔軟に設定できます。複雑な条件に関しては、「標準レポート」→「コンバージョン」→「目標 or eコマース」に別途設定しまたものがそのまま使えます。よく使いそうなのは、クリックイベントの件数などでしょうか。

テスト対象のトラフィックの割合

画像では100%になっていますが、これはテストパターンを見せる対象のパーセンテージで、ABテストですからオリジナルのページも含まれます。

テストパターンが1つの場合、テスト当初に割り振られるのは、

オリジナルのページ(50%) + テストパターンA(50%)

となります。もしテストパターンが3つあった場合は、

オリジナルのページ(33.3..%) + テストパターンA(33.3..%)+テストパターンB(33.3..%)

です。

割合は100, 75, 50, 25, 10, 5, 1(いずれも%)から選べます。50%でパターンが2つのケースならば、

オリジナルのページ(50%) + テストパターンA(25%)+テストパターンB(25%)

になります。対象の割合をテストパターン数でシェアする感じです。

ただし、ウェブテストが採用するアルゴリズムは多腕バンディットテストで、実はテストパターンに割り振られる比率が動的に変わります。その辺りは公式のドキュメント(多腕バンディット テスト)に詳しい記述があります。冒頭を引用すると。

「多腕バンディット(multi-armed bandit)」という名前は、それぞれに異なる見込み配当率が設定された、「One-armed bandit(片腕の盗賊)」というスロット マシンが複数並んでいる状況を模した仮説テストという意味を持っています。スロット マシンのプレイヤーは、最も見込み配当率が高いスロット マシンを見つけ出す必要がある一方で、利益を最大化する必要もあります。この状況では、これまでの配当率が最も優れているマシンのみをプレイするか、それともさらに配当率が高いマシンがある場合を想定し、別のマシン(配当率が劣る可能性もあるマシン)も試してみるべきか、というジレンマが生じます。Google アナリティクス ウェブテストでは、この多腕バンディット問題に対処するために構築された高度な数学モデルを使用します。

具体例を交え解りやすく書かれているので、一読してみるのをお勧めします。

詳細設定の所は主にテストの期間に関わる設定ですが、はじめはそのままで良いでしょう。デフォルトで最低テスト期間が2週間なので、もっと短くしたいときのみ設定するところですが、最適パターンが見つからず終わるケースもあります。

次は具体的なテストページの設定をします。

54)

このケースはパターンAとBのページを設定しています。パターンAがオリジナルのページだと思って下さい。オリジナルのページは絶対パスを設定する必要がありますが、テストパターンの方は相対パスを指定出来ます。

一番シンプルなのはhtmlを分けて、index_a.htmlとindex_b.htmlなどに分けるケースですが、動的なサイトではこれはちょっと面倒な事が多いですよね。この相対パスを使えば一つのhtml内で条件分岐して表示を変えることが出来ます。

たとえば、テストするウェブページをhttp://example.com/とした場合、テストパターンのウェブページの設定をrelativeの?var=1と設定すると、http://example.com/とhttp://example.com/?var=1bに振り分けてくれます。なお、location hashを使った#var=1なども可能です。詳しくは公式ドキュメント(パターンのページの相対 URL)にあります。

そもそもURLにクエリパラメータがついていた場合のケースはどうなるかと言うと、基本的にパラメータを継承してくれるので問題無く動くはずです。こちらも公式ドキュメント(オリジナルまたはパターンのページのパラメータの伝達)に詳しく書いてあります。

テストパターンページは最大で9個まで設定できます。あと、テストパターンのURLが異なる場合は検索エンジンでの評価が下がらないようにrel="canonical"を設定する必要があります。(参考:ウェブテストと SEO ランキング

上記の設定で生成されたコードを埋め込みます。特に此処は言うことないです。

10)

コードを設定したら次に進むと、コードのチェックをしてくれます。

39)

テスト開始を押すと実際に振り分けが始まります。

URLが動的に変わる場合はどうなるか?

ドキュメントとして見つけられなかったのですが、URLにパラメータを埋め込んでいるケースは良くあると思います。たとえば http://example.com/entry/34959/の様に、最後の34959がドキュメントのidになっているケースです。

オリジナルのURLは絶対パスしかかけないので、http://example.com/entry/34959/しか登録できないのですが、たとえば、http://example.com/entry/4567/とアクセスされた場合は、テストが無効になるのか?というのが疑問でした。結論から言うと、下記の設定でhttp://example.com/entry/4567/でアクセスした場合もちゃんとテストを有効になっていました。

  1. オリジナルのURLは代表となるURLを入れる(この場合http://example.com/entry/34959/)
  2. テストパターンのURLは全てrelativeで設定する

こうする事で、http://example.com/entry/1234/でアクセスすると、http://example.com/entry/1234/?var=1など適切にリダイレクトされます。

設定に必要な事は書いたつもりですが、ウェブテストの仕組みや効率良くテストを行うためのパターンの作り方など、色々かいてあるので、公式ドキュメントは見ておくと良いと思います。

Analyticsを導入しているサイトは多いと思うので、試して見てはいかがでしょうか?

注意すべき点 5/11追記

1つ書き忘れていました。この方式の弊害として、テストページへの振り分けにjsを使ってリダイレクトしているというのがあります。つまり、振り分けされるまえのアクセスも振り分けのためのリダイレクトもHTTPのステータス200になります。

なにが問題になるかというと、リダイレクトされているにもかかわらずアクセスログでは2回アクセスされているのと同じように見えてしまいます。なので、アクセスログからPVを集計する際に、リダイレクト後のアクセスをカウントしないようにするなどの工夫が必要になります。

このエントリーをはてなブックマークに追加

↑このページのトップヘ