Lori MacVittie「SPDYとHTML5 WebSocketsの比較」
f5 DevCentral 2012.6.13のエントリ
SPDY versus HTML5 WebSockets
- websocketsとspdyを比較
- spdyの方が普及の見込みが遥かに高い、と予測
- 予測の理由も説明
- webの高速化とか共通点が多い２つの技術の細かい違い
- websockectsにはヘッダが無い
- この細かい違いが意外と影響範囲が大きいことを説明してる
- 色々勉強になった比較
以下斜め読んだ内容
- #HTML5 #fasterapp #webperf #SPDY
- 似てる部分多い
- だがデータセンターへのインパクトはかなり違う
- http2.0をめぐる議論が少し盛り上がり中
- The HTTP 2.0 War has Just Begun
- このエントリへ「「なぜwebsocketsがスルー？」というコメントが付いた
- 答えは簡単「HTTPヘッダ」
- コメント主は詳しい説明欲しいと思うから、少し突っ込んだ説明してみる
ソリューションが違えばインパクトも違う
- spdyとwebsocketsにはシンプルだが根本的な違いがある
- この相違点ゆえに、websocketsはwebへのインパクトは極めて小さくなる
- データセンターに話を限れば影響力はある、かも。あるいは「またの機会に」扱い
- spdyとwebsocketの特徴の重要な部分はほとんど同じ
- これはコメント主の言う通り
- 非同期通信
- long polling等々既存テクニックのマイナス点を克服し、リアルタイム風な味付けをwebアプリに付けてくれる
- TCPコネクション１つだけを使う
- サーバーのオーバヘッド減らし、エンドユーザの体感パフォーマンス向上
- データ圧縮し通信コスト減らす
- websocketsはデフォルトではない。要拡張機能
- draft-ietf-hybi-thewebsocketprotocol-15 - The WebSocket Protocol
- モバイル環境などで活きてくると期待受けてる
- httpの外で通信する所も同じ
- 仕様も運用も同じような問題を解決しようとしてる
- httpヘッダが、spdy/websocketsの違い
- websocketsにhttpヘッダがない
- ここはSOA World Magazineの「HTML5 Web Sockets: A Quantum Leap in Scalability for the Web」という記事が詳しい。曰く
- websockets接続開始したら、クライアント／サーバー通信は完全に双方の通信に変わる
- websocketデータフレーム双方からいつでも投げれる
- データフレームはテキストだろうとバイナリーだといける
- 両側から同時にデータフレームを投げ合うことだってできる
- 最小データフレームサイズは2バイト
- 「0x00」〜「0xFF」の「〜」に投げたいデータがUTF-8で入ってる
- テキストデータではterminator（RFC2616準拠）使える
- バイナリデータではlength prefixつかえる
- httpヘッダを使うインフラに対して、websocketsのインパクトがとても大きい
インフラへのインパクト
- websocketsのもたらすインフラへのインパクトは「良い事」よりも「悪い事」が上回る可能性あり
- 少なくとも、オープンに使われるwebアプリではその可能性あり
- websockets/spdyともに普及しきるまでは、ゲートウェイサービスが必要になる点では共通してる
- websocketsは既存のインフラにどう導入していくか、というところで色々キツイ場面がある
- 仕組み上websockets通信はインフラ側からは全く分からない
- httpヘッダを使ってリクエストされてるオブジェクトのcontent-type、uriを判定していくタイプのサービスからはwebsocketsでリクエストされるオブジェクトは中身が全く分からなくなる
- IDS, IPS, ADC、ファイアーウォールなどがこのタイプのインフラに該当する
- spdy通信ではオブジェクトの中身が分からないということにはならない
- 過去の自分のエントリから関連部分再掲
- Oops! HTML5 Does It Again
- パフォーマンス改善のためにwebsocketsが使ってるテクニックの１つがhttpヘッダ削除
- 「content-type？」「煩雑！」というノリで
- httpヘッダは通信のエンドポイントに転送してるデータについて伝える（text/html、video/aviなど）
- アンチウィルスソフトやマルウェア検出ソフトが得意とするテクニック
- あるcontent typeにおかしい部分がないかを検出するテクニック
- MIME type情報が使えなくなったら、アンチウィルスソフトの診断は一気に難しくなる
- データからフォーマットを推論してくことは不可能じゃないが
- httpヘッダがないのに「このデータはウィルス」といった正確な知識をどうやったら獲得できるのか
- 「httpヘッダは偽装されるし」
- 確かに。だが一般的に言ってアプリが虚偽のデータタイプを伝えることはないし、あっても悪用されることがまずない脆弱性
- 「httpヘッダなくてもURIはどうか」
- websocketの場合オブジェクトとuriの間に関連性ゼロ
- httpヘッダ削るとデータタイプもわからないし、データサイズもわからなくなる
- httpヘッダの活用がとても重要なインフラ・サービスがインフラの世界にはある
- spdyは削除しないで圧縮する
- このことが、spdyの方がwebsocketsよりも遥かに有望な選択肢の位置に高めてる
- データセンターでspdyを使いたい？
- spdyゲートウェイを導入して、通信されるデータに対してspdy有効にしたら、完了
- データセンターでwebsockets導入したい？
- 既存のスタックを色々置き換えたり、機能追加することが必須になる
- つまりリスク付きの導入
- 実績あるスタックを置き換えて、実績ゼロ・未知数のスタックをたくさん投入しないとwebsockets化できない
- もう一度「なぜwebsocketsスルー？」に戻ると。。
- 高速化・パフォーマンス向上という点ではwebsocketsもspdyも同じ効果
- 既存インフラにかける負担（置き換え、アップグレード、運用コスト増）がwebsocketsは大きすぎて、インフラの世界ではそれほど普及しないはず
- パブリックな場面、オープンな場面ではwebsocketsがあんまり普及しない
- エンタープライズについてはまだダメだと結論でてない
- 結論出てない＝有望、ということじゃないが。。。
David E. Sanger「イランへのサイバー攻撃をオバマは加速させた 」（NYTimes）
nytimes.com 2012.6.1の記事
Obama Order Sped Up Wave of Cyberattacks Against Iran - NYTimes.com
- 近刊の「Confront and Conceal: Obama's Secret Wars and Surprising Use of American Power」の抄録版
- Confront and Concealは、18ヶ月の取材をベースに書かれた労作の模様
- アメリカがイランに仕掛けてるサイバー攻撃の経緯をまとめあげてる
- そのうち映画化されそうな内容で面白い
- ブッシュ政権起源、オバマが加速、好戦的イスラエル、懐柔のためにアメリカ・イスラエル共同計画
- ガダフィ大佐からテネシーの軍事研究所へと渡ったP-1遠心分離機、巨大なワーム、イラン地下で極秘で進む核開発
- ウィルスに仕込まれた（？）バグ、極秘計画漏洩、大ダメージを受けたイラン核開発
等々
以下斜め読んだ内容
- 就任直後に出したオバマ大統領が極秘指令
- イランの主要ウラン濃縮施設への攻撃
- 稼働中のコンピュータシステムへの攻撃をより洗練化・強化させる
- サイバー兵器の利用を拡大させる
- 継続的な利用はアメリカでは初
- 攻撃プログラム関係者の証言で分かった
- オバマ大統領の決断
- イラクへのサイバー攻撃
- 前ブッシュ大統領がこの攻撃を始めた
- コードネーム"Olympic Game"
- この攻撃を加速せよ、とオバマは決断
- この攻撃の露見後にオバマが決断したのがポイント
- 2010年に露見してしまったサイバー攻撃
- プログラミングエラーが原因でイランNatanzの原子力施設を攻撃したワームがイラン国外へ流出
- セキュリティの専門家はワームの研究を始め、このワームをStuxnetと命名した
- このワームはアメリカとイスラエルが共同開発したものだった
- Stuxnet流出直後に首脳陣が会合
- ホワイトハウスのSituation Room
- オバマ、 Joseph R. Biden Jr副大統領、CIA長官Leon E. Panetta（当時）らが出席
- イランの核保有へむけた動きを抑えるためのアメリカの勇敢な試みが致命的な傷を負ったのか
- オバマ曰く「この攻撃を停止すべきか？」
- その会合への出席者した国家安全保局局員の証言
- サイバー攻撃継続すべき、とオバマは決断
-
- サイバー攻撃でイランが未だ混乱していた
- イラン側が攻撃に使ったコードを解読完了したのか見えてない状態のとき
-
- 攻撃続行後の動き
- 数週間後に新型ウィルスを投下
- さらに新型を投下
- Stuxnet露見後の数週間で投下されたウィルスの成果
- イラン国内のウラン濃縮用の遠心分離器5000台中1000台が感染した
- アメリカとイスラエルがイランの核開発計画を妨害しようとしてるという説
- 各方面の専門家、アメリカ、ヨーロッパ、イスラエルのプロジェクトの現職および元関係者。彼らへの18カ月かけて得た証言に基づく
- 全て匿名
- サイバー攻撃自体は機密扱いで、作戦の一部は現在も継続中のため
- 取材協力者の見立ては色々
- このサイバー攻撃作戦がイランの核兵器保有へのプランの妨害にどれだけ貢献できたのか。
- 作戦の成否について懐疑的な声多い
- 濃縮施設の機能は攻撃前の水準に戻り、より高度な濃縮処理を必要とする製造兵器製造も加わっていた
- イランが核兵器製造を諦めてないのかどうかは議論の分かれる所
- アメリカ諜報機関の最新データでは、2003年以降兵器の主要部品の開発を延期させている
- 兵器の一部の開発は継続していることを示すデータもある
- イランの動き
- Stuxnetの攻撃を受けたことを公式に否定
- その後施設内システムにワームを発見したと公表
- 2011年には軍隊内部に情報部門を設立
- イランの消極的防衛チーム責任者
- Gholamreza Jalali准将
- サイバー攻撃を迎撃する体制は整っている、とコメント
- 現時点でイラン側からの攻撃の兆候はみられない
- アメリカ政府のスタンスは「サイバー兵器開発してる」が「使ったことない」
- 過去のサイバー攻撃と今回の攻撃（Olympic Game）は種類が違う
- アル・カイダのメンバー所有のPCへサイバー攻撃を一度展開した、というレポートあり
- 2011年のリビアでのNATO空爆時にもリビアの対空防衛システムを麻痺させるサイバー攻撃が計画された、というレポートあり
- サイバー攻撃Olympic Gameの特徴
- 他国のインフラを麻痺させるために、継続的にサイバー兵器が利用された
- 従来なら爆撃やエージェント侵入による主要施設攻撃で行っていた攻撃と同じことをコンピュータのコードで実行した
- Carey Nachenbergの分析
- Olypic Gameで使われたワームを解読にあたった
- SymantecのVP
- 2012年4月にStanford大学で開催されたシンポジウムで発表
- Olympic Gameで使われたワーム、通常発見されるワームよりも５０倍サイズが大きい
- ワームの内部構造の解析結果をもとにした犯罪法学的調査では、責任者が特定できなかった
- サイバー兵器Flameというのもあった
- イラン高官のPCを攻撃し情報の不正取得に使われた
- コード自体は５年前ものなので、今回の攻撃（Olympic Games）とは関係ない、という政府関係者証言あり
- Olympic GameについてSituation Roomの会合でのオバマの発言
- 情報源：会合参加者
- 今回のタイプの攻撃は、アメリカを別の次元に押し進めるものだ、と
- この新しい次元への移行は、40年代の原爆、50年代の大陸弾道ミサイル、ここ数十年の無人戦闘機に匹敵するもの
- アメリカ国民が一人でもサイバー攻撃の存在を知ってしまえば、他国政府、テロリスト、ハッカーがらの所業の自己正当化を促すものになる、と
- オバマ側近曰く
- 可能性未知数の兵器のために理論的裏付けを取ることに対して、政府は乗り気ではなかった
- だが、イランの動きを止めるためには他に手段がない
- ということでオバマが承認した
- Olympic Gamesプロジェクトが失敗した場合のオバマの見立て
- アメリカにはイラン外交・対イラン制裁のを構築していく余裕がなくなる
- イスラエルは周辺地域の緊張拡大との引き換えに従来通りの武力制裁はできる
Olympic Gameプロジェクトを進めたのは、前ブッシュ大統領
- 2006年の前ブッシュ大統領の時代に遡る
- 当時の対イラン戦略
- 欧米間でイラン制裁の費用負担をめぐって対立
- 当時のイラン
- ブッシュ政権の目を盗んで、Natanzの地下施設でウラン濃縮を再開。
- 2009年まで地下施設の存在は明らかになっていなかった
- イラン大統領（Mahmoud Ahmadinejad）は核施設見学ツアー開催した
- 将来的に遠心分離機5,000基を目指す、と語っていた
- イランには、核反応炉が１つしかなく、核燃料はロシアから輸入
- なぜ非軍事核開発にそれだけ燃料が必要なのかブッシュ政権は疑問視してた
- 燃料として使う一方で備蓄して核爆弾開発用に利用できるように備えている可能性を憂慮してた
- ブッシュ政権のタカ派（チェイニー副大統領など）の立場
- イランへの先制攻撃を進言してた
- イランが核兵器を開発できるだけの核燃料を入手する前に手を打つ
- ブッシュ政権は軍事行動というオプションを何度か検討
- 中東のこの地域の戦争状態をさらに激化させるが、戦火は不確定と結論して止めた
- CIAへの対イラン工作
- イランのシステムが不具合を起こすように仕込みを続けてた
- イランが輸入した電源供給用部品に細工
- 仕込みの効果は殆どゼロ
- James E. Cartwright将軍
- アメリカ戦略軍内にサイバー軍事作戦チームを組織
- 多くの国内原子力施設の責任者
- ブッシュ大統領と国家安全保障チームへ、諜報機関スタッフからの新しく画期的なアイディアを伝達する役目も兼ねた
- イランのシステムが不具合を起こすように仕込みを続けてた
- ブッシュ政権で考案されたサイバー兵器は、過去のサイバー兵器を数段階洗練化させたものだった
- 初期の段階では、ビーコンというコードを開発された
イスラエルとの共同作戦へステップアップ
- ビーコンは基地へ潜入したビーコンが極秘情報を掴んで戻るのに数ヶ月かかる仕組み
- 地下の極秘施設の稼働方法についての計画図やシステム内のディレクトリ情報など
- イスラエルの諜報技術の水準の高さアメリカ諜報部員も注目するレベルだった
- イスラエルと共同で巨大なワームの開発を進めることになった
- このワームは侵入したシステムを内側から攻撃する役割を持っていた
- アメリカとイスラエルの緊密な連携を成立要因は２つある
- １つは、イスラエルのサイバー攻撃スキルの高さ
- イスラエルのユニット8200部隊の持つサイバースキルはNSAに匹敵する水準
- イランのNatanzの深いレベルへイスラエル諜報部員は極秘潜入していた
- Natanz攻略がサイバー攻撃の正否を握る場所だった
- もう１つがイスラエルによる武力行使を抑制させたいというアメリカの意向
- イスラエルがイランの核施設へ先制攻撃をしかないようにさせたかった
- アメリカは「サイバー攻撃はイランにとても有効」と納得させることが条件
- サイバー攻撃のあらゆる局面にイスラエルを巻き込んで参加させる他無かった
- 複数の役人が証言してる
- １つは、イスラエルのサイバー攻撃スキルの高さ
- その後アメリカとイスラエルは巨大なワームを開発した
- このワームをアメリカは「bug」と呼んだ
- 実戦投入前にbugのテストをしないといけない
- ってことで、イランのP-1遠心分離施設のレプリカをアメリカ国内に建設した
- イランのP-1施設は旧式で信頼性低い設計。
- イランはこの施設を、パキスタンの原子力開発責任者のAbdul Qadeer Khanから買った
- Abdul Qadeer Khanはブラックマーケットで燃料製造技術を売りさばいてる
- アメリカは既に同型の遠心分離施設を所有してた
- リビアのガダフィ大佐経由で入手
- リビアの核兵器開発
- 2003年に最終的に断念した
- 遠心分離施設をパキスタンの密輸組織（＝Khan）からガダフィ大佐は購入してた
- ガダフィが手放した施設はテネシー州の兵器研究所に移された
- Olympic Gameプロジェクトを予見していた米軍・諜報機関関係者たち
- 保管されてたP-1遠心分離施設を持ちだし、Natanzの施設とほぼ同一の施設を建設
- この施設を「破壊テスト」（と彼らが呼んでたテスト）に使った
- テストは国営原子力研究所のスタッフにも伏せた状態で実施
- テストは成功
- bugの挙動
- まずコンピュータに侵入
- 侵入後は指令受信するまで潜伏
- 速度を急上昇、急低下といった命令が飛んでくる
- ターゲットのシステムのデリケートな部分は暴走したのちに自壊する
- 数回失敗後に動作に成功
- ブッシュ任期終了直前の頃にSituation Roomのテーブルにレプリカ施設の残骸がテスト成功の証拠として並べられた
- イランの施設へ投下する準備が整った
- 元CIA長官Michael V. Hayden
- 任期中にサイバー攻撃をどこまで把握してたのか、明言を避けた
- 曰く、以前のサイバー攻撃では他のコンピュータへの影響は限定的だった、と
- 今回のサイバー攻撃は物理的破壊をもたらすものとして初の試みだった
- システムの動作を遅らせるとか、データを盗み出すといったレベルを超えた作戦だった、と
- 今回は「ルビコンを渡った人が出た」
- Natanzの施設へどうやってワームを仕込むか
- 攻撃第一弾
- 小規模
- 2008年
- イランの核施設が制御不能に陥った
- イラン側は原因を探り、彼らの動きをアメリカは傍受した。この攻撃の関係者曰く
- 不良品のせいだ、エンジニアが下手クソだからだ、計画が不完全だから、がイラン側の反応。ワームの可能性は視野に無し
- イラン側は原因を掴ませなかった成功要因
- ワームは数週間潜伏し、施設の通常稼働の様子を記録していた
- ワームは攻撃を開始すると同時に、施設の制御ルームへは「平常通り稼働中」という偽のシグナルを送り続けた
- ここがこのワームのコードの優れた部分、と当時のアメリカの関係者が回顧してる
- その後、ウィーンに本部のあるIAEA（国際原子力機関）にイランが不正な原子力利用を進めてるという噂が伝わり、査察団を送り込んだ
- 今回の攻撃参加者の証言
- 施設稼働の失敗によってイラン側が自分らには手の負えない技術だと考えるように仕向ける。これが狙い
- 施設のいくつが攻撃によって機能不全に陥ると、164台のマシンに接続してる指令室を全閉鎖し、サボタージュを疑って調べ回った
- イラン側は過剰反応してた
- 施設現場で多くの人が解雇されたことを、アメリカ側は掴んだ
- 核査察官のイラン入り。Natanzの状況をカメラが映せるようになった
- 原子力機関がイラン訪問中の出来事はカメラを使って記録された
- カメラ映像から分かること
- 崩壊した施設の残骸が残されていた
- イラン政府が、過去に正常稼働した施設を解体して一掃させていた
- サイバー攻撃はブッシュ大統領の任期終了までに完了しなかった
- オバマは大統領就任前にブッシュと会合を持った
- ２つの機密計画の続行を力説
- Olympic Gameプロジェクト
- パキスタンで展開中の無人偵察機による攻撃作戦
- （補足）
- オバマはブッシュの助言に従った
- ２つの機密計画の続行を力説
Stuxnetの衝撃
- 大統領選ではオバマは個人のプライバシーや送電網、航空管制システムといったインフラへの脅威として、インターネットの問題を議論していた
- ホワイトハウス入りしたとき、インターネットの諸問題についてオバマは関心を持っていた
- アメリカの防衛力向上に資する大規模な研究を進めると、ホワイトハウスのEast Roomでの会見で高らかに宣言した
- オバマが会見で語らなかったこと
- サイバー戦争の技法についてオバマが学んでいること
- Olympic Gamesプロジェクトのアーキテクト曰く
- Situation Roomでオバマと会合を持った
- イラン国内の核製造施設群の配線網を携行した
- 配線網が大判の紙に出力されていて何重にも折り畳めれる大きさ。通称「馬用毛布」
- オバマは会合で計画続行を許可
- 許可を受け、サイバー攻撃実行
- オバマはプロジェクトを更新し、次の段階にステップアップすることを許可
- Olympic Gamesプロジェクトの過去のケースよりもリスクが高く大胆なものになることもあった
- 別の政府高官曰く
- イランが手掛けるプロジェクトのあらゆる局面を遅延化させること
- オバマ大統領は就任直後から一貫してた
- オバマ自身深く関わった。外交、制裁、ありとあらゆる重要な決定を下した
- 進行中の作戦も例外なくこの基本路線に従った
- イランが手掛けるプロジェクトのあらゆる局面を遅延化させること
- 極秘計画が外部に漏れた
- 2010年夏
- ワームの新しい亜種をNatanzへ投入した直後
- ワームは本来Natanzのマシンの外部に移動するように設計されてない
- 突如Natanzの外部に解き放たれてしまった
- 流出の知らせがCIA長官（Panetta）、Cartwright将軍、統合参謀本部長、CIA副長官Michael J. Morellの耳に入り、オバマ大統領とBiden副大統領に報告が入った
- 報告によると、ワームのエラーが原因
- このエラーによってNatanzの施設へ接続するとエンジニアのコンピュータもワームに感染してしまう
- エンジニアがNatanzを離れてからネット接続したときに、ワームはNatanzの外にあることを認識できずに、自己複製を開始して世界中に広がっていった
- 突然一般人にワームのコードの存在が知られることになってしまった
- なぜワームがこのような動きをしたのかはまだ不明なところがある
- 報告者ばオバマ大統領に伝えた内容
- イスラエル側でワームに修正を加えてる
- 漏洩報告の席上でオバマとBiden
- オバマは矢継ぎ早に質問を繰り返した
- Natanzの施設の外部でもダメージを与える力を持ったコードなのかを知りたがった
- オバマは報告者からはお役所的な回答しかで得られなかった
- BIdenは「イスラエルのせい」「やりすぎだ」と立腹
- オバマは矢継ぎ早に質問を繰り返した
- 実際にはアメリカとイスラエルは共同で作戦を実行してた
- イランの原子力施設の特定部分を標的にして、部分的な損失によってイラン側が計画を断念するように仕向けること
- これが両国の目的
- イランの原子力施設の特定部分を標的にして、部分的な損失によってイラン側が計画を断念するように仕向けること
- 誰がエラーをワームに混入させたのかはまだ明らかになってない
- Olympic Games計画漏洩後、オバマはこのプロジェクトをどうするか決断に迫られた
- ワームの複製がネット上に解き放たれた
- セキュリティ専門家が解析してこのワームの目的を特定できてしまう状態にまでなった
- 政府役人の証言
- オバマは「十分な情報がない」としつつも「計画続行」を命じた
- アメリカの対イラン政策
- ワーム漏洩から一週間しないうちに、新型ワームがイランの1000の施設へ投下された
サイバー兵器の今後は不透明
- 今のとこイラン限定。だが今後もそうなる保証ゼロ
- 政府役人曰く
- 特定国家にだけサイバー兵器を使ってきた
- 複数の政府役人曰く
- サイバー兵器を北朝鮮に積極的に使わないんだ？
- 別の役人曰く
- サイバー兵器あれば色々チャンスが巡ってくる
- 中国の軍事計画を頓挫させる
- 民衆暴動と政府による弾圧の続くシリアを鎮圧できる
- 世界展開されてるアルカイダの動きをブロックできる
- 元CIA局員曰く
- 計画中の規模よりも大規模にサイバー攻撃の展開を検討してる
- オバマが補佐官へ曰く
- サイバー兵器には、使い続けること（濫用されること）にリスクが常にある
- インフラにコンピュータシステムを使ってない国はない
- 全ての国がサイバー攻撃に程度の差はあれ脆弱性のリスクをもつ
- アメリカのインフラはリスクがとても小さい
- 多くの専門家の見立て
- アメリカを矛先にしたサイバー攻撃がどのみち登場
Avichal Garg「チートして成功するスタートアップ」
Avichal's blog 2012.4.8のエントリ
Startups Win by Cheating « Avichal's Blog
- 元GoogleでPrepMeという教育系スタートアップを2011年にExitさせ、現在はSpoolという「後で読む」系サービスをやってる人のエントリ
- チートは釣り文句っぽく、どういう視点であれ（ビジネスになる）アドバンテージをちゃんと持っていることが大事という主旨
- アドバンテージの種類をざっくり羅列して、例題としてzyngaの人を取り上げてる
以下斜め読んだ内容
- よいプロダクト作れば他はうまく回る
- こんな風に考えてるエンジニアは多いが、現実にはうまくいかない
- よいプロダクトの必要条件だが成功の十分条件ではない
- 不公平なアドバンテージが必要
- （補足）ここでの「不公平」は「誰にでも等しく手に入らない」くらいの意味
- 不公平なアドバンテージをフルに活かせばスタートアップはたいてい成功する
- よいプロダクトあっての話だが、わずかなアドバンテージがビジネスを成功へと押し上げる
- スタートアップやってるなら、どの点で不公平なアドバンテージを持ってるかを正しく把握しないとダメ
- このタイプのアドバンテージは、参入障壁を上げたり、今後成功のために何が必要かを教えてくれる
- 不公平なアドバンテージをざっくり列挙
- 完全版じゃない
- 情報
- アクセス
- 元販売部門のVPで前の会社の顧客向けに新製品を売ろうとしてるなら、アクセスのアドバンテージがある
- 前職の顧客データな不正なアクセスといった違法なことは論外
- テクノロジー
- ビジネスにとって心臓部分になる技術のパテントを取得してるか、技術利用について正当性を主張できる立場にあるなら、テクノロジーのアドバンテージがある
- このアドバンテージを持つスタートアップはとても少ない
- 技術の正当利用の主張を安易に考え、技術の持つ本当の価値を測り損ねる傾向がエンジニアにはある
- データ
- 誰もアクセスできないデータにアクセスできる権利をもってる
- 過去にコンサルで入った会社の例
- 大手小売り会社の非公開apiに独占的にアクセスできた
- 更にその小売会社の顧客へ他社には許可されてない方法で広告を打つことができた
- リーチ
- 有名人の特権
- 無料で人々にアプローチできる
- Kevin Roseがやったこと
- Jessica Albaがやったこと
- 自分の知名度を使って紙おむつ会社を宣伝
- （補足）The Honest Company
- 事例：ZyngaのMark Pincus
- あらゆる起業家や企業には独自のチートする方法をもってる
- 時間をかけて考える起業家は少ない事柄
- 自分たちのユニークなアドバンテージはどの辺にあるのか
- ビジネス成功のためにどんなアドバンテージを獲得する必要があるのか
- この２つを把握していれば、ビジネスを軌道に乗せることがとても容易になる
- ビジネスを軌道に乗せること。これが一番難しい
Avichal Garg「教育系スタートアップがコケる理由」
Avichal's Blog 2011.10.7のエントリ
Why Education Startups Do Not Succeed
- AvichalはSpoolのco-founder
- 教育系のスタートアップがネット系のスタートアップ違ってつまずくポイントを列挙してて面白い
- お客の教育観を分かってない、教育市場は巨大だが見当違いなところにフォーカスしてる会社多い、等々
- 公文式（Kumon)が登場してる
以下斜め読んだ内容
このエントリのきっかけ
- PrepMe
- 2001年に立ち上げた
- オンラインの教育系スタートアップでは最古参
- Providence Equity Partners傘下のAscend Learningに買収されたのが、2011年
- 先月にVCに頼み込んで、教育系ビジネスへの出資について意見交換したり、起業家６人に援助を求めたりした
- そこで話した自分の考えをこのエントリでまとめる
- このエントリはあくまで私見のまとめ
- 思い切った一般化してる。教育政策、経済政策、テクノロジー、等々
- PrepMeやSpoolの公式見解と受け取らないように
始めに要約すると。。。
- 多くの教育系起業家のビジネスモデルは悪い
- 「品質」という切り口で教育ビジネスを考える
- だが平均的な人は教育を「コスト」として見てる
- 教育ビジネスが軌道に乗るプロセス
- インターネット企業の成長曲線からは乖離してる
- 20年かけて教育の問題を解決したい？だったらやりなよ、という感覚
- アメリカの貧困層への教育提供、アジアで教育系企業作る
- ここにだったらチャンスある
- アメリカの中流層をターゲットにしても見込みゼロ
- 長期的に見れば、教育への通念は変化しチャンスも広がる、かも
- ここでいう「長期」は５年単位の話
高い教育を受けた人たちと平均的な人たちでは「教育」観が違う
- VCや起業家はたいていいい教育受けてる
- いい教育受けてる人たち
- VCや起業家がたいてい該当する
- 教育＝投資と考える
- 元を取るのに20年かかる投資、と納得してる
- リターンは高いとわかれば投資を厭わない人たち
- 教育=投資と考える人は、価格に敏感でより高い品質を目指す
- ここでの「品質」は、リターンの大きさを言ってる
- サービス購入の決め手はコストではなく、品質
- 平均的な人たち
- 教育はあくまで「出費」
- 義務だから教育を受けてる
- 高い教育を受けてないことがマイナスになるような暮らしをしていない
- 2005年頃のOhioの小さい町を例に。。。
- ちなみに自分はOhio出身
- 大学出てないOhioの典型例
- 年収2.5万ドルの工場の職、妻も同じく2.5万ドルの工場の仕事、トータルで年収５万ドル
- 住宅は9万ドル、食べるのに困らない、車はローンだが月々300ドル
- とても困ってるわけでない
- 彼らの子供も似たような暮らしになる
- まとめると、住宅を変えて、食べるのに困らず、車も買えるし、週末の娯楽にも金を使える生活
- 高い教育を受けていないことが、典型的アメリカ人の暮らしにもたらす影響
- 安定した雇用が得られない
- 老後が不安定
- 病気になれば破産へ一気に落下する
- 色々悪影響あるけど、高等教育の欠如が、直接的に何かをもたらさない
- 自分たちの子供にも直接的な悪影響がない
- こういう事情から教育を出費としてみるようになる
- 厳しい現実
- 70歳で病気になれば生活崩壊する
- 年金（401k）払ってこなかったら死ぬまで働かないとダメ
- 自分の子供の能力は今後30年のグローバル市場で太刀打ちできない
- SAT受験前にKaplanのようなprep schoolに通う子どもは15％
- アメリカ人の５０％以上は高校も出ていない
- 教育への見方が根本的なレベルで違う（投資／出費）ことがとても重要
- スケールする教育系企業の条件
- 見込みゼロ
- 高等教育の提供に力点ある企業
- 成長の余地あり
- お客が支払うコストを減らしていくことに力点置いてる企業
- 見込みゼロ
- 具体的に教育市場から何社かピックアップ
- Chegg
- 教育系スタートアップ
- 評価額１億ドルで、急成長
- 教科書から得られる効果をより安く売ることに力点
- 2011年頃から教育版Netflixがブームに
- DVDレンタルをNetflixが駆逐していったのを連想させてる
- 夢のテキストブック
- デジタルでパーソナライズされ、オンラインで学習できて、タブレットでできる、インタラクティブ、ソーシャルなテキストブック
- まだ実用化されてない
- University of Phoenix
- 学位取得の敷居を下げようとしてる
- 利便性の提供
- 政府系ローンの支援を取り付けてる
- お客がサービス受けるかどうか（金を払う価値があるかどうか）を決めてる
- お金は最終的には政府が責任を負う構図
- BtoCではない。マーケティングに力入れてる
- 地方大学で取れる学位と同等の学位をより簡単に手に入れることができるようにしてる
- Harvardといった有名大と競争しない
- Phoenix大学は地方大学を競合とみてる
- 地方大学の方が学費は上で、夜間コースしかないところもある
- Phoenix大学はポッと出ではない。1976年開学し、1994年にIPO済
- Kaplan
- 元々は予備校ビジネス。ビジネスとしてあまり成功してなかった
- コンシューマビジネスで、教育の価値に力点置いてた
- Phoenix大学を手本に方向転換
- Kaplan大学でPhoenix大学のビジネスを真似して、成功
- 利便性を訴求するビジネスに転換
- 元々は予備校ビジネス。ビジネスとしてあまり成功してなかった
- K12
- 学区相手にビジネス
- 他の子どもよりコストの高い子どもへの費用をカットする仕組みをK12は提供しようとしてる
- 特殊な要件のある生徒、才能ある生徒、地方の生徒、等々
- 中東やアジアでビジネス展開してる
- Chegg
- 通常のインターネット企業のスタイルで教育系ビジネスやってるところもある
- Tutorvista
- オンラインの家庭教師サービスとしてローンチ
- 先生はインド在住の人を使って、英語圏の人にサービス提供
- 月額99ドルの利用料
- 検索エンジン対策に大金
- 数千万ドル単位の収益。IPOには足りない
- ビジネス転換し、インドに教育センター設立
- 2億1300万ドルでPearsonが買収。この規模の買収はインドでは初
- Tutor.com
- 10年前にローンチ
- オンライン家庭教師ビジネス
- ５ラウンド連続で出資受けたが軌道に乗らず
- 路線変更し、ニッチな市場に活路見出してる
- 図書館、学校など政府系の顧客をターゲットに
- GlobalScholar
- Drugstore.comのCEOが始めて、コンシューマ向けビジネスとしてローンチ
- 成功しないと気付いてデジタル版通信簿をよそから買い取ってきた
- のちに学校関係に流通販路持つScantronが買収
- 教育の品質にフォーカスして、瞬く間に100万ドル以下で収益頭打ちになった企業の例はたくさんある
- 自分たちが暮らす街の教育センターが10くらいあるとしたら、それぞれが年100万ドルくらいの収益
- （ローンチ直後の収益を支える）アーリーアダプター層の見方と大多数の人たちの見方が根本的に違う
- Tutorvista
脱線：アジア系、貧困層であれば話が変わってくる部分がある
- アジア各国に住んでて教育をちゃんと受けてないなら、生活は困窮してるはず
- 困窮の原因は部分的には文化的
- 社会資本がなければ教育を受ける余地がない
- 困窮の主原因は経済的なもの
- 教育をうけてなければ、ありつける仕事は単純労働系になり、子供のために十分なお金を回すことができない
- この困窮の意味合いは、中国で暮らす人とKansasで暮らす人を比べると明確になる
- 中国で教育を受けてないことがもたらすこと
- 職が得られない
- 貧困にあえぎながら死ぬ、子どもに十分食べさせることできない、親の面倒見れない
- 中国では、若者が家族の年配層を養うべしという家族モデル
- 中国で教育を受けることが豊かな生活への手がかりになってる
- コールセンター、銀行、政府系機関、軍隊への就職への門戸
- 貧困にあえいだ親世代は子どもには良い暮らしを得るチャンスを与えようとする
- Kansasで大学を出てない人は優雅な暮らしや安定老後はおそらく手に入らない
- だが、自身も子供も自分の親も餓死したり、ホームレスになるということはまずない
- 中国人に見て取った「学歴無しが貧困に直結する」という感覚は、移民であるアジア系アメリカ人の間にも広まってる
- もちろん、アジア系アメリカ人共通ではないが、この感覚が広く共有されてるのは見て取れる
- 中国で教育を受けてないことがもたらすこと
- アジアで一般消費者向けに教育系ビジネスを立ち上げるとき、ビジネスを軌道に乗せてスケールさせることができる
- MegaStudyとKumonはその好例
- アメリカではうまくいかないのは、アメリカにはアジア系アメリカ人の数がそれほど大きくないから
- 貧困も教育に対する考え方を変える
- 面白いデータ
- アメリカで新しい事を始めるのに積極的なのは貧困層というデータ
- アメリカ貧困層の動機づけの構造はインドの田舎の人たちとよく似てる
- アメリカ貧困層もインドの田舎の人たちも「困窮」が通常の状態
- 何か劇的なことを始めないと困窮がそのまま継続する
- 親や教師はこのことをよく理解してる
- 何か劇的なことを始めないと困窮がそのまま継続する
- 貧困層のコミュニティでは奨励されるのは、新しく実験的要素の強いことを試すこと
- オンラインスクールやチャータースクール、学期の延長、夏休み撤廃、co-op（産学連携の教育）
- 「うまくいかないかも」と感じても手を付けてしまう
- 現状の困窮を劇的に変えるものを求めてるから。だから積極的に手を出す
- 出口のない困窮からの脱出には、高品質なものをやらないとダメ、と思ってるから
- 貧困層向けのビジネスのポイント
- 貧困層の一人一人は十分なお金を持たない
- 貧困層コミュニティにある学校などをターゲットにする
- エンタープライズ型のビジネスに似てる部分あり
- Kumon
- 評価額10億ドル以上
- アジアでローンチし、フランチャイズモデルで、教育を受けた家族をターゲットにしてる
- 学生が出かける場所であり、学生を監督する場所を提供してる（ある意味ベビーシッター的）
- 抱える学生数420万人
- アメリカでは少ない。20万人くらい
- Khan Academyの利用者層
- Quantcasが出してるデータ
- 高等教育受けてて、補助教材を探してる人
- 貧困層（ヒスパニック系、アフリカ系とほぼ一致する）
- アジア系
- 教育市場は数十億ドル（数十兆ドル）規模
- 長期的スパンで考え、今後25年で有意義なものを作ろうとしてる人には、チャンスはたくさん
- 落とし穴色々
- よいプロダクトによい結果が自動的についてくると、信じてはダメ
- プロダクトをより安く提供していくことには成功の可能性が高い
- この辺は高度な教育を受けた人が嫌がる部分
- 先進国・欧米国でビジネスをスタートさせてはダメ
- 飽和気味。一般消費者をターゲットにしてるなら、アジアは見込みある
- VCから出資受けてはダメ
- ビジネスの成長曲線がスタートアップ一般と違う
- ビジネス初期にVCが思い描くものと乖離してる
- まずは、従来と違うことを教育分野で見てみたいと考えるエンジェル投資家から出資してもらうのがいい
- 次に、1000万ドル収益が見込める目途が立ったらになったらprivaty equityを受け入れる
- ベストは、praivaty equityに頼らず、キャッシュフローだけでビジネス回すこと
- 成功する教育系ビジネスの多くは、private equity抜きでやってる
- 中流層をターゲットにしてはダメ
- 困窮して新しい打開策を渇望してる貧困層をターゲットすべし
- 中国・インドの家庭をターゲットにすべし
- 彼らの教育費を半減させることができるはずだから
- 高い質の教育に対して金の糸目を付けない人たちをターゲットにすべし
- 急成長を絶対に期待しない
- 20年かかる
- ネット起業を同列にできない
- 収益が1000万ドルに達するには相当の時間が
- そのレベルに到達したら、ブランディングしていくべし
- 教育産業は小さいので良いサービスはすぐに広まる
- 最後におすすめのエントリ
- このエントリで書いたことでなかなか信じてもらえ無さそうな部分を補強してくれる統計データとかもある
- Preparation for College Admission Exams,2009 NACAC Discussion Paper
- （補足）
- リンク切れ。web.archive.orgにキャッシュ
- Preparation for College Admission Exams
- （補足）
- Educational Attainment in the United States: 2009 - Detailed Tables
- Private Household Spending on Education & Training
- More Money spent on Education and General Problems with Education in Korea
- （補足）
- リンク切れ。web.archive.orgにキャッシュ
- Joe S e o u l m a n: More Money spent on Education and General Problems with Education in Korea
- （補足）
Paddy Moogan「ウェブページの最適化をやり遂げるには（ECサイト編）」
SEOmoz 2012.4.29のエントリ
Perfecting On-Page Optimization for Ecommerce Websites | SEOmoz
- ページ単位で行うSEO対策やコンバージョンUPのためのチェックリストの決定版は2009年に書かれてる、けど3年たったので最新版を作った、ただしECサイトに話絞って、という主旨のエントリ。
- アドバイスのよくあるパターンは、「SEO効果は少々、でもCVRアップは期待大」、「だからやっとけ」
- 派生パターンとして「SEO効果少々、でもUX向上」「だからCVRアップ有望」、「だからやっとけ」
- 翻訳あり。ただし不正確＆ノイズ多い
- SEO的に見た、ECサイトで「あなたが取り組むべき１５のページ要素」2012年版 - webマーケティング入門
- 論旨が掴めない（原文読んだきっかけ）
- 原文は定点観測としてinformativeなエントリだった
- 翻訳では、理由を割愛して説得力に欠ける話に転化したり、全く別の話になってたり、留保つきで主張してることが断定になったり、ゆえに歯切れの悪い部分が問答無用の断定になってる。
- コメント欄でもエントリに載ってない手法について質問が出て、それにPaddyが丁寧にリプライしててinformative
以下斜め読んだ内容
- はじめに
- このサイト(SEOmoz)の公式見解ではない
- 2009年（？）にRandが書いたエントリ
- Perfecting Keyword Targeting and On-Page Optimization
- SEOmozの人気エントリの１つ
- 未だに引き合いにだされること数知れず
- ページ単位の最適化がテーマのエントリ
- エントリのコアの部分は今なお有効
- ただし、追記した方がいい内容がある
- 追記した方がいい内容を、ECサイトに限定して列挙してみるのがこのエントリの主旨
- ECサイトの商品ページのパーツを１５に分類してみた
- (1)カスタマーレビュー
- ECサイトやっててカスタマーレビューを付けてないなら相当損してる
- カスタマーレビューは重要なフィードバック
- ビジネスを改善していくのに必須の情報が詰まってる
- カスタマーレビューはユニークなコンテンツ作りの源泉でもある
- 商品数の多い大規模ECサイトであっても商品ページそれぞれにコンテンツとして追加できるから
- ユニークでない商品ページがカスタマーレビューが追加されてユニークなページになる
- 基本tips
- お客へ購入後数週間後に商品レビューを依頼するメールを自動的に出せるシステムを用意
- 買うか、作る
- メールでレビュー依頼する体制をスタートし、できるだけレビューを獲得できるように手を打つ
- 進んでお客がレビューに協力してもらえるように、インセンティブを用意する
- 次回購入時に使える割引券とか
- レビューの内容が非難や文句であっても心配しない
- お客はアホじゃない。レビューが好評価だらけのサイトにお客がどう思うか考えてみるべし
- お客へ購入後数週間後に商品レビューを依頼するメールを自動的に出せるシステムを用意
- レビューがまだ無い商品ページ
- 「レビュー無」「レビュー希望」等が表示されてる商品ページ
- この状態はCVRに悪影響あるかも？という心配する人たちあり
- まずレビューエリア全体を非表示しておく
- レビューが一定数獲得したらレビューエリアが表示させるようにページ設計
- もちろん現在の環境では無理なケースもあるが、できるかどうか調べるべき
- レビューデータのマークアップにも気を配る
- マイクロデータのフォーマットに準拠したマークアップ
- googleがコンテンツを解析するときに、コンテンツのコンテキストとして活用してもらえる
- 検索結果ページでの表示内容がリッチになる
- おすすめ度、レビューア、レビュー抜粋なども並べて表示されるようになるため
- マイクロデータ付で表示されるようになれば、CTRアップに貢献できる（かも）
- レビューをmicroformtsに準拠してマークアップすること自体は広まってる
- microformats使うことが差別化にならないかも。もしくは使わないことが差別化になるかも。
- (2)商品紹介動画
- 最適化は一筋縄でいかないが、成功したら大きい
- 動画使ってるECサイト増えてるが最適化からほど遠いのが大半
- 手本はZapposの商品ページ
- 5万本の商品動画アップしてる
- 検索結果での表示内容も動画のサムネイル入りになって他と差別化できてる
- 動画の埋め込みやりかたを正しい方法でやってる
- 商品ページに動画載せるメリット
- リッチなコンテンツにする近道
- よい動画はCVRアップに貢献できる
- 専門性のある商品だと商品動画はCVRに貢献しやすい
- データや証拠つきで力説したい所が、そういうデータ等は持ち合わせない
- 動画埋め込み最適化でおすすめサービスがWISTIA
- 動画のホスティングサービス
- ページへの動画埋め込みと最適化をサービスにしてる
- ちなみにSEOmozもWiSTIA使ってる
- 自社（Distilled）でも何回か使ったけど、スニペットがすぐ手に入って導入簡単だった
- サービスの安定や機能追加等をスピーディにやってるサービス
- 動画の最適化でおすすめエントリとスライド
- 脱線：paginationの最適化
- ボリュームのあるコンテンツをどうやってページ分割するか
- 取り組む問題色々
- 分割したページをクロールされ、定期的にインデックスされるように設計
- ページ分割されたページのランキングやページからページへのリンクの重み付け
- rel="next",rel="previous"と、"view all"
- 2009年時点で存在しなかった、pagenationの最適化テクニック
- googleが奨励。やり方までブログで説明してる
- Official Google Webmaster Central Blog: Pagination with rel=“next” and rel=“prev”
- Official Google Webmaster Central Blog: View-all in search results
- googleへ分割されたページの関係を適切に伝える
- 分割ページ群の中で起点となるページへのリンク重み付けをgoogleへ伝える
- 他にもpagination最適化テクニックあり
- Adam Audetteのエントリはおすすめ
- Official Google Webmaster Central Blog: View-all in search results
- 脱線：microdata, schema.org
- (3)Q&Aコンテンツ
- 2009年頃には無かった要素
- 商品に特価したQ&AコンテンツがECサイトにとって価値がある
- 「ユニークなコンテンツ」作りをサイトが大規模サイトになってもキープし続けること
- ECサイトの大変な所の１つ。
- カスタマーレビュー同様、ユニークなコンテンツの助けになりうる
- オール自作でないuser generatedなQ&Aコンテンツであることが重要
- Q&Aコンテンツをクローラーがアクセス可能にしておく
- Q&AコンテンツはCVRアップに貢献しうる
- 質問への回答にお客が満足できるものなとき
- 商品のファンに活躍の場を与え、彼らが進んでお客に疑問に応えてくれる動機付けを強化、しうる
- はやりのゲーミフィケーションの実例、になりうる
- Quoraは？
- 商品のファンが未購入者を自発的に啓蒙していく場所として、Quoraは最適
- オレオレ予測
- 今後Quoraクローンが今後ECサイトオーナーの欲しいものリスト入りする
- この手のQ&Aサービスは「ユニークなコンテンツ調達」にとって重要な鍵になる、かも
- (4)ソーシャルボタン
- ECサイトのゴールはお客に買ってもらうこと
- tweet/likeしてもらうことではない
- お客の意識を買い物から逸らすことはしない方がいい、と思う
- ECサイトでのソーシャルボタンの使いどころ
- ソーシャルボタン関連で面白いアイディアあり
- お客のSNS利用を逆手にとったCVRアップを期待する類のアイディア
- 実務で試したことないが検討してる
- サイトを訪問したお客がtwitter/facebook/etc.へログインしてるかチェック
- Detect if visitors are logged into Twitter, Facebook or Google+
- ログイン／ログオフによってメッセージをカスタマイズとかできる
- 「likeしてくれたら割引します」といったお客へのオファーがスムーズにできる
- likeもゲットできて、割引クーポン提供後にCVRもアップするかもしれない
- ECサイトのゴールはお客に買ってもらうこと
- 脱線：ページの速度
- 2009年のSEOのチェックリストに無かった項目
- SEOに限らずページ速度はサイトにとって重要な要素
- 2010.4.9にgoogleはサイト速度を検索順位アルゴリズムに組み込むと発表
- サイトの速度はCVRに影響を及ぼす
- お客は商品ページが表示されるのをいつまでも待ってくれない
- ページ高速化がCVR改善をもたらしたというwalmartのデータもある
- 4 awesome slides showing how page speed correlates to business metrics at Walmart.com
- （補足）2012.2にSan Francisco開催されたmeetupでebayのチームが話した内容（Real User Monitoring @ Walmart.com: A Story in 3 Parts）をダイジェストしてる記事
- ページ表示時間1秒以下の時のCVRとの比較。２秒以内だとCVRは半分以下にダウン。３秒以内だとCVR当初の20%に。４秒以内だと10%強まで下がる。
- 4 awesome slides showing how page speed correlates to business metrics at Walmart.com
- ページ高速化は検索順位（SEO）よりもCVR改善を意識して取り組むべき
//open graphタグサンプル <meta property="og:title" content="クライアント・サイド・スクリプティング with Web Standards" /> <meta property="og:description" content="英語エントリ斜め読み。hackner news、node、spdy、js、高速化tips" /> <meta property="og:type" content="article" />
- 脱線：Open Graph Protocol
- これも2009年のSEOのチェックリストに無かった項目
- head要素内に入れるmeta要素の１つ
- CMS等で自動生成対応できる部分なので対応しやすい
- ECサイトにopen graphのタグを入れてくメリット
- open graphタグとSEO関連でおすすめエントリ
- Web developers cheatsheet for open graph tags
- これも2009年のSEOのチェックリストに無かった項目
- How to optimise Facebook open graph tags
- call to action
- conversion rate
- ターゲットから特定の行動を引き出せるか
- 買ってくれる、資料請求してくれる、アンケートに協力してくれる、etc.
- sem/seoでecサイトへのトラフィックを稼ぐ
- あくまでゴールは購入してもらうこと
- トラフィックは同じでもCVR改善すれば収益アップできる
- 商品ページ
- ECサイトで最重要ページ
- 商品ページのCVR改善のためのてこ入れを明示的にやるべき
- CVR最適化やったことない。。。。
- だとしても、現状どうなのかは最大限データ収集すべき
- CVRの測定と改善に役立つツール色々ある
- Crazy Egg
- ClickTale
- google analyticsのevent tracking
- seomozのチュートリアルエントリあり
- Google Analytics Event Tracking to Monitor Calls to Action
- CVR測定ツールを
- (10)タイトルテキスト
- 開発時のテンプレート
- 「商品名」と「CVR対策文言orUSPテキスト」
- 例「MacBook Air - 全品送料無料」
- 検索結画面に「送料無料」と表示されれば、クリック率アップになる（かもね）
- 重複ゼロがここでは最重要
- titleやdescriptionをはじめとするメタデータ
- 同じテキストが複数のページで使われていないかどうか
- 脱線：descriptionテキスト
- SEOではなくCVR改善狙いで最適化すべき
- 検索順位への影響力はとても小さい
- 検索結果画面でのクリック率アップにフォーカス
- CVRアップにつながる情報いれる
- USPテキスト
- (11)商品説明テキスト
- ユニークに。メーカーからもらったテキスト丸写しはNG
- 他のECサイトのテキストと比較して差別化されないとダメ
- 送料無料とか最安値等のUSP情報を入れてく
- 時間をかける
- (12)ページURL
- SEO基本事項
- カテゴリやサブカテゴリはURLに入れない
- ある製品が複数のカテゴリに入るケースではとても重要
- 重複コンテンツを生まないために必要
- 「rel="canonical"」を使って検索エンジンにオリジナルを通知。解決策ではあるが理想ではない
- よいURL
- 例。www.example.com/product-name-12345
- 商品名と商品コードだけ入れる
- よく似た商品が複数あるとよく似たURLになってしまう可能性
- その保険として、商品コードも入れとく
- ペナルティにはならない。けど避けるのが無難
- (13)h1要素のテキスト
- (14)電話番号
- (15)会社概要
- 特定地域（横浜、名古屋市、etc.）がターゲットの場合に重要度アップ
- 会社の所在地情報をgoogleへできるだけ多く情報を出すと、地域関連のキーワードでの検索順位アップにつながる
- schema.orgのフォーマットでマークアップ
- 会社情報はサイトの信頼性の目印の１つでもある
- googleにとって。かつ、ユーザにとって。
- 最後に：eCommerce SEOの良記事3本
- コメント欄
- Q：ソーシャルボタン導入の効果ってない？「abc.comで＊＊を買った」というポスト/tweetが流れると、効果ありそう
- A：商品ページにボタン付けてseo/CVR面で効果あると言い切れるか微妙
- proありconあり。向いてる商品、向いてない商品あり。という程度の認識
- Q：商品比較サイトからのトラフィック増のための最適化を追加しては？
- Google Product SearchとかBing ShoppingとかThe Find
- 検索結果の絞り込みオプションで「送料無料」や「google checkout」対応、とかがある
- ECサイト側で送料無料やってて、決済手段としてgoogle checkout対応してるなら、それに対応してることを比較サイトへ通知すれば、トラフィック増になるはず
- A：このエントリの候補に入れてたが最終的に割愛したトピック
- 異論なし。対応できるなら、した方がいい
- Q：ページ最適化にはA/Bテスト（スプリットテスト）は外せないのでは？
- レイアウト、配色、ボタンのサイズ、ソーシャルプラグイン系の有無
- テストしてCVRが優秀なのを採用していくというプロセスが重要だと思う
- A：同意見
- 商品ページの要素配置では重要になってくる。配置される要素が多いから
- どんな要素の配置が「お客が財布からクレジットカードを取り出す」行動を一番引き出せるか
- これを知る助けになる
- Q：脱線だが冒頭のモックアップはBalsamiqで作った
- A：その通り
- Q："view all"はlink要素の属性値にはないからrel="previous"やrel="next"と同列に書くのはおかしいのでは？
- A：同意見。エントリでは役割が共通してるからひとまとめにしてるだけ。
- Q：facet navigationも追加したら？
- （補足）amazonにあるような「送料無料」「1000円〜2000円」といった情報を切り口（facet）で絞り込んで必要な情報へ辿りつかせるやつ
- A：割愛したトピック。別エントリで書くかも
- Q：商品が数千あるから商品説明をプログラム使って作りたい。ユニークなテキストになるように設定して
- A：オススメしない。テキスト量産ソフトでいい線言ってるソフトも中にはあるけど、自動生成系は結局チェックしないとだめだから。
- Q：zapposがやってるような検索結果ページからカテゴリページへのリダイレクトはどうか？
- A：いいアイディア
- 注意点。大規模サイトで実装すると、サイトの速度低下の要因となりバックエンドに負荷。解決可能な問題だが。
- Q：最適化に着手する優先順位があるのでは？
- 大量の商品を扱うECサイトだったら、一番利益出してる商品ページから着手すべしとクライアントにアドバイスしてる
- A：同意見
- おすすめは、上位だがトップ３入りしてないページから着手すること。即効性があるから
- Q：カートに入れたけど買い物を止めたユーザをターゲットにして出されるメッセージやヒントが嫌いなんだが。。。。
- amazonとかがやってる。「お買い物が完了してませんよ」とメッセージ出すやつ
- それ以外のヘルプメッセージやヒントは基本的に肯定派
- A：いい指摘
- クライアント（＝ECサイト運営）曰く、その手のメッセージに対してお客は気にしてないどころか歓迎してる
- 「気にしてないどころか歓迎されてる」というのは正直意外だった。尤も、実装は慎重に行うべきなのは変わらない
- Q：値段はページのどこに表示したらいい？
- A：場合によりけり。A/Bテストで最適化していくのが向いてるトピック
- 「定価」「割引後の価格」と並べることだけは避けるべき
Mike Belshe「HTTP Speed+Mobilityレビュー」
belshe.com 2012.3.29のエントリ
Comments on Microsoft’s SPDY Proposal « Mike's Lookout
MSがIETFへ出したHTTP Speed+Mobilityへ、SPDYの仕様の作者の一人による項目別の寸評
- MS案とSPDYの違い等がピンポイントで分かって有益
以下斜め読んだ内容
- MS案ではコア部分はSPDYそのまま
- SPDYから取り込まれてるもの
- 多重化
- リクエストの優先順位コントロール
- 圧縮
- フレームのシンタックスもSPDYそのまま
- SYN_STREAM
- SYN_RESET
- SYN_REPLY
- HEADERS
- SPDYから取り込まれてるもの
- SPDYはwebsocketより古い歴史
- 「HTTP Speed+Mobility」では、シンタックスをwebsocketに似たものへ修正してる
- プロトコル面でSPDYと違いを生み出す変更ではない
- この修正でSPDYと他のWebテクノロジーとの類似性が強まった
- シンタックスか。他のプロトコルとのシンメトリーか
- 自分はシンメトリーを重視する派
- websocketsのシンタックスはSPDYより複雑、だと思う
- まあこれは枝葉の話
- MSの提案は成程と思うし、こういう動きがMSから出ること自体うれしい
- MS案ではFlow Controlを削除された
- クライアントから10ストリーム投げたとする。そのうちの１つが詰まったしたときに、flow controlが実装されてないと困る
- 全部のストリームを終了させてメモリを解放する。もしくは、残りのストリームも詰まらせるか。２つの道しかない
- TCPのflow controlとSPDYのflow controlは別物
- SPDYの初期ドラフトではFlow Controlがなかった
- SPDYを実装してみて始めた得た知見
- flow controlが必須であり、パフォーマンスにも優れ、シンプルになる.
- 従来のプロトコルの理論からは得られなかった知見
- クライアントから10ストリーム投げたとする。そのうちの１つが詰まったしたときに、flow controlが実装されてないと困る
- 実装しないと分からない話もある
- HTTPの仕様はオプションの山
- pipelining
- chunked upload
- absolute uri
- オプションになると実装されず、利用されないという流れができる
- MS案にはベンチマークがない
- MS案の本当の所の性能がわからない
- MS案ではヘッダ圧縮がオプションに修正されてる
- モバイル環境では致命的な修正
- MSがモバイル向けに最適化考えてたら圧縮についてもっと考え直すはず
- 正直ヘッダ圧縮を仕様から削除する人の考えがわからない
- webの中では意見の収斂がみられるが
- MS案ではSETTINGSフレームが削除されてる
- これはMSの失点だと思う
- SPDYのスペックではクライアントから際限なくリクエスト投げれる
- サーバー側ではクライアントからのリクエストを制限してたい場合がある。
- サーバー側からSPDY接続を制限するためにSETTINGSフレーム使う
- MS案ではserver pushがオプション扱い
- SPDYでもserver pushは色々意見分かれてる
- 削除派の言うことにも一理ある
- だが「オプション扱い」という案はケリの付け方として最悪
- 削除しないでオプション扱いにするのは、実装への負担が大きくなり、何もよい結果をもたらさない可能性だってある
- MS案の作者は、server push=オプション使いでメリットあるよ、と謳ってるが。裏付けになるデータ、ベンチマークない
- MS案ではIP poolingが削除
- MS案でSPDYコア部分が取り込まれてる点は、HTTP2.0でSPDYのコア部分は取り込まれることが有望な証拠
- MS案からSPDYに出されてる懸念点は尤もなもの
- MSはMS案について十分テストや検証してないのは明確
- SPDY側は、その点色々データ揃えてる
- なので意見の異なる部分はそのデータをもとにあっさり収束するはず
- コメント欄
- Q：圧縮+ssl暗号化環境になるのでデバッグ超大変。デバッグ用にヘッダ圧縮をオフにする機能はメリットあると思うが。
- A：デバッグ目的でヘッダ圧縮をオプション扱いにするのは、一理ある。
- Q：SPDY=SSL必須もMS案との違いでは？
- A：誤解あり。SPDYのスペックではSSLは強制されない。SSLにすべきだと思うが、その辺は利用者にゆだねられてる
- Q：TLS強制だとCA認証まわりが大変
- A：「実装必須ただし利用は自由」という位置づけで全く使われず消えた技術がたくさんある。Pipeliningとかchunked uploads。
- With specific regard to compression, we know that only about 70% of compress-able content is compressed. The rest is just sad, because it hurts the net, it hurts the users, and it hurts the sites. If we let header compression be optional, I see no reason why it wouldn’t end up like the myriad of mandatory-but-optional features that went before and are no longer usable.Regarding your objections on TLS – there was a time people said an entire HTTP stack was too much for small embedded devices. It’s just not true anymore. Also – keep in mind you don’t need general CA support for all TLS in embedded devices. Bake in the cert you expect on your server with an infinite lifetime and be done with it. If you’re not worried about authentication (or were otherwise willing to settle with HTTP anyway), you’re done.At the end of the day, we shouldn’t decide yes-or-no for security based on technical principles for small devices. We should be deciding for security because we think its necessary for users or not. I think it is necessary, and it is clear that when it is optional, too many people don’t know better and opt out – creating the unsecured world we live in now.
- Q：圧縮にgzip使ってるけど、gzipより速いの最近いくつかある。 Snappy、QuickLZ、LZO
- A：「速い」は多義的で何を指してるのかわからないが。。。
- ファイル圧縮時間、データ転送時間、ファイル解答時間。
- ちゃんとしたベンチマークみたことないから、検討してない。もし検討したとしてもパテント系で面倒なら避ける
Scott Gilbertson「TwitterがSPDYサポートしたらしい」
- wired.com webmonkey 2012.3.9の記事
Twitter Catches the 'SPDY' Train | Webmonkey | Wired.com
以下斜め読んだ内容
- api.twitter.comへの通信にSPDYが使われてる
- （補足）2012.4.5時点でoffになってる
- SPDYおさらい
- "speedy"と同じ発音
- HTTPを代替するもの
- ページやファイルをネットでリクエストするときHTTPが使われる。サーバーの応答もHTTP使う
- アドレスバーの頭がhttpで始まる由縁
- SPDYはプロトコル
- SPDYの起源
- FirefoxでもSPDY使える by Fx中の人
- Fx11から
- Fx11はデフォルト無効なので"about:config"から"network.http.spdy.enabled"をtrueにする
- たぶん、Fx13はデフォルト有効に
- Twitter / @chrisblizzard: @snackfight @webmonkey SPD ...
- HTTP2.0の仕様にSPDYが取り込まれる、かも
- IETFのhttpbisワーキンググループで検討されてる
- SPDY Protocol draft-mbelshe-httpbis-spdy-00
- デスクトップブラウザの4割でSPDYサポート
- ChromeとFxでそれくらいのシェアになる
- Browser market share
- twitterのような大規模サービスが使い始めると影響大きい
- 他のブラウザでもサポートされるんじゃない？
- サーバー側でもSPDY実装したい？
- apacheだとmod_spdyがベータリリースだけどある
- Performance Calendar » Introducing mod_spdy, a SPDY module for the Apache HTTP server
- コメント欄
