非エンジニアのProduct Managerが社内のBig Dataを広告運用業務に生かしてみた
この記事は GMOアドマーケティング Advent Calendar 2021 19日目の記事です。 はじめに こんにちは、GMOアドマーケティングのM.H(@masaseat)です。 自分はGMOアドマーケティングでアドネットワーク「AkaNe」とDSP「ReeMo」のProduct Managerを担当しています。 業務において広告配信結果の分析や、売上や性能のボトルネックをGoogleのデータウェアハウス「Google BigQuery」を用いて分析することが多いのですが、今回はその解析結果をプロダクトマネジメント業務や、広告運用メンバーの業務改善に活かしてみた方法をご紹介します。 分析環境について GMOアドマーケティングでは、広告配信結果のほぼ全てのログがGoogleのデータウェアハウス「Google BigQuery」に収納されています。 GMOアドマーケティングではエンジニア
よくあるオンプレOracleからRDSに移行したDBAの反省文 - ASMのきもち
この記事は JPOUG Advent Calendar 2021 - Adventar 17日目の記事です。 昨日はShinodaさんの「Oracle Database から PostgreSQL への接続を試す - Qiita」でしたね。 いやーOracle Database Gateway for ODBC全然使ったことがなかったので、これはぜひやってみよ…あれ、RDSでできるの？明日AWSサポートに早速連絡してみよう… 最近ブログを書く頻度がアドベントカレンダー以外書く頻度がない感じになってきております…コレハ、マズイ、ゾ！！笑 さて弱気な内容はおいておいて…ここ最近、ろくに活動もできなかったのはこれをやっていたからなのです。 そうよくある、(꜆꜄•ω•)꜆꜄꜆オンプレOracleからRDSに移行した話。 今更感あるのですが、私と同じミスを減らすきっかけになれば。と思い、書いてみます
MonotaROのデータ基盤10年史（前編） - MonotaRO Tech Blog
おしらせ：12/23 に後編記事がでました！ tech-blog.monotaro.com こんにちは、データ基盤グループの香川です。 現在モノタロウではBigQueryに社内のデータを集約し、データ基盤を構築しています。 およそ全従業員の6割が日々データ基盤を利用しており、利用方法や目的は多岐に渡ります。 データ基盤グループはこれまでデータ基盤システムの開発保守と利用者のサポートを主な業務として取り組んできましたが、これら多岐にわたる社内のデータ利用における課題の解決及びさらなるデータ活用の高度化を目的として、今年の5月よりデータ管理を専門に行う組織として新たに体制を再構築しました。 そこで改めて組織として取り組むべき課題や方向性を決めるために、まず自分たちの現在地を知ることが重要と考え、データ基盤の歴史を振り返り、社内のデータ活用における課題やそれを取り巻く状況がどう変わってきたのかを
Looker を運営する組織を考察してみる | フューチャー技術ブログ
はじめにフューチャー夏の自由研究2021の9回目です。こんにちは、TIG DXユニットの西田と申します。 業務で GCP のインフラの設計/構築/運用を担当しております。私が感じている『GCP の特徴』というと、Gartner の Magic Quadrant などでも毎回紹介されているデータ分析領域だと思っています。 そのため今回は、 Google社が買収したLookerという技術の簡単な紹介 そして、それを使うとなった場合、何が必要になるか？ Looker を採用するメリットに関しては本記事では特に触れません。 経営層から、使う事が決定された前提での話になっています。 という事を考察してみます。 本記事はあくまでも自由研究であり、私自身は Looker の運用経験はない中での私の主観がメインです。そこは最初に申し上げておきますが、ご容赦ください🙇 Looker とは？概略Gartne
データ集計基盤の改善でLooker導入に至ったワケ - ZOZO TECH BLOG
こんにちは。開発部データエンジニアの遠藤です。現在、私はデータ×テクノロジーでZOZOグループのマーケティングを支援するデータチームに所属して、データ処理基盤の運用などに従事しています。 本記事では、Lookerを用いて運用中のデータ集計基盤をきれいなデータをスマートに取り出せる基盤に改良した件について報告します。 データ集計基盤で燻っていた問題 1. クエリ管理の限界 2. 集計定義に対するデータの信憑性が謎 Lookerは何が良い？ ～データガバナンス機能～ LookML データディクショナリ Gitによるバージョン管理 データ集計基盤（改）の設定フロー データ集計基盤（改）でのデータマート更新 まとめ データ集計基盤で燻っていた問題 ZOZOでは、サービスに関するあらゆるデータをBigQueryに集約しています。BigQueryに集約した大量のデータからデータマートとして必要なデータ
『失敗から学ぶRDBの正しい歩き方』と『SQLアンチパターン』｜Koske Kano
巷で話題の『失敗から学ぶRDBの正しい歩き方』(通称「そーだい本」: 以下、文字列長の都合でこの呼称を使用します)を読んだメモです。 Webアプリケーションを構築していく時、データの設計や運用の面で「こうしておけばよかったー」と後から悶々とする場面は多々あるんですが、本書はそれら現場のモヤモヤや失敗の数々に名前を付け、「アンチパターン」として断罪(！？)していく内容になってます。 元々は『SQLアンチパターン』という、よく似たコンセプトの素晴らしいオライリー本があるんですが、本書でも随所に言及があるので未読の方はまずそちらから手をつけるのがいいかもしれません。 ざっくりした内容はそれぞれリンク先の章立てを覗いてみてください。なんとなく雰囲気はつかめるんじゃないかと思います。 今回は両者を比べながらゆるーく感想を書いていきたいと思います。 両者の守備範囲この2つ、まぁよく似た構成ではあるんで
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
