より正しい意思決定のための統計的仮説検定とサンプルサイズ計算 - Gunosyデータ分析ブログ
はじめに こんにちは、Gunosy Tech LabのBIチームに所属しているクボタです。 Gunosyではアプリ内のロジックやUI等の変更において数値ベースでの意思決定を行なっています。 例えば新たなキャンペーンでのCVR増加やUI変更によるA/Bテストでのクリック数増加の効果検証などで統計的に裏打された手法を用いることで正しく意思決定を行うことを目指しています。 data.gunosy.io 本記事ではそのような状況で必要となるサンプルサイズの設計や統計的仮説検定のお話をさせていただきます。 はじめに 検定手法の選択 統計的仮説検定の手順 比較する指標の選定 帰無仮説 と対立仮説 の決定 検定統計量の選定 有意水準の決定 検出力の決定 効果量の決定 サンプルサイズの計算 ノンパラメトリック検定 多重比較 おわりに 参考文献 検定手法の選択 数値による意思決定を行う際に検定はよく利用され
Gunosyのパーソナライズを支える技術 -1クリックで始まるパーソナライズ- - Gunosy Tech Blog
この記事は Gunosy Advent Calendar 2017 の3日目の記事です。 昨日の記事はaikizokuさんの現場で役立つAutoLayoutのTips集でした。 はじめに ニュースパス開発部の koid です。 この記事は、先日 @mathetake が投稿した、下記の記事の続編になります。 tech.gunosy.io プロジェクトの背景的な部分は、上記の記事を読んでいただきたいのですが、 1. ユーザーはクリックするたびに社内ではファインマンベクトルと呼ばせている呼ばれているベクトルがリアルタイムに生成かつ更新される ちょうど、このファインマンベクトルユーザベクトルを、ユーザが記事をクリックする度に、リアルタイムに更新する部分に関わったので、そのときの話を書きたいと思います。 下のアーキテクチャっぽい図でいうと、ちょうど上半分の話になります。 課題と背景 弊社では以前か
BigQueryのクエリ課金額をslack通知する - Gunosyデータ分析ブログ
はじめに こんにちは、データ分析部の阿部です。 Gunosyには社内警察と呼ばれる人がおり、たとえばデータ可視化の際に円グラフを使うと正しい使い方を教えてくれる、母数という言葉の使い方を正してくれる、方々がいます。 tech.gunosy.io 今回はBigQueryで課金額の高いクエリを投げると警告してくれる、課金警察というボットを作ったので紹介します。 BigQueryはクエリで使われるデータ量に対して従量的に課金されるため、クエリ毎の課金額が把握できると便利です。 Gunosyではエンジニア・非エンジニア問わず、インターン生でも自由にクエリを書いて分析できる環境となっているため、知らず知らずのうちに大胆なクエリが投げられることもあります。 そのため、課金警察でクエリ毎の課金額をSlackに通知しお互いに監視して注意しようという意図です。 どうやってやるか BigQueryにはクエリの
Scrapy + Scrapy Cloudで快適Pythonクロール+スクレイピングライフを送る - Gunosyデータ分析ブログ
はじめに こんにちは、データ分析部の久保 (@beatinaniwa) です。 今日は義務教育で教えても良いんじゃないかとよく思うWebクロールとスクレイピングの話です。 私自身、日頃は社内に蓄積されるニュース記事データや行動ログをSQLやPythonを使って取得・分析することが多いですが、Web上にある外部データを使って分析に役立てたいというシーンはままあります。 単独のページをガリガリスクレイピングしたいときなどは、下の1年半ぐらい前の会社アドベントカレンダーに書いたような方法でやっていけば良いんですが、いくつもの階層にわかれたニュースポータルサイトやグルメポータルサイトを効率よくクロール+スクレイピングするためには、それに適したツールを使うのがすごく便利です。 qiita.com そこでPython用スクレイピングフレームワークScrapyの登場です。 Scrapy | A Fast
Norikra in Gunosy Network Ads@Norikra meetup #2
Cloudflare Workers x AWS Lambdaの組み合わせユースケース / Cloudflare Workers x AWS Lambda Combination Use Case
「サーバにログインしない・させないサービス運用」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々
メモった。間違い等あるかもしれませんが、その場合はごめんなさい。 Gunosy 2011.09リリース 現在900万DL突破 エンジニアは現在26名 2014.11は16名、2013.11は7名、2012.11は4名 クライアント+QAは5名、Web+APIまわりは5名、インフラは1名とかとか Gunosyの開発 API: Golang パートナー・広告主への管理画面: Rails バッチ・内部向け: Django or Python バージョン管理: GitHub 構成管理・デプロイ: Chef (+OpsWorks) 開発の特徴 小さい単位で作ってすぐ捨てる マイクロサービス的な 機能が増えすぎたら分割 メンテするよりリプレース サーバにログインされて困る事 信頼できないビルド・デプロイ 開発者の手元でビルドすると、どの断面なのかわからずトラッキングできない プロダクションに上がってい
GunosyでのRails開発フロー
この当時の内容と大きく変わっていませんが、最新のRails開発について公式テックブログに書きました。そちらも合わせてご参照ください。 この記事はGunosy Advent Calendar 2014の22日目の記事です。 こんにちは、Gunosyのtoshimaruです。Gunosyでは主にRuby on Railsアプリを担当しています。 はじめにGunosyでは昨年度よりAPIの実装をRails実装からGo実装へと変えたことでAPIのパフォーマンスの大幅な改善が行われました。そんなわけで「GunosyってRails捨ててGoを使ってるんじゃないの？」とお思いの方もいらっしゃるかもしれませんがそんなことはありません。大規模アクセスのない管理画面などではRuby on RailsはまだまだGunosyで現役バリバリです1。高速にWEBアプリを作る必要のあるシーンにおいてはGoはRailsに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高速な広告配信サーバの作り方のコツ