サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
note.com/dd_techblog
電通デジタルでデータサイエンティストをしている中嶋です。 前回の記事は「Airflow 2.0でDAG定義をよりシンプルに!TaskFlow APIの紹介」でした。 Advent Calendar 10日目となる本記事では因果探索の一手法であるLiNGAM(Linear Non-Gaussian Acyclic Model)の解説及び、Google Colabでの分析例について紹介します。 因果探索とは最近のトレンド 最近、広告配信やマーケティング分析の文脈で施策の効果を適切に評価する手法として実験計画法や因果推論が注目を浴びています。産業界でも株式会社ソニーコンピュータサイエンス研究所、クウジット株式会社、株式会社電通国際情報サービスの三社が提供するCALCという要因分析ツールや、最近はNECの因果分析ソリューション causal analysisも出ていたりと盛り上がりを見せています。
電通デジタルでバックエンド開発をしている松田です。 前回の記事は「広告出稿プランニング業務におけるセグメントのマッピングと表示改善」でした。 Dentsu Digital Tech Advent Calendar 2020 9 日目の記事になります。この記事ではAirflow 2.0で追加された機能の一つであるTaskFlow APIについて、PythonOperatorを例としたDAG定義を中心に1.10.xとの比較を交え紹介します。 弊社のAdvent Calendarでは、Airflow 2.0に関するものはこれまでにHAスケジューラの記事がありました。Airflow 2.0で提供される新しい機能について詳しく知りたい場合はAirflow Planningを参照ください。 TaskFlow APIとは?TaskFlow APIとはざっくり言うと、タスク間の暗黙的なデータ連携を明示的に
電通デジタルでバックエンド開発をしている長内です。 本記事では電通デジタル内で開発されている業務アプリケーション内において、セグメントを取扱う仕組みを改善したのでその内容をご紹介します。 弊社の業務の中に広告出稿のプランニングがあり、業務アプリケーション上から興味・関心に関するセグメントを指定する操作があります。 前提として、この操作に関連する従来の実装ではユーザがアプリケーション上で任意のセグメントを抽出する際、ユーザ入力に対して関連性の低いものを含む大量のセグメント候補のリストに対して目視で選択を行っていました。 当然、我々は大量の要素から任意の1件を目視で探すという行為に非効率さを感じます。 であれば画面上に部分一致判定を行うような抽出用のフォームを用意し、入力した文字列によって目的のセグメントを抽出すればよい、と考えるかもしれませんが、この解決方法では本質的な解決には至れませんでし
※ 本記事は、Dentsu Digital Advent Calendar 7日目の記事となります。 こんにちは、電通デジタルでバックエンド開発をしている関本です。普段は技術寄りの話題が多い当ブログですが、今回は『オンラインハッカソンの開催を検討、運営を担当する方々』に向けて、 を主題として弊社開発部内の取り組みの様子とその結果についてお話させていただきます。 まずはじめに、業務で忙殺されている方に向けて心得3箇条からお伝えしていきます。 【オンラインハッカソン開催の心得3箇条】 1. ハッカソン期間中は外界との交流を完全シャットアウトすべし! 2. 運営の事前準備、お題策定には時間をかけるべし! 3. 当日の「霊圧問題」に対処すべし!それではハッカソン開催に至った経緯、事前準備や当日の様子等の詳細について順を追って、お話していきます。少し長めの文章となりますが、お時間ある方は最後までお
電通デジタルでSREをしている神田です。 この記事は電通デジタルアドベントカレンダーの4日目の記事です。前回の記事は「Reactアプリケーション内でGoogle Analytics計測をする際、react-gaを使わず、gtag.jsを利用した方法とその選択理由」でした。 電通デジタルのいくつかの開発プロジェクトでは、データ処理のためのワークフローエンジンとしてAirflowが採用されています。 この記事では、Airflow 2.0で改善された機能の1つである、スケジューラーのHA(High Availability)対応について解説します。 Airflow 2.0で提供される機能について詳しく知りたい方はAirflow 2.0 Planningを参照してください。 そもそも、スケジューラーって何をしているの?スケジューラーは、DAGやタスクを監視し依存関係をもとに実行可能なTaskIns
Reactアプリケーション内でGoogle Analytics計測をする際、react-gaを使わず、gtag.jsを利用した方法とその選択理由 電通デジタルのエンジニア、西山です。 この記事は、電通デジタルアドベントカレンダー2020の3日目の記事です。前回の記事は「2020年に作ったDevOps内製ツール」でした。 この記事ではReactでGoogle Analyticsの計測コードを埋め込む方法についてお話しします。他のブログなどですでに何度も紹介されているテーマですが、ブログによって用いられる手法は様々で、どれを採用すればいいか迷う人も多くいるのではないかと思いますし、中には情報が古くなっているものもあります。 そこで最新の状況を調査した上で、私たちが採用した手法を紹介しますので、ReactでGoogle Analytics計測コードを埋め込む際の参考にしていただければと思います。
電通デジタルでSite Reliability Engineer(SRE)をしている齋藤です。 電通デジタルアドベントカレンダー20202日目の記事になります。前回の記事は「Dentsu Digital Tech Advent Calendar 2020開始します!」でした。 本記事では2020年にSREチームで作ったDevOps内製ツールについてご紹介させていただきたいと思います。内部プロダクトのユーティリティーなど細々したものは色々あるのですが、今回は日常的に利用頻度の高い以下2つのツール ・Auth0をIdPにしたAWSマルチアカウントSSOのクレデンシャル取得ツール(auth02aws) ・オンデマンドでBastionホストを起動して使うツール(bastion-session.sh) を紹介させていただきます。 Auth0をIdPにしたAWSマルチアカウントSSOのクレデンシャル取
でご紹介したGo言語でのgRPCコード生成の状況の続報(2020年末)をお伝えしたいと思います。 概要としては前回の記事に記載した通りで ・Protocol Buffer側のレポジトリは golang/protobuf から protocolbuffers/protobuf-go に移行 ・gPRC側のレポジトリのgrpc/grpc-goに新たにprotoc-gen-go-grpcコマンドができた なのですが、以下が追加になりました。 ・gPRC用のコードを生成するには Protocol Buffersのメッセージやシリアライズに protocolbuffers/protobuf-go のprotoc-gen-go、gPRCのサーバ/クライアントに grpc/grpc-goのprotoc-gen-go-grpc、と両方を使うことになった 以降で詳細をご紹介します。 経緯2020年3月のpr
電通デジタルでバックエンド開発をしている平沼です。 私は、4/1(水) に電通デジタルに中途入社しました。初日のオリエンテーション以降、入社 2 日目から今までリモートワークをしてきた中で感じたことをお伝えします。私としては、このままリモートワークが続いてもよいと考えています。 入社までの話私は、前職までは SIer として仕事をしており、今までリモートワークをしたことはありませんでした。プロジェクトでは、Mattermost という Slack ライクなチャットツールを立ててやり取りをすることはありましたが、基本的にはメールや対面での打合せがほとんどを占めていました。 今回転職するにあたって、入社直前までフルリモートワークになるということは全く想像していませんでした。弊社は、働き方改革を推進しており、そのなかでリモートワークの導入を計画していたことから、新型コロナウィルスの影響下でも比較
電通デジタルで機械学習エンジニアをしている今井です。 本記事では、BigQueryを用いて二重頑健(doubly robust)推定量による効果検証を行うための方法について紹介します。 この記事は過去記事[1]の続編となります。 IPW推定量による効果検証 因果効果とは、仮に介入があった場合のコンバージョン値(例えば購入金額など)と、介入がなかった場合のコンバージョン値の差です。 当然ながら、同一ユーザーにおいてこれらを同時に観測することはできません。 そこで提案されたのが、実際に介入があったTreatment群のコンバージョン値の平均と介入がなかったControl群のコンバージョン値の平均の差分が因果効果である、という平均処置効果(average treatment effect, ATE)です。 しかしながら、現実には交絡因子と呼ばれる介入とコンバージョン値のいずれにも影響を与える要因
こんにちは!電通デジタルのBI担当です。 今回は、技術記事でありつつも実験的に少し柔らかめな文体でお送りします。専門知識がなくても伝わるように書いていきます。応援よろしくお願いします。 応援よろしくお願いします はじめに今回は「DAR(ディーエーアール)」というサービスの一部のAPIについて説明します。このAPIですが、(広告業界も狭いため)ネット上に参考情報や日本語記事がなかなか存在しません。 APIから取得できるデータが更新されるタイミングなど、いくつかつまづきポイントもあるため、Tech blogという形で残せればと思い今回記事を書きました。 DARとはデジタル広告の出稿や計測を担当されている方なら一度は聞いたことがある名前だと思いますが…DARという名前はご存知でしょうか? 知らないという方のために説明すると、DARは「Digital Ad Ratings」の略で、Nielsen社
電通デジタルでSite Reliability Engineer(SRE)をしている齋藤です。 先日(8/5)に7/22開催のAWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料が公開されました。 資料中では以下の内容を説明しています。 ・AWSではアカウントに個別のIAMユーザを作成してログインする代わりに、IDプロバイダ(IdP)を使用し、シングルサインオンができること ・シングルサインオンは組織に独自のID基盤がある場合や、複数のAWSアカウントを使用している場合に有効であること ・シングルサインオンの実現の方法にはいくつかパターンがあり、運用をふまえながら何を選択するのがよいかであること 弊社の自社開発部署もAWSをマルチアカウント構成-シングルサインオンで運用しています。今回はその事例を上記資料の選定パターンチャート
帰ってきた optional - Protocol Buffers v3.12 から Field presence が導入 電通デジタルでバックエンド開発をしている齋藤です。 今回は Protocol Buffers v3.12 のリリースで追加された Field presence 機能について調べたことをご紹介します。 前提:v3.12 以前の Protocol Buffers v3 における optional な値の扱いProtocol Buffers v3 (proto3) では v2 (proto2) にはあった optional ながなくなり、optional を扱うにはひと工夫必要でした。加えて、Message の Filed に値を入れなかった場合は、Fieldの型のディフォルト値が送られてきたとみなす仕様になっています(各型のディフォルト値はこちら)。 そのため、開発者は
SnowflakeのGA4コネクタでできること 1.概要電通デジタルCRMインテグレーション事業部の小林です。 この記事では、Snowflake の Google Analytics用コネクタについてご紹介します。 こちらは2024年1月28日にプレビューとなった機能で、Rawデータ用と集計データ用のコネクタがそれぞれあるようです。 Google Analytics Rawデータ用のSnowflakeコネクタ https://other-docs.snowflake.com/en/connectors/google/
こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。 弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。 テレワーク環境で私たちのエンジニア部門で急務と感じた課題テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート?全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様
電通デジタルで機械学習エンジニアをしている今井です。 本記事では、顧客の潜在的な購買特性を加味してLTV(life time value)を予測するための統計モデルについて紹介します。 こちらは大阪大学 櫻井研究室との産学連携において開発されたモデルです。 顧客の潜在的な購買特性を検出する pLTVモデルは、RFM指標(Recency, Frequency, Monetary)を用いてLTVを予測する統計モデルです。 詳しくは過去記事[1]にまとめています。 本研究では、例えば「夏季/冬季, 平日/休日」といった時系列による特徴的な購買行動を抽出することで、マーケティング的な示唆出し、およびpLTVの精度改善を実現します。 提案手法では、各顧客の購買行動を商品カテゴリ, 時系列(購入日)の両面から分析し、いくつかの重要なトピックに分類します。 具体的には、購買ログを顧客ID(𝑢),
電通デジタルで機械学習エンジニアをしている今井です。 本記事では、BigQueryでUplift Modeling分析を行うための方法について紹介します。 広告効果を上げるためには? 広告効果とは、広告に接触した場合と接触していない場合とのその後のコンバージョン(CV)の差である、と言えます。 介入が無作為に割り当てられるランダム化比較試験(randomized controlled trial, RCT)において、広告効果は平均処置効果(average treatment effect, ATE)として推定できます。 詳しくは過去記事[1]にまとめています。 Uplift Modelingは「広告施策において、その効果を上げるためには誰を広告配信対象とするべきか」を推定するための方法です。 ユーザーの特徴量を 𝐱𝑖 とすると、Uplift Scoreは下記のように算出されます。 Up
電通デジタルでバックエンドの開発をしている齋藤です。弊社では社内/グループ会社向けデジタル広告運用実績の管理システムバックエンド API に gRPC を利用しています。 本記事では gRPC サーバ内で発生したエラーを gRPC Server Interceptor で gRPC Error Status にマッピングする試作をご紹介します。 ユースケースgRPC を使った API サーバでエラーが発生した場合、エラーハンドリングとロギングをした後に gRPC クライエントへのエラーを伝えます。ここで、サーバのエラーを gRPC クライアントに伝えるエラーに変換する処理が発生します。クライアントに伝えるエラーメッセージはサーバで発生したことそのままではなく、クライアントに必要な情報にする必要があります。この処理は全ての gRPC のメソッド呼び出しで実施します。そこで、本処理を gRPC
Go Protocol Buffer Message API V2 のReflectionとgRPC Server-side Interceptorを使ってAPIの呼び出し権限チェックを実現する 電通デジタルでバックエンド開発をしている齋藤です。弊社では社内/グループ会社向けのデジタル広告運用実績の管理システムのバックエンドAPIにgRPCを利用しています。 そこに、今年(2020年)の3月2日にGo公式のブログでGo Protocol Buffer Message API V2 の発表があり、4月13日にgolang/protobuf に Message API V2 対応版の v1.4.0 が正式リリースされました。これにより Go でも Reflectionが使えるようになりました。ブログ中で紹介されている、FieldOptionsを読み取ってフィールドをクリアする条件に使うなどより
電通デジタルで機械学習エンジニアをしている今井です。 本記事では、顧客生涯価値を予測するための統計モデルについて紹介します。 pLTVの求め方マーケティングにおける顧客評価のための重要な指標として顧客生涯価値(life time value, LTV)が広く使われています。 LTVを高精度に予測できるようになると、適切なマーケティング活動を通して優良顧客との長期的な関係構築が可能となります。 LTVを予測するにあたり、次のように要素を分解します。 pLTV = 生存確率 × 期待購買回数 × 期待購買金額 これらの3要素を推定するためのモデルとしてBTYDモデル[1]が提案されています。 BTYDモデルはECビジネスのような都度払いで売買が行われる取引を想定しています。 (サブスクリプション型のサービスでは期待購買回数と期待購買金額が一定であるため、生存時間解析などを用いて契約期間を推定す
電通デジタルでデータサイエンティストを務めている荒川です。広告領域を中心にデータ系のプロジェクトを統括しています。 本記事ではfastTextとMagnitudeを用いて、複数の広告プラットフォームで提供されるセグメントをマッピングする手法を紹介します。 広告セグメントをマッピングしたいデジタル上で広告配信をする際の特徴として、ターゲットに応じて細かくセグメンテーションできる点は、異論の余地がないでしょう。最も基本的なターゲティング手法のひとつとして、広告プラットフォームが提供するセグメントを用いることがあります。 例えば「カメラ好き」がターゲットだった場合、各プラットフォームが提供している「カメラ関心層」といったセグメントを配信対象にセットすることで、狙いたいターゲットに絞った広告配信が可能になります。 電通デジタルでは、プランナーの業務効率化/品質向上のために、想定ターゲットを入力する
電通デジタルで機械学習エンジニアをしている今井です。 本記事では、BigQueryで傾向スコア分析を行うための方法について紹介します。 広告効果ってあったの?広告効果とは、広告に接触した場合と接触していない場合とのその後のコンバージョン(例えば、購入金額や継続期間など)の差である、と言えます。 しかしながら、同一ユーザーにおいて、広告に接触した場合と接触していない場合とを同時に観測することはできません。 これを反実仮想(counterfactual)と呼びます。 そこで提案されたのが平均処置効果(average treatment effect, ATE)です。 広告に接触したユーザー群(𝑤=1)と接触していないユーザー群(𝑤=0)とのその後のコンバージョン(𝑦 )の差を広告効果とするものです。 ここで、介入(広告に接触する)の有無以外の条件が公平になるようにユーザー郡が分かれていれ
このページを最初にブックマークしてみませんか?
『Dentsu Digital Tech Blog|note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く