ソーシャル知らないけどSocialWeb Conference vol.5 - OpenSocial Night #2 -を見て来た

OpenSocial カンファレンス

※追記
動画見た方がわかりやすいと思うので動画おいておきます。


会場が近いといいですね。階段降りただけで有益な話が聞けるというのはとても嬉しい。
ソーシャルアプリとかOpenSocialって全然触ったことがなく、mixiアプリもサンシャイン牧場に招待された時にperlでボット作ってしばらく育てたくらい。
それだけじゃマズいなと思って昨日mixiアプリの開発者登録したものの、helloworld作ろうとしたら本格的なアプリ登録フォーム出て来たので結局やめてしまいました。


ってことで、メモしたものの少ししか知識がないまま話を聞いたのでだいぶわからないところとか抜けたところが多かった。
他の人の資料とか見ながらまた追記とかします。


あ、でもKayフレームワークはLLTVの時に聞いたので覚えてました。
python触ったことないけど、話聞いててKayフレームワークは触りたくなるくらいの好感度。
App Engine使う時にやってみたい。


以下メモ。
何か間違ってるところあったらコメントください。

はじめに

  • 前回参加していない人が多い
    • 第1回はモバゲー、リクルートの新しい話をやった
  • 今回はOpenSocialについて

OpenSocial jQuery によるウェブ制作スキルを活かした OpenSocialアプリケーション開発 - なかじまんソフトウェア株式会社 中嶋博信氏

OpenSocialアプリの基本性質
  • ProfileビューとCanvasビューがある
  • ウェブアプリとの違い
  • パーミションモデル
    • 情報の取得や更新の制限がある
      • 個人情報などの取り方に制限
OpenSocial jQueryの目的
  • OpenSocialはHTML+CSS+jQueryで作られる＋OpenSocialアプリはプラットフォーム
    • OpenSocial jQueryが橋渡しし、ウェブアプリと同じように開発できるように支援
  • 使い方はopensocial-jquery.jsを読み込み、jQueryと同様の利用方法で開発
  • OpenSocial jQueryへの期待
    • 高いシェア
    • 層が広いのでデザイナも使える
    • jQueryでの実績、活用
      • 現在ウェブアプリで使っているjQueryのウェブアプリをそのまま移植できる
    • SAP(Social Application Provider)の動機付け
OpenSocial jQuery
OpenSocial jQueryの構成
  • 表面上はjQuery
    • jQuery1.3.2を内包
    • JSDeferred0.2.2
    • コアプラグイン
      • GadgetsAPIを使いやすく
  • 拡張プラグイン
  • jQueryプラグイン
OpenSocial jQueryの特長
  • Ajaxメソッドを使ってる
    • OpenSocialなので自分のドメインでなくクロスドメイン
  • ビューの遷移（ウェブアプリでいうページ遷移）
    • getJSONにclickイベントを持ったコールバック関数を渡す
    • ready関数の第2引数に表示するページを渡す
  • 署名リクエスト＋OpenSocial Hostも簡単にできる
    • 署名は簡単。poseのURLにスペースを空けてsigned
OpenSocial API側の拡張
  • プロフィール情報、友だち情報の取得
  • 永続化情報の取得と保存(削除は未対応)
  • postData,getDataで取得と保存
    • プロフィール情報はGET /people/@viewer/@selfで取得できる
      • viwerをownerに変更すればオーナー情報
      • selfは省略可
    • 友だちはfriends
    • メッセージ送信はmessage
注意点
  • OpenSocial APIの制限を受けるため
    • viewerや友だちがアプリをインストールしてないと画像が表示されない
      • viewerがアプリをインストールしてないとプロフィール情報はIDのみに制限
      • 友だちがアプリをインストールしてないと
    • 「mixiアプリに関するプライバシー設定」 の値も影響される
注意点に対してのエラーハンドリング
  • エラーのコールバックがある
    • error
      • viewerがインストールしてなければerror()で紹介ページへ移動させる
    • ajaxError
    • next().error()
      • JSDeferred0.2.2の機能
  • 取得できない項目を補う
    • 取得できないものはデフォルト値を設定
  • アプリをインストールしている友だちに限定する
    • @appを利用する

AppEngineを使ったソーシャルアプリの開発と運用 - 株式会社キャンディット 松尾貴史氏

