こんにちは。マイクロアドでインフラエンジニアとして勤務している伊東です。 今日はインフラエンジニア視点で導入してみた社内 IoT、間接的な業務効率改善の話をいろいろ脱線しながらユルくご紹介したいと思います。 IoT の歴史とマイクロアドの現在と 近年よく聞く「IoT」ですが調べてみると意外と歴史は古いようです。まだ IoT という名前もなくインターネットすら一般的ではなかった 1992 年頃、コーラの自動販売機の残量、温度のデータを送ったのが始まりだとか・・・。または、それよりも１年前、ケンブリッジ大学で研究室のコーヒーメーカーにコーヒーがあるかどうかを確認するために設置されたカメラも「残量」や「温度」を知りたいというコーヒーメーカーに対する欲求であり、間接的ですがそれを実現した IoT です。 さて、マイクロアド社内ではどんな要望、課題があったのでしょうか。 それは、ビッグデータの分析、

マイクロアドのデータサイエンティストの青井です。広告配信におけるロジック設計などの分析業務を行っています。今回はユーザーにとって役立つ情報を広告で届けるためにマイクロアドが行なってきた行動分析の変遷について紹介します。はじめにRTBと呼ばれるインターネット広告の配信技術について簡単に説明し、どのようにユーザーへ広告を配信しているのかを紹介します。続いて、行動データを用いてどのようにユーザーの興味関心を推定して、広告配信を行なっているのかを紹介します。 RTBによるユーザーへの広告配信 RTBとは ユーザーへの広告配信の方法 行動データを用いたユーザーの興味関心の推定 行動ターゲティングとは 行動データが増えるなかで生じた課題 フルファネルマネジメント データを集約するための基盤構築 フルファネルとは フルファネルマネジメントの機能紹介 ユーザーのスコアリング 興味関心の可視化 最後に RT

はじめまして．マイクロアドの新卒3年目のサーバサイドエンジニアの松宮です． 主にMicroAd BLADEという広告配信プラットフォームの開発をしています． サーバサイドの開発言語はJava/Scalaが中心で，最近はScalaの利用シーンが増えてきました． ということで本日はScalaが活躍するお話です． タイトルの通り，順序保証型分散ストリーム処理 についてお話します． 上記用語は分散ストリーム処理に順序保証型という単語をくっつけた造語で，分散ストリーム処理において時系列を保持して処理を実行する方法です． 「大量のデータを順番に処理したい！」という方がいらっしゃれば是非ともご一読頂ければ幸いです． 順序保証型分散ストリーム処理とは そもそもストリーム処理とは，無尽蔵に生成されるデータを半永久的に処理し続けることを指し，アクセスログやセンサーから得られるログデータなどの時々刻々と生成され

MicroAdの京都研究所でソフトウェアエンジニアとして勤務している池田です。主に広告配信やReal Time Bidding（以下RTB）のプログラムの開発に携わってきました。 本日はアドネットワークと呼ばれていた時代から現在主流となったRTBに至るまで、MicroAdの広告配信プログラムで採用したプログラミング言語の経緯についてご紹介します。 MicroAd 配信プログラムと採用言語の変遷 サービスの開発年次と採用言語 年 サービス 概要 開発言語 2004 BlogClick ブログに特化したコンテンツマッチ型広告配信 Perl 2006 MicroAd リターゲティング/行動ターゲティング広告配信 Perl 2009 MicroAd配信改修 アーキテクチャ変更 Perl 2009 MicroAd VASCO 媒体向け無償アドサーバ PHP *1 2011 BLADE Demand-

背景 SPSSという壁 SPSSは使わない 本題 ~ HTTP cookieを使って年齢と性別を推定する 問題の設定 データを可視化してアプローチ方法を考える モデリング 結果 性別 年齢 結果の総評 プロダクション環境に組み込む 終わりに 背景 表題をみた皆様はこう思われたに違いない「何を今更そんな話、、、、」。 実はこれ、 developers.microad.co.jp でサラリと触れられている”SPSS"に関係があるんです。 SPSSという壁 マイクロアドではSPSS Modeler(以下SPSS)を使って年齢と性別を推定していました。いま流行の機械学習でね。 皆さんのSPSSについての印象は大まかに次の３パターンに分かれるでしょう。 「Ⅰ. SPSSってなんぞや？(((ﾟдﾟ; )」 「Ⅱ. (∩ﾟдﾟ)Rの有償版？」 「Ⅲ. あぁ、察した、、、（そそくさと退散）彡(*￣з￣)」

こんにちは。インフラエンジニアの@kanga333です。 最近マイクロアドではデータ基盤を刷新しました。 今回はデータ基盤の刷新に至る背景と新基盤での設計ポイントについてざっくり書いていきたいと思います。 刷新に至る背景 マイクロアドを長年支えてきた既存データ基盤は長年の改修の結果、色々な課題を抱えていました。 データの転送がNFS, Fluentd, Kafkaなど機能毎に色々な方法で行われており、共通基盤的な部分にもかかわらず共通化ができていませんでした。 Hadoopクラスタはサービス毎に立ち上がっていました。クラスタのバージョンは更新できておらず、運用コストが膨らんでいました。 クラスタが分散しているので、データサイエンティストが新しい環境にデータを集める際に、どこににデータがあるのか各担当者にヒアリングする必要がありました。 そして、そこに第一回の記事でも触れているようにDWHの