Privacy Sandbox等のクッキーレスアドテックに関する前回の記事から1年が経とうとしています。1年間様々なベンダーから提案が公開され、議論も進化のペースが激しく、しばらくまとめを断念していました。今年に入ってからもGoogle (ChromeとAds)やAppleからクッキーレス、IDレスアドテックについて発表が相次ぎましたが、主要提案の開発とリリーススケジュールが明らかになり、発散から収束フェーズに入ったと思われるので、一度状況まとめておきます。 振り返り Privacy SandboxはGoogle Chromeの開発チームが提案する、3rd-party cookieとフィンガープリンティングの代替技術(サイトを跨いだ計測とターゲティング機能、アドフラウド防止機能)およびサイトを跨いだユーザ単位のトラッキング防止機能の総称です。3rd-party cookieの段階的な廃止自
※この投稿は米国時間 2020 年 3 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Twitter の広告プラットフォームでは、日常業務の一環として数十億もの広告エンゲージメント イベントが日々発生しています。そしてこれらのイベントのひとつひとつが、ダウンストリームの数百もの集約指標に影響を及ぼす可能性があります。広告主がユーザー エンゲージメントを測定し、広告キャンペーンを効率よく追跡できるように、Twitter はさまざまな分析ツール、API、ダッシュボードを提供しています。これらは 1 秒あたりに数百万もの指標をほぼリアルタイムで集約することが可能です。 本投稿では、Steve Niemitz がリードを務めるTwitter の収益データプラットフォームエンジニアチームが、Twitter の広告分析プラットフォームの収益正確性と信頼性を向上させる
「広告が嫌われる”本当”の理由」という文章を読んで違和感があったので、「”本当”の理由」を書いておく。 この問題提起。これについては非常に重要なことだと思う。 一方で、「本当の理由」とタイトルにある割には本質的な部分が全然的を得てなくて、本文の内容に違和感もあり、誤認識があるように思った。 そこで以下を書いておきたい。 ・そもそも冒頭にあるアドフラウドと「嫌われる広告」の話は別問題。 ・「広告が嫌われる理由」について、幅広く「広告」と言った場合のそれと、「ネット広告」に限った場合のそれとの問題の切り分けをしないといけない。上記文章では残念ながら混同されてしまっている。 ・「広告が嫌われる」のはなにも最近に始まった話ではなく、テレビCMが「トイレタイム」と言われる時代からあった。その頃の「広告が嫌われる理由」は、楽しんで見ている番組が中断されることにあった。テレビの前を離れればいいだけなので
低レイテンシと安定性を生むアーキテクチャ - SSPの現場に学ぶ、高可用性のつくり方 低レイテンシとは、広告配信の世界でユーザービリティ / 収益に直結する要素であることから、重要視されています。では、SSPの現場で実際に用いられるシステムはどのような構成になっているのでしょうか。fluct社の鈴木健太さんに、低レイテンシ、そして安定して稼働するシステムの基本を聞きました。 200msを目安にレスポンスを返す、低レスポンス設計 オンプレミスとAWSを組み合わせてコストとスケールのバランスを保つ データのコピーをサーバーに入れ、独立化する 悪くなったところを捨てるのが、低レイテンシ・システム安定化の秘訣 ログの集計はBigQueryで簡単に 悪くなったところは捨てて、全体を安定に動かす レイテンシ(latency)とは、リクエストに対して応答を返すまでの時間のことです。レイテンシをできるだけ
昨日の録画が上がってて、作業しながら聞いてたら面白かったので昨日の記事に追従する形おまとめした。 (1/21 コメントいただいたので、コメントで補足頂いた部分に注記を足しました!ありがとうございます!) 発表のまとめ Ad www.youtube.com トークメモ トラッキング 広告主としては電話番号や住所のような個人情報は欲しくないが、もっと匿名性のある情報はほしい。 GDPRの考え方により、個人情報の範囲が拡張されて、閲覧履歴すらも個人情報とみなされると日本でもその時流が来る可能性がある。 デジタルマーケティングなので、ユーザに合わせたよりよいものを出すためのものだが、どんどん規制が厳しくなっている セキュリティ ユーザが任意で広告トラッキングをさせないためのITP (Intelligent Tracking Prevention) を回避するような業者も出てきているが、あまりよろし
記事の趣旨 ネット広告で使われているRTBというシステムのプロトコルであるOpenRTB。 昨年9月にOpenRTB3.0が発表されたので、OpenRTB2.5での課題を踏まえて概要をながめてみます。 確定版もまだですし、3.0が各所で導入されるのは先のこととは思いますが、いざ導入という時に乗り遅れないよう準備しときましょう。 本当にざっくり書いているのであしからず。 OpenRTB3.0の指針 プログラマティックバイイングは便利になった一方、複雑化が進んでいるので、RTB3.0により透明化する新しい手続きの設計が進めている。 特徴 重複したコードを減らし、高速な入札を可能にする 関与したimpressionに認証済みの署名を提供することが求められる ヘッダー入札やサプライチェーンに複雑化に対応するよう策定された 現在のRTBプロトコルは、オープンエクスチェンジか、OTT動画か、プログラマ
OpenRTBを解説する前に「RTB」についても軽く説明したいと思います。 RTBとは、「Real Time Bidding」の略で広告の入札をリアルタイムで取引する方式のことです。 事前に枠を抑えておく事前予約制の純広告などとは異なり、ユーザがサイトに訪問したタイミングで広告の選定を行います。 純広告の例 RTBの例 OpenRTBとは、簡単に言うとRTBを行う際のルールです。 各社様々な独自のデータを用いて広告の配信を行っている中で何のデータをやり取りするのか、またどういう形でやり取りを行うのか といったことを標準的に定めているのがOpenRTBです。 例えば、ある媒体ページにユーザが訪れたとき、広告主に広告要求リクエストが飛ぶとします。 このとき媒体側は、サイトの情報(ゲーム、自動車など)や訪れたユーザの情報(ID、訪問履歴など)を広告主側に渡します。 これらの情報がただ羅列されてい
2018年11月21日、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2018」が開催されました。4度目の開催となる今回のテーマは「Next LINE」。メッセージアプリだけでなく、さまざまなサービスの開発や新たな技術領域への投資を行っているLINEが目指すビジョンと各分野での取り組みについて、エンジニアたちが技術的側面から紹介します。セッション「LINEが目指す理想の広告プラットフォーム」に登壇したのはLINE株式会社開発Aチームの渡邉直樹氏。LINEの様々なサービス上で用いられる広告配信プラットフォームの裏側を紐解きます。講演資料はこちら LINEが目指す理想の広告プラットフォーム 渡邉直樹氏:みなさま、こんにちは。サーバーサイドエンジニアとして広告プラットフォームの開発をしています、渡邉直樹と申します。よろしくお願いします。 演台の
スペックワークを知っていますか? 日本ではあまり定着していない言葉ですが、「スペックワーク (SPEC WORK)」というものが海外の広告デザイン業界で問題視されています。スペックワークを平たく言えば、「気に入ったらお金を払うよ (気に入らなければ払わない)」という類のクライアントからの要求です。 カナダの広告代理店 Zulu Alpha Kilo は、そんな業界のスペックワークについてNOを掲げ、5年前から提案依頼書の8割を断るという英断を行いました。当初は社員・クライアント含め、非常に混乱したそうですが、その結果、この5年間一度もスペックワークを行わず成長を遂げてきたのです。 そんなZulu Alpha Kiloが、一風変わった映像を制作しました。これを観ればデザイン業界の「スペックワーク」がいかに良くないことであるかが理解できます。スペックワークにNOというべきである!(Say no
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く