speee engineer mtg 2016/10/05

908 views

Published on

広告運用プラットフォームの基本的な仕組みとモデル共通化の話

Published in: Engineering
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
908
On SlideShare
0
From Embeds
0
Number of Embeds
880
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

speee engineer mtg 2016/10/05

  1. 1. 10/05 Engineer MTG NAKAJIMA Satoshi
  2. 2. なにをしているか プロモーションユニット(PU)をサポートするシス テムの開発/運用 PUとは?
  3. 3. PUとは 各事業のプロモーション全般を担当 広告運用、効果検証、分析など
  4. 4. PUの業務 出稿した広告によってどれぐらい費用が発生し て、それによって売上がどれぐらい上がったのか 効果の良かった広告は一体何が良くて、効果の悪 かった広告は何が悪かったのかの検証・仮説 次の広告はどのような施策を打つのか どうやって計測しているの?
  5. 5. 広告の効果計測の仕組み 広告に1つずつutmパラメータを振る utm_source utm_medium utm_campaign utm_content utm_term
  6. 6. 広告の効果計測の仕組み これらのパラメータを組み合わせてユニークに し、各オフラインデータ(本人確認済CVs, 訪問完了 CVs, 申込, etc...)がどの広告からの流入していたの か、たどれる PUはなにをしていたのか?
  7. 7. 広告の構成
  8. 8. PUがやっていたこと 各広告媒体から配信結果をCSVなりでDLしてくる PUで広告とオフラインデータを紐付けてどの広告 で売上が上がったのかをまとめる キャンペーンや広告グループ単位での費用対効果 (ROAS: Return On Advertising Spend)などをKPIと して追っていた
  9. 9. PUがやっていたこと ROAS を出すには各階層毎の売上がわからないとい けないのでハイスペックPCにリモートで繋いで Excel を使ってutmパラメータからどのキャンペー ンや広告グループなのかを判別し、それぞれの売 上を算出していた そのデータを使ってレポートを作成
  10. 10. PUがやっていたこと プロダ クト キャン ペーン 数 広告グル ープ数 広告数 キーワー ド数 ieul 1502 647,174 1,770,387 4,487,242 salon 736 20,669 143,014 2,273,279 nurikae 351 66747 270,743 24,918
  11. 11. PUがやっていたこと 全部紐付けられないので追う必要がありそうなも のを一部抜き出して見ていた
  12. 12. 紐付けぐらい機械でやろう
  13. 13. PUをサポートするシステムで何を 行っているのか 各広告媒体から配信結果を取得し記録する 対応媒体 Google(search/display) Yahoo(search/display) Facebook Hike Popin Gunosy
  14. 14. PUをサポートするシステムで何を 行っているのか 各事業部からオフラインデータを取得し、utmパラ メータを使って広告とキーワードとサイトリンク 毎に紐付ける 上位概念(アカウント、キャンペーンなど)毎に集計 する 紐付けたデータを表示、レポートの出力 common-model の話
  15. 15. common-model におけるモデル共 通化の現在とこれからやろうと思っ ていたこと
  16. 16. common-model とは Markeforce に関連するモデルの共通化を目的とし たgem Rails Engine 製
  17. 17. common-model を使ったアプリケ ーション im-prom-marke-force im-prom-result-collector 2つのアプリケーションから1つのDBを参照 作り方は省略。やってみてどうだったか
  18. 18. どうだった? 個人的にはやってよかった 普通のWebアプリケーションっぽくないところの 恩恵は大きいかも
  19. 19. 困った所 install:migrations を各アプリケーションでやると migration ファイルがその時の年月日時分秒にな り、DBは共通のものを使用しているので schema_migrations との違いが出て色々怒られる。 とりあえずの対応は migration ファイル作ったら中 にコメントアウトで元の migration ファイルの年月 日時分秒が入ってるので職人の手で rename
  20. 20. 困った所 モデルの追加がちょっと心理的ハードル高かった ただ慣れてくればあまり問題ない 開発したいアプリの Gemfile の中で branch が指 定できるので向け先変えて開発 テストも書いてる
  21. 21. 困った所 本番 migration が面倒 多分普通なら deploy 時に capistrano に任せる所 だがMarkeforce では role: db を外しておいて 自動で migration しないで直接 rake db:migrate していた
  22. 22. 良かった所 重複が省けた
  23. 23. 所感 最初の方は慣れずに手間取ったが、後半はそうで もなくやってよかったかな、という感じ(+あんま りモデル追加や変更もなかった) プロダクト自体 社内向け + そんなにアクセスユーザいない からこそ無理やりやった部分も多く、参考になる んかいな、という感じ でもMarkeforce はまだこの形で続けていこうかと 思っている
  24. 24. この後のやっておきたいな、と思っ ていた所 migrationの脱却 やっぱり migration 周りは面倒っちゃ面倒なので migration の脱却 をしておきたい、と思ってい た
  25. 25. この後のやっておきたいな、と思っ ていた所 common-model のrails 脱却 結局Railsに依存しているのは恐らく Active::Record , Active::Model , Active::Support ぐらいなので Rails Engine でなく普通の gem として作ればいいん じゃないか、と思っていた
  26. 26. End

×