プロフィール
AppEngine
  • Googleのサーバでウェブアプリが動かせる
  • ほとんど落ちないしアクセスが増えたら分身してくれる
  • BigTable(Datasotre)にデータが入るので、多い日も安心
    • DBのようにshardingを考えなくてもいい
  • と、たくさんメリットあるのに0円！
    • しかもOpenSocialSigned Requestの検証もついてる！
      • 検証はとても簡単kayoauth
kayoauth
こんなにメリットばかりだけどホントにタダ？
  • 一応従量制
  • 従量制とは言え、GClueの社長の話では
    • うはうはだよ。何もしなくていい
    • 70万PVで$10/day
      • 20万PVで$1/day
    • オフレコ
      • 原価計算3万円くらいなので原価率6%くらいの収入
    • ただ、広告単価が下がってからは厳しい
      • アプリ内で課金しないと。
      • データのバックアップが課題
まとめ
  • AppEngineはSocialアプリにぴったり
    • はじめはタダなのでポンっと出すのは楽
  • 難しいという人は仕事くれれば作ります！
質疑応答
  • データ構造がRDBじゃないのだけど、Socialアプリに相性がいい？
    • データ構造は相当複雑な物も表せるし、データが多くても考えなくていいから相性はいいと思う
  • kayフレームワークがDjangoよりもメリットがあるところ
    • Djangoはpythonで有名なフレームワークではあるけど、AppEngine上では無駄なコードが多い
      • AppEngineで動かすためには色々工夫が必要
      • RDB用の新機能がどんどん追加されていくと思うが、それがAppEngine上で再利用できるかわからない
    • Django-nonrelもあるんだけど、コールドスタンドアップが重い
  • 会場のPythoistは何人？
    • 7人くらい

OpenSocial アプリ開発／管理プラットフォーム 「OpenSocial Host」 のご紹介〜 ローコスト、ローリスクでアプリ開発を始めよう！ 〜 - 株式会社ハートレイルズ 上楽理央氏

OpenSocial Hostとは？
  • JavaScript API（PC、モバイルの両方に対応）
    • HTTPベースのWebAPI
  • インフラ：ファイルストレーズ、KVS
  • 管理GUIもある
  • アクセス解析、イベント解析がついてる
特長
  • 単一機能のみの利用が可能
  • 従量課金
    • 一定の利用量までは無料
      • 数万ユーザ程度のアプリならまず無料
      • アドプログラムの半分以下の課金が目安
  • ソーシャルアプリの有名どころはほぼ対応
中身
  • opensocialhostという名前空間の機能にさまざまなAPIがある
  • API
    • OpenSocial hostのへのデータベース操作:DataAPI
      • KVSのキー毎にパーミションを設定できるのでデータのパーミションを細かく設定できる
    • OpenSocial hostのへのファイル操作:FileAPI
      • Ajaxベースのファイルアップローダ系も簡単に対応できる
    • コンテナへのソーシャルグラフ操作:OpenSocial RestfulAPI
      • プロフィールやライフサイクルイベントに連動した処理を実装可能
OpenSocial HostのDB
  • KVS
    • キーに細かいパーミションを背てい
    • エクスポート、インポートが可能
      • 使いづらいなら他のプレットフォームへの移行が容易
ファイルのホスティング
アクセス解析、イベント解析
  • PV,UU,UAなど一般的な解析
  • 個々のユーザの利用解析
    • 「mixiのどのユーザが使ってる」など
  • アプリのインストール、アンインストール数等の確認が容易
近い将来対応
今後の対応
  • 国際化
  • アプリケーションテンプレート
    • GUIでアプリのカスタマイズ
  • 汎用PaaS
    • JavaScriptorのためのプラットフォーム
質疑応答
  • KVSの内部はどうなってるか教えてもらえますか？
    • 今はKVSもどきの普通のRDBを使ってるが、対応できなければ外に出すかも
  • ファイルAPIがあるが、たくさんファイルを置いた場合の課金は？
    • 詳細覚えてないが、1,2GBくらいになると従量課金。はじめはタダ
  • サーバサイドJavaScriptのイメージがわかない
    • 普通のHTML作る時に使うJavaScriptを管理画面からあげるだけ
    • ヘッダ情報やPOST情報をAPIを通してJavaScriptで扱う
  • JavaScriptのデバッグはどのようにやる？
    • 管理画面上にエミュレーションがあるのでそれを使える
  • 最大何万ユーザ抱えたアプリをさばいた実績がありますか？
    • 実績は今後作る
    • 全アプリで数万ユーザくらいだけど、資源を全然使ってないのでまだまだ余裕

大規模SNSにおけるソーシャルアプリの運用とマネタイズ - 株式会社ドリコム 神谷友輔氏

マネタイズとは
  • 期末テストで「アイツに勝つために何でもしてやる」という想いと同じ
まずゲームとして成り立たせるためのポイント
  • 「また明日遊んでもらえるか？」
    • おもしろさ
    • 安定した稼働
    • 絶え間ない更新
マネタイズについて
  • 直接課金
マネタイズに必要なもの
  • マネタイズに必要な「面白さ」
    • 価値を生む
  • マネタイズに必要な「記録」
    • 価値を高める
  • マネタイズに必要な「安定稼働」
マネタイズに必要な「面白さ」：価値を生む
  • 一言でいうと「成長」
    • 成長という成功価値に人はお金を払う
  • 何でも課金すべき？
    • Noだと思う
  • どこに課金する？
    • ゲームの進行に関係ない部分に課金する
      • 例えばRPGなら、「竜を倒す」という本筋に課金しちゃダメ
    • ソーシャルならではの課金する
      • ともだち
時間消費型成長と金銭消費型成長
  • 2つの成長
    • 時間を払って成長
    • 金銭を払って成長
  • どこに成功価値を置くかがゲームのポイント
    • 時間消費型と金銭消費型の2つの円が真ん中で上手く重なるのが良い（ベン図）
ソーシャルならではの価値
  • 友だち、仲間などの相手がいることで生まれるモチベーション
  • ギフトという価値の考え方
    • はじめは相手をなでるという無料の行為
      • それに対して相手はなで返す
      • これが進むと「相手にもっと色々あげたい」というギフトという価値が生まれる
  • 相手にちょっかいを出すと経験値が上がるという仕組みは必要
    • 友だちのところに行く理由ができる
      • 友だちも同様に自分のところに来てくれる
      • これが進むとその作用がループする
ここまでのまとめ
  • 価値を与えるテクニックは社内に100個弱あるけど、そこまでは言えず
マネタイズに必要な「記録」：価値を高める
  • ユーザを飽きさせないためにどこにポイント置くか
抑えておくべきKPI
  • DAU
    • 一日に遊んでくれている人数
      • 明日も遊ぼうと思ってくれているか
  • ARPU、課金率
    • 課金が減ればゲームに価値を感じなくなったということ
  • バイラル率
    • 一人が広げた人数
      • 減ったら「ソーシャルゲーム」ではなく「スタンドアロンゲーム」になってしまっている
マネタイズに必要な「安定稼働」
  • 絶対安定稼働が必要
    • ユーザが一度落ちたサービスへの復帰率は低い
      • 新規ユーザの獲得の比にならない痛さ
    • たとえゲームが100万インストールされていても、そのうち1万人しか遊んでないゲームは問題
      • 同じ1万人しか遊んでないゲームでも、まだ1万人しかインストールされていないのならそこから増やすのは頑張ればどうにかなる
安定稼働が必要だが、巨大SNSならではの問題がある
  • 想定すべき負荷がやばい
  • 数秒以内に200返しがMUST
    • エラーやtimeoutが多いとSNS側にサービスを止められる
  • アクセスが増える日時
    • リリース直後はお祭り
    • イベント直後や日付変更時
どうやって対策？
  • 普通のwebアプリと同じ点
    • チェック環境などで想定の負荷対策
  • webアプリとは違う点
    • 「ドドンパ」：0から100km/hになる可能性がある
      • 普通のwebアプリなら段々にユーザ数が増えて行くので予測がつく
      • ソーシャルアプリはリリース直後に一瞬で10万人が使うという可能性もある
  • ドリコムではスケーリングの規模の見立てができたところで手元に持ってくる
    • AmazonEC2で初めに動かして見極めをし、安定したところで自社データセンタへもってくる
対策をしたと思っていても罠が待ってる
  • EC2は西海岸
    • 行って1秒、帰って1秒という可能性もある
  • 県民魂
    • アンケートアプリ
    • 元々のpcアプリ：5000人
    • 県民魂：23万人
      • pcアプリと同じ程度だと思ったら予想外のユーザ数
  • ユーザがどう遊ぶかわからない
    • 「なでる」という軽いはずの機能が「誰でも彼でもひたすらなでる」というユーザが出てきたせいで負荷に耐えられなくなった
      • RDBでは耐えきれずTT(tyokyo tyrant)に移行