[etc] : オンライン広告におけるアトリビューション分析の必要性
オンライン広告の評価 ダイレクトレスポンスといったオンライン広告配信を行い広告Clickからの次のActionを求めるような商材の場合、CPA(Cost Per Action/Acquisition)、ROAS(Return On Adevertising Spend)というCOST指標を用いて広告Vendorやキャンペーン評価を行うのが一般的である。この指標を出すためにConversion数(Action数/Acquistion数)を計測が必須で、InternetUserがClickした広告と紐づく直接Conversion、広告はClickせず表示のみを行ったアシスト数の間接Conversionに分けられ、現状ほとんどの広告主が前者の直接Conversionのみを見てCOST指標を評価している。直接Conversion数を出す際によく問題として発生するのが、広告主側でのConversion計測と各広告配信Vendorのレポート数に乖離が発生してしまう点である。乖離の発生原因は直接Conversion計測のやり方と定義の違いである。
まずはConvesion計測のやり方の違いについて言及する。広告主側では広告効果測定ツールというものを導入しており、広告のクリックURLやパラメータに配信Vendorを識別するものを含めInternetUserの広告Click後Conversion完了するまでその識別子を引き回して計測する。こうすることによってどの配信Vendor経由で直接Conversionに寄与したか判別可能となる。その一方で各広告配信Vendorが計測できることは自身が配信した広告のLast Clickと直接Conversionが発生した事実のみで、InternetUserにおける本当のLast Clickというものを各配信Vendorの計測はできていない状況にある。
次に直接Conversionの定義である。各配信Vendorは自身が配信した広告のLast Clickから規定日数以内に直接Conversionが発生したかを計測している。この規定日数が配信Vendorと広告主で異なり、更にはConversionとして認めるInternetUserの属性(新規Userのみ認め、リピーターは除外する)も影響する。この定義差を埋めるために配信VendorのAccount Executiveが配信レポートを提出する際に極力広告主側の定義に合わせているが、それでも上記の計測方法が異なるので完全な一致にはならない。
ダイレクトレスポンスにおける広告配信Vendor間の競合 広告主は複数の広告配信Vendorを利用している事が多く、ダイレクトレスポンスによるリターゲティングを行っている場合は、1requestにおける配信獲得を目指してVendor間で最悪の場合同じ広告主のほぼ同じクリエイティブでImpressionの奪い合いが発生している。差別化のポイントは確実にConversionするInternetUserに対して無駄な予算を使うことなく適切なタイミングで適切な配信面に届けられているかという点になる。この背景に配信在庫に対してImpressionを幾らで入札するかというBidding Priceの精度が大きく関わっており、多くのVendorがMachineLearningを利用したBidding Priceの最適化を行っている。このVendor間の成績をCOST指標で評価してしまうと、Bidding力で勝るVendorに予算がアロケーションされて局所的な最適化が起こってしまう。局所的な最適化の一番の問題はCPAを合わせるために配信Vendor、運用者(代理店も含む)が動いてしまうので、最終的なConversion数を延ばすという点においてこれらの広告では貢献できなくなってしまう。更にこの状況が続くとオンライン広告市場全体としても喜ばしく無いはずである。どの配信Vendorも確実にConversionするInternetUserに対してはHigh Priceの最適化(局所的な高単価CPM)が行われているが、広告主として全体COSTを下げる必要があるので収益観点においては逆の立場である配信Vendor,Publisherは高単価が扱いづらいことになる。
日本のRTB広告在庫の使われ方 日本のPublisherが純広告を抱え込み広告在庫をRTB Player等に積極的にならない原因としては日本のRTB在庫利用がダイレクトレスポンスに偏ってしまっている事が考えられる。上で説明したようにダイレクトレスポンスを在庫に入れると高収益性への期待が薄くなる。各RTB Playerも広告主による焼き畑作業が続くと苦しい一方なので、今後ブランド広告を収益の軸とすることも考えなければならない。RTBの仕組みとしてブランド広告を特定のPublisherに高単価で提供するPMP(Private Market Place)等の仕組みも登場してきているので今後の注目株である。PMPを普及させるためにもRTB Player ≠ リターゲティングのようなイメージをDemand側に啓蒙しなければならない。USの方ではブランド広告をRTB在庫として扱い、収益化に成功している様子。
カスタマージャー二データを用いたアトリビューション分析 Conversionに至るまでの自然検索流入、純広告Impression、アフィリエイト広告Impression、広告Click等の複数チャネルに接触した履歴全てをまとめたカスタマージャーニーデータをアトリビューション分析では利用する。目的としては単純なCPA,ROASのラストクリックを獲得した広告Vendorの評価だけではなく、InternetUserの態度変容に対して各施策がどれだけ寄与したのかを中間指標としてスコアリングし、今後のマーケティング施策全体をどのように設計するかを考えることである。ただしアトリビューション分析がCPA,ROAS評価と比べると一気に難易度が高くなる。なぜならばオンライン施策がオフラインへ購買へどれほど起因したかのシチューエーション問題だけでなく、InternetUserを分析するのかPublisherを分析するのか、それらを対象とする分析のフレームワークやMdelingなど数理統計学の知識を必要とする。アクセス解析ツール側で分析Modeling手法を含んで可視化Solutionとして提供するものも存在するが、複雑すぎて運用者側が使いこなせていない印象がある。今後は広告Vendor側でも分析ツールやフレームワークを提供し、InternetUserの態度変容の可視化とマーケティングシナリオの自動化など運用者負荷を減らす施策が行われてくると予想される。
リンク アトリビューション分析 - アナリティクス ヘルプ
The Customer Journey to Online Purchase – Think with Google
[etc] : AdExchangeとSupply Side Platform(SSP)との違いって何よ？ JP Chaosmap 2015-2016 from Hiroshi Kondo www.slideshare.net
What is the difference between ad exchanges and supply-side platforms? - Quora 説明に困るAdExchangeとSSPの違い。ポジションレイヤー的な話だとAdExchangeもSSPともにDSPやADNetworkを束ねてPublisher側に広告を流す仕組みであり、この点だけを述べてしまうとほとんど差異が無いように思われる。また現在に至っては使われ方もほとんど同じと言える。(細かい話だとAdExchangeはDSPを束ねてSSPと接続をする場合もあるがここはあまり意識されない。) Quoraを調べていたら2つの違いについて適切な解答があり、最もupvoteが付いているものを読んでみた。結論としては作られた目的が異なる。AdExchangeは薄利なレムナント在庫を自動管理するもの、SSPは単価の高い広告を適切な在庫に流してPublisherの収益最大化を行う。以下は大体の翻訳。
AdExchangeはStock Exchangeを例としたトランザクションを促進する自動化プラットフォームである。用途としては主にレムナント在庫に使われる。レムナント在庫は余剰在庫なので価値がとても低いから人的なリソースを使わずに売りたい。AdExchangeは薄利なので配信量を多くすること頼っている。SSPは供給サイドのサービスでTechnology Platform/Service/Sales(人)のコンポーネントの組み合わせである。彼らは複雑かつExchangeとは取引をしないような大規模なPublisher,DSP,広告主と関係を保っている。Publisherとしては自身のビジネスに専念できるし、扱いたい広告vendorの数を制限できる。(しかし注意しなければいけないこととしてはPublisherはスーパープレミアムな在庫はSSPに開放せず別途持っていてインハウスのSalesチームにBig Brandとして売らせている。) SSPは広告主の沢山の広告をRealTimeBiddingによって提供するようなInterfaceを持ち、Publisher側の個々のadspotの価値を戦略的に最大化させる。SSPはDMPなどのlayerと接続可能なのでAdExchangeより多くのGross Marginを得ている。(注意しなければいけないことはSSPはAdExchangeより様々な面での高いコストを支払っている。)
Defining SSPs, Ad Exchanges And Rubicon Project | AdExchanger 上のリンクはAdExchangeとSSPとRubicon Projectの定義。以下は大体の翻訳
AdExchangeとSSPはかつては異なるものであったが段々と区別が困難になりつつあり、補完的な技術は統合されている。SSPが登場した頃、AdExchangeとSSPの違いはAdtech vendorの間ではとても重要な内容だった。デジタル市場の動きがとても速いという理由もあって特徴的な名前付けをする必要があった。SSPとAdExchangeの統合は新しいことではなく、GoogleはSSPのAdmeldとDoubleClick AdExchangeを統合している。歴史的な違いとしてはAdExchangeはトランザクションを有効にする一方で、SSPはPublisher側に価格調整機能などの多くのToolを提供してAdExchangeと同じことを行う。長い間様々なPlayerを見ていると、特定の市場空間にいる大体の会社がより優れた顧客サービスをできるようにツールの開発や機能提供を行う。Rubiconは収益最大化を目的としたSSPとしてスタートしたはずが、彼らが十分な在庫を持っていたならば、自然とAdExchangeの機能を統合している。この産業の誰もがmedia platformerであって、全てのPublisherが喜んでいない状況である。SSP,AdExchange,DSPやAdnetworkの統合は周囲(広告主やPublisher)を混乱させる。
[etc] : Recsys2015で発表されたCriteo社の最新レコメンド情報を読む RecSys 2015: Large-scale real-time product recommendation at Criteo from Romain Lerallut www.slideshare.net
criteo社のRecommendation Logic Criteo社の広告枠への配信に対するCTR/CVR予測モデルの話以外にもRecommendLogicに関する発表がRecsys2015であったので見てみました。一般的なRecommed Systemでは良く見受けられる構成や手法なのでインパクトがある内容ではありませんが共有します。Keywords : Logistic Regression, Hadoop, Memcached, collaboration filterling, Recsys2015,
Criteo社のCTR/CVR予測モデルは下記論文などを参照 Simple and scalable response prediction for display advertising
Criteo社の説明とインフラ 2005年に設立、フランスに本社を置き世界に社員1700人(そのうちEnginnerが300人)、100億のUniqUserを持つ。 秒間80万のHTTPリクエスト、29000インプレッション、RTBの処理を10ms、Recommendの処理を100msでこなす。 3つの大陸にインハウスのデータセンターが7つ。サーバー15000台、ヨーロッパに巨大なHadoop Clusterがある。35PBのBig Dataがある。 Criteo社のデータソース 商品カタログデータが広告主ごとに100万ほど。その広告主を10000社持つ。 インターネットユーザーの行動履歴のイベント数が毎日2B。 広告表示やクリックなどのイベントデータが毎日20B。 Recommend Logic やりたいこととしてはRecommendの関数にインターネットユーザーを入れた時に一番のオススメ商品が出るようにしたいが、実際のところ複数の商品が出るし、新鮮さも保たなければならない。 できることとしてはOfflineで事前に商品の推薦を選んでおき、OnlineでRecommendationを決定する。 Offlineで広告主からインターネットユーザーの行動ログを送ってもらい、商品ランキング/カテゴリ商品ランキングを定め、商品閲覧の共起から類似商品を導き出し、商品購買の共起から補足商品を推薦する。 インターネットユーザーが商品Xを閲覧した時の推薦する候補は以下のもの 閲覧した商品Xそのもの。(直接商品) 他のインターネットユーザーが商品Xと閲覧共起しているもの。(類似商品) 他のインターネットユーザーが商品Xを閲覧した上で購入したもの。(補足商品) 広告主のサイトで最も見られて/買われているもの。(売れ筋商品) System Overview 4時間おきに広告主から商品カタログデータを貰い、Memcachedに入れる。 広告主サイト側でのインターネットユーザーのイベントログを送ってもらい、商品アイテム推薦を導き出すためにHadop MapReduceにかける。MapReduceされた推薦データは12時間おきにMemcachedに入れられる。 広告表示/クリック/コンバージョンデータを6時間おきに取得し、それを基に予測モデルをHadoop上で更新する。 Recommendのリクエストが来るたびに、インターネットユーザーのデータを用いて推薦アイテムを商品カタログから参照する。 機械学習の予測モデル(おそらくクリックやコンバージョン予測)はLogistic Regressionを利用している。なぜならばLRはスケールするし、速いし、たくさんの特徴を扱うことができる。(bitのhash magicを使うなどして) Memcachedに入れられた類似商品、最も見られている商品、最も買われている商品をスコアリングして高いものから推薦する。 Recommend Logicの評価 オンラインABテストを行う際はインターネットユーザーの50%ずつにそれぞれのモデルを適用するが、これらは以下の理由により煩わしい。 すぐに多くのお金を失う。 テストの期間が長くなってしまう。信頼がおける期間は2週間ぐらい必要。 ソースコードを本番同様にしなければならない。 インフラ的に高負荷になってしまう。 広告主のアカウントがそこまで十分な時間をくれない。 その代わりとしてOnlineのログを使ったテストフレームワークがある。 しかし自分たちで管理するデータしかもっていない。(外部データは非常に高価なため) それでも私達は完全な間違いをしないことの確信がある。 Onlineのパフォーマンスを上げるためにOfflineテストの最善策を見つけなければならない。以下は参考論文 Counterfactual Reasoning and Learning Systems 今後のUpdate より長期的なUserのProfileデータを活用する。 より多く/より良い商品情報を利用する。(画像、文脈、NLP) 類似商品計算のUpdate。 商品スコアリングの結合。 私たちはClick予測のデータを公開している。 4GB display-click data : Kaggle challenge in 2014 http://bit.
[etc] : アジャイル開発の導入に向けた備忘録 SCRUM BOOT CAMP THE BOOK
作者: 西村直人,永瀬美穂,吉羽龍太郎出版社/メーカー: 翔泳社発売日: 2013/02/13メディア: 単行本（ソフトカバー）購入: 5人 クリック: 13回この商品を含むブログ (33件) を見るアジャイルサムライ――達人開発者への道
作者: Jonathan Rasmusson出版社/メーカー: オーム社発売日: 2014/06/25メディア: Kindle版この商品を含むブログ (4件) を見る
SCRUM BOOT CAMP と アジャイルサムライ このブログも勉強したことの纏めサイト的なものになってしまってきているので、体験談や自分の考えも纏められるようにしていきたいですね、、、。今回はアジャイル開発手法の1つであるSCRUMについて計画,実施,振り返りを行う機会があったので、新しいインプットとしてSCRUM BOOT CAMPとアジャイルサムライを読んでみました。過去に独自色の強いアジャイルを試したことはありましたが、コミュニケーション時間の増加および課題の明確化ができるたものの、アジャイルの学習や進行に費やした時間に対するプロダクト成果まで結びつかず途中で挫折しました。その経験からチームビルドを半ば諦めて個人の力で打開する雰囲気作りをしていた節があったので、これを機にもう一度教科書を読んでから考え直してから実践したいと思います。掲載している内容は自分の言葉で置き換えておりますのでご注意ください。
SCRUM BOOT CAMP 事前に全てを予測するのは不可能。そこから計画することはできない。 という事が前提。 要求の分析や設計には時間をかけず、重要なものやリスクが高いものから先に作る。 要求の実現順、問題点を明確化、もっと良いやり方の適応などを意識する事。 開発チームの規模は3〜9人ぐらいがベスト。 スプリントは短くて1週間、長ければ4週間。週単位で区切る場合が多い。 スプリントにおいて開発する量は過去の実績値(velocity)を元に予測。 スプリント計画で合意した内容に全力を尽くすが、完了を約束するわけではない。 スプリント単位でリリース判断可能なプロダクトが求められる。完了の定義を事前に明確化し、途中での削除は避ける。 スプリント内では毎日の状況確認。 スプリント内で出来上がった動作するプロダクトを確認する。スプリントレビューはプロダクトオーナーに対してデモを披露する。 スプリントの最後に振り返り(スプリントレトロスペクティブ)を行い、もっと成果を出すためのプランを出す。 プロダクトオーナーとスクラムマスターの兼任は避けたほうが良い。プロダクトオーナーは製品を良くすることを考え、スクラムマスターは開発を円滑に進める。 プロダクトバックログのためにインセプションデッキを作成する。インセプションデッキのテンプレートは以下にある。 https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck プロダクトバックログは全員が必ず理解する。 プロダクトバックログの工数や予算は実際に作業する担当者が見積もる。見積のズレは必ず発生するので、時間をかけずに行う。基準となる作業を見つけて相対的な見積をする。当てずっぽうの見積の中でベストを尽くす。 スプリント内で実現しようとするプロダクトバックログの量が多いと大変で良くない傾向なので、確実に終わらせる事ができる項目数を定義する。 デイリースクラムが単純な進捗報告会とならないように、問題を見つけるように工夫する。問題が出てきたらデイリースクラムの後に関係者で集まって対応を考える。 スプリントレビューではデモを目で見て、本当はどうすべきかを確認する。デモと完了の定義を比較して終わっているかも合わせて確認する。完了の定義はチーム内で合意をしていないといけない。 問題に対しては個人でなんとかしようとしがちなので、チーム全員で対応すべき。 タスクボードを使ってTodo,Doing,Doneを分かりやすくする。 バーンダウンチャートを使って縦軸に見積もり時間の合計、横軸に営業日を記録し、最終日が0になるような折れ線グラフを作る。これが理想線となり、実際のタスクの実行時間をプロットして理想線と比較する。 スプリントを旨く回すために自分たちでルールを決めても良い。 velocityに求められのは安定性。安定していないvelocityは予測に使えない。velocityを上げていくことだけを意識していくと悪影響がでる。 みんなをサポートしてプロジェクトの目的を達成していくのがスクラムマスターの仕事、サーヴァントリーダシップと呼ばれる。またスクラムマスターはあらゆる妨害を見つけて取り除く。 良いスクラムマスターだと妨害リストに50個以上項目を管理している。妨害リストはチームが見えるところに貼っておくと良い。 プロダクトバックログは日々更新されるべきで、いろいろな意見が集まるように誰でも更新できるようにしておくと良い。プロダクトバックログを観て削除できるものは優先度を下げたり諦めるなどをする。 開発メンバーのプロジェクトを進めるスキルがあるかどうかを判断するためにスキルマップを書いてみると良い。開発メンバーの性格や得意/不得意を知った上で各メンバーとこれまでどんなプロジェクトにいたか、仕事で重要視すること、期待されていることは何かを話し合っておくことも重要。 失敗を重ねて学んで行く。成長しないスクラムチームではプロジェクトがうまくいかない。失敗を繰り返さないように学んでいく。 通常のスプリントの後でリリースの前にリリーススプリントをやることも初期のスクラムチームでは採用される。リリースに必要なことを片付けるための期間。 アジャイルサムライ チームの持てる力を最大限に出すことでプロジェクトの成功確率を向上させる。 本当に価値があるものに対して集中し、余分なものは捨てて身軽になる。 アジャイル開発は気弱な人には合わず、隠すことが無い、質の高い仕事へ情熱を持つこと、価値を生み出すことを期待するのであるならアジャイルを採用することによって得ることは多い。 プロジェクトの3つの真実。1.
[etc] : WORK RULES! はGoogleでの採用やマネジメントが分かる良本 ワーク・ルールズ！―君の生き方とリーダーシップを変える
作者: ラズロ・ボック,鬼澤 忍,矢羽野 薫出版社/メーカー: 東洋経済新報社発売日: 2015/07/31メディア: 単行本この商品を含むブログを見る
内容の覚書 Googleにいらっしゃる人事担当/上級副社長？のラズロボックさんが書いた本。最近の僕のtopicsはチームメンバーと自分が同じ方向性で共に成長できるかどうかということ、それに対する経営者やリーダーやマネージャーとしてのあり方というものであり、この本でもその点に注意して読んでみた。訳者の意訳力もあるのか、かなりスラスラ読める本なのでお薦め。忙しい人は冒頭と14章だけ読んでみると良いかもしれない。最高の人材(人財)を採用しチームとして機能させるための並々ならぬ努力が読み取れる。
マネージャーはチームに奉仕し、現場の障害を取り除いてチームが躍動することに集中する。 最高の創業者は他の創業者が自分と並び立つ余地を生み出す。会社員でも自分を創業者とみなし行動する。 ミッションが個人の仕事に影響を与えるのは事業目的ではなく、道徳だからである。歴史上大きな力を振る舞った運動は道徳的な動機を持っていた。ミッションへの信頼が共有されているためほとんどのグーグラーは結束している。 社員の発言や意思決定を重要視する。(余談:中国での検索結果検閲の判断についても社員からの意見に耳を傾けた。www.google.cnはサービスを閉じたが、www.google.hkは継続している) 一般的な企業の場合は社員教育に資金や時間など力を注ぐが、Googleの場合は上位10%に入る求職者を採用し、その後の手間をかけずに済ませる。採用費用は平均的な企業の2倍ほど。 何らかの点で自分より優れた人だけを雇う。 アイビーリーグの平均/平均以上の卒業生より、州立学校をトップで卒業した聡明で勤勉な学生を採用したい。過去にやり遂げたことをに比べてどこの大学を出たかはさほど重要ではない。 単純に賢いからという理由で採用するのではなく、一緒に働く全ての人を成功に導いてくれる人を採用する。 本当に優秀な人は仕事を探していない、在籍している会社に満足しているし十分な報酬を得ている。そこでテクノロジーの力を利用して最高の人材を探し出すヘッドハンティングを行う。(gHire) 面接者は最初の5分間で評価を行い、それ以降の時間は最初の評価を確認するための時間として費やす。 人の職務能力を予測するための最善の指標は日々の業務内容と似た仕事(ワークサンプルテスト)を与えること。 自己複製採用マシーンを作成するための4つの事。1. 採用候補者の人材の質/基準を高く設定する。2. 社員が自分自身で採用候補者を見つける。3. 採用候補者を客観的に評価する。4. 採用候補者に入社すべき理由を伝える。 人材の質を確保するためにはあらゆる圧力には屈せず闘う。 「権力は腐敗する。絶対的な権力は絶対腐敗する。」権力を持つものは持たないものより道徳的規範を持たなければならない。 マネージャーの権限が少なければ少ないほどチームが取り入れるべき自由裁量の余地は増えることになる。 マイクロマネジメントはミスマネジメント。 常識はずれの野心的目標を設定して失敗したとしても、きっと何か素晴らしいことをやり遂げたことなる。 Googleでは各個人のOKRを確認することができる。 人間の本質を変えるためのマネジメントではなく、仕事を変えるためには何が必要かということ。 マネージャーの仕事は人々が働く意味を見つけることをサポートすること。 スター社員を分析して他の社員より成功している理由を見つける。 業績が低い人への思いやりも忘れてはいけない。採用のプロセスが適切ならその人への役割の与え方が間違っている。学習を支援して新しい役割を見つける。 人生で最低/最高の瞬間に出くわしたとしても自分より寛大な組織が後ろに居てくれると分かるだけで慰めになる。 評価決定前にマネージャー陣が集まって部下の最終評価を検討するキャリブレーションがあるので公平な評価が可能。 社員の評価においてボトムテールの人々の改善に投資をすることはチームの改善に繋がる。それでも業績を上げない場合は退職して別の会社で成功を収める。 パフォーマンスの高さは状況に依存するので、他の職場でうまくいっていても新しい環境でうまくいくとは限らない。 エンジニアは管理されることを嫌う。彼らはマネージャーの事が嫌いだし、マネージャーになりたくないと思っていことも確か。 優れたマネージャーの8つの属性。1. 良いコーチであること。2. マイクロマネジメントをしないこと。3. メンバーの成功や満足度に関心を示すこと。4. 生産性/成果思考であること。5. 話を聞いて、情報を共有すること。6. チームメンバーのキャリア開発を支援。7. 明確な構成と戦略を持つこと。8. チームに対して助言できる技術スキルを持っていること。この中でも技術的な専門知識は重要度が一番低い。 ある分野で専門的な知識を得るためには1万時間が必要。ただし1万時間の長さではなく、どう使うかが重要。少しでも確実にのこるものを学ばせるほうが賢い投資。 フィードバックのない反復はモチベーションが向上しないし進歩しない。組織やチームの学習効率をあげる方法の一つとして学習するスキルを細かい要素に分けて具体的なフィードバックに返すこと。更には学習がもたらした結果を測定する。 最善の学習方法は教えること。 外発的動機づけの報酬体系を洗練させ、4つの原則が生まれる。1, 報酬は不公平。2. 報酬ではなく成果を称える。3. 愛を伝え合う環境づくり。4. 思慮深い失敗に報いる。 最も優秀な人でも失敗するので、失敗にどう対応するかが問題になる。またリスクを賞賛しないと誰もリスクを取らなくなる。 社会的構造の隙間にいる人ほど素晴らしいアイディアを持っている可能性が高い。 意思決定のエネルギーはここぞという時に使うべき。自分をパターン化すること。些細な事に気をとられていたら仕事が終わらない。
[etc] : RecommendSystem成果へのポインタ
[javascript] : FC2動画で非会員による1日の視聴制限を解除するBookmarklet おしまい
[etc] : WebCrawler in Scala Crawler in Scala 検索Crawlerを作る - Web就活日記
以前はnutchを使ったcrawlerを試してみましたが、今回はcrawler自体をscalaで書いているものをまとめようと思います。インターネットで紹介されているものの中には全然使えないものもあったりするので、選択には気をつけてください。個人的にはまとめた結果からJoup、HtmlUnitDriverが記述や設定が簡単で手軽に実行できるという点でお薦めしたいツールになっています。
nomad denigma/nomad
JDK/JRE7、MongoDB、Debianを必要とします。これによって私はテストしませんでしたが。sourceの更新も2年前で止まってしまっていますね。。application.conf、filters.groovy、seeds.txtの3つのファイルを記述するだけで簡単に動かせて、結果をMongo上で確認できるようなのでDebianUserは試してみると良いかもしれません。
simplewebcrawler Srirangan/simplewebcrawler
ScalaとGridGainを必要とします。GridGainでjobを分割することで並列分散処理をやっているみたい。GridGainを使うというニッチ派は聞いた事が無いので、何かしら問題が発生した時に大変そうです。
fureteur gip/fureteur
おそらく紹介する中で一番作りこまれている印象を受けました。RabbitMQを利用した分散Crawlingを実現、akkaのactorでmoduleを実装、スケジューリングを管理してくれる、sbtで用意されているので簡単に利用できる等の特徴があります。本気でCrawlerを作りたい人向けですかね。
crawler bplawler/crawler
指定したURLから再帰的にリンクを見つけてCrawlしてくれます。ただしドキュメントがほとんど無く初心者には設定がよくわからない、READMEの記述が誤っている、複雑なTagのパースがうまくできない(？)、様々なサイトのリンクを取得しようとするとExceptionがたくさん出て処理が進まないなど使用するのは困難と言えます。評価出来る内容としてはsbtによるbuild管理と、少ないコード記述でcrawlerができてしまうこと。以下は簡単に導入の内容を記載しておきます。
$ git clone https://github.com/bplawler/crawler.git $ cd crawler $ cp build.sbt build.sbt.bak $ vi build.sbt $ diff -u build.sbt build.sbt.bak --- build.sbt 2014-12-30 09:17:54.895512815 +0900 +++ build.sbt.bak 2014-12-30 09:48:18.683566361 +0900 @@ -8,8 +8,6 @@ scalacOptions := Seq("-deprecation", "
[etc] : データサイエンティスト養成読本 データサイエンティスト養成読本 R活用編 【ビジネスデータ分析の現場で役立つ知識が満載! 】 (Software Design plus)
作者: 酒巻隆治,里洋平,市川太祐,福島真太朗,安部晃生,和田計也,久本空海,西薗良太出版社/メーカー: 技術評論社発売日: 2014/12/12メディア: 大型本この商品を含むブログ (1件) を見る
データサイエンス 参加したイベントで頂いた「データサイエンティスト養成読本 R活用編」の冒頭を中心に読んでみました。前に出ていた同等の養成本よりデータサイエンティスト養成の問題と本書の位置づけがはっきりしていて読みやすかったと思います。21世紀で最もセクシーな職業という噂のデータサイエンティストについて、本の中で重要だと思った内容の意訳をメモしておきます。(あまりデータサイエンティストの話はまとめてなく、結局は統計の話ばかりメモしてしまっています。すみません。)
アカデミック領域と異なるビジネス領域でのノウハウの少なさ。 データの前処理のような泥臭い話は書籍やWebには出てこない。 使用するツールに拘りを持たず、効率を重視して使い分けが必要。 ビジネスへの意思決定にも携わるため、新卒からいきなり経験させてもらえない。 3つのキャリアタイプがあり、組織の上では各キャリアタイプの人材の協力が必要。 ビジネス寄りのタイプ(ユーザーの気持ち理解) 統計理論に強いタイプ(統計解析) エンジニアリングに強いタイプ(データ処理のコードを書く) R言語はメモリに載り切らないデータ量、リアルタイム処理には不向き。 統計学の全体像 記述統計学 真ん中 = 平均、中央値。 構成 = 比率。 ばらつき = 分散、標準偏差。 推測統計学 全体の真ん中が同じ確率 = t検定。 全体の構成が同じ確率 = χ二乗検定。 全体のばらつきが同じ確率 = F検定。 関係から全体分け = コレスポンデンス分析、主成分分析、因子分析、クラスタ分析。 関係から全体を当てる = 重回帰分析、判別分析。 標準偏差は分散の平方根。 検定と一部のデータを利用してもデータ感に差があると言えるかを確認する手法。差がない確率が一定未満の場合は差があると判定。 クラスタリングには階層的、非階層的がある。非階層的な例としてk-meansがある。 アソシエーション分析を行って、有益なルールを探す。 決定木はツリー構造で可視化できるのでわかりやすい、CARTが有名。CARTはジニ係数でデータを分割。ジニ係数は0〜1の値、0だと平等、1だと不平等。 機械学習は目的変数が離散型か連続値かによってクラス分類、数値予測に分けられる。 クラス分類ではデータ数が少ない時に精度が最も高いとされるSVMが有名。 ランダムフォレストはアンサンブル学習(集団学習)により分類/回帰を行う。アンサンブル学習は弱学習機をたくさん作って結果の多数決を取る。ランダムフォレストは数値予測にも利用可能。 線形回帰は目的変数を直線的な関係で予測。評価指標にはRMSE(平均2乗誤差)、決定係数などを利用する。 以上が第一、二章の要約でした。個人的にもデータサイエンティストは何でも出来る人として見られる事が多く、データの分析からビジネスの未来を考えられる人と思われる事が多いように感じていますが、データサイエンティスト側としてはそれは要求レベルが高過ぎることで、決して一人ではできるような内容ではないと言えます。エンジニアにもネットワークエンジニア、Webアプリケーションエンジニア(サーバーサイドエンジニア、フロントエンジニア)、スマートフォンアプリエンジニアなど細かく定義できるようにデータサイエンティストにも当然得意不得意な領域があって、誰しもがコンサルタントやマーケッターなどの領域をカバーできないという世間一般の認識を少し変えていきたいですね。
[etc] : What is spray? What is spray spray | Introduction » What is spray?
adtech × scala勉強会でsprayの事例が幾つかあったので軽く触ってみることにしました。上のWhat-is-sprayで紹介されている内容をここでも簡単に記述しておくと以下のような感じです。2014.12.23日現在、最新のVersionは1.3.2のようです。尚、本記事の実験環境はCentOS Linux release 7.0.1406 (Core)で動かしています。
Akka上で動く、HTTP/RESTをサポートしたクライント/サーバーサイドのライブラリ。 JVMのlayerを触りたい場合もレガシーなJavaの実装が必要なくscalaのAPIの記述で事が足りる。 sprayはフレームワークというよりはライブラリ志向で作られている(哲学的に)。 完全非同期、Non-Blocking。 ActorとFutureベース。 ハイパフォーマンス、軽量、テスト可能。 twirlというtemplate engineもある。 中心となるspray-io、インメモリのキャッシュであるspray-caching、spray-io上でClient/Serverとして動くspray-can、Servlet上で動かすためのspray-servletなどのモジュールが用意されている。 Getting Start Hello world Getting Started with sbt — Installing sbt on Linux
まずはscalaのbuild toolをinstall、次にsprayを動かしてみます。プロジェクト名はhello-worldとします。以下の実行によりHTMLを吐き出すところまでは出来ました。spray-templateはspray-can上でspray-routingを実行するためのtemplateなようです。
$ wget https://dl.bintray.com/sbt/rpm/sbt-0.13.7.rpm $ sudo yum localinstall sbt-0.13.7.rpm -y $ git clone git://github.com/spray/spray-template.git hello-world $ cd hello-world $ sbt test re-start $ curl "