Archives: Videos

ストリーミングTVでコンテンツシグナルを共有する方法

  バイヤーは、希望する環境で適切なオーディエンスにリーチするため、ストリーミングTVにチャンネル、ジャンル、番組情報などのより詳細なコンテクスト情報を求めています。  ウェブやモバイルアプリなどのデジタルチャネルや、リニアTVなどの昔から存在するチャネルでも、透明性の高さは既に常識となっています。しかし、他のチャネルと比較して、プログラマティック・ストリーミングTVでは、コンテクスチュアルデータの仕組みは異なり、考慮すべきことが多くあります。   プログラマティック・ストリーミングTVの市場規模を拡大をするためには、透明性の向上が重要  マーケターは、ブランド適合性を確実にし、的確なターゲティング、適切なアトリビューションと最適化を可能にするため、リニアTVで既に実現されているような明確さを、広告が表示されるコンテンツにも求めています。   こうした可視性は他のチャネルでは 、昔から常識とされてきました。例えばウェブでは、バイヤーが通常確認するのは各インプレッション機会のウェブページのURL全体です。また、セラー、消費者、デバイスに関するその他シグナルも確認できます。同様の情報は、モバイルでも確認可能でアプリバンドルを通してシグナルを提供しています。    一方、ストリーミングTVにURLはありません。アプリバンドルはありますが、モバイルアプリのような機能は持ち合わせていません。こうした理由から、コンテンツシグナルが非常に重要となります。     例えば、Pluto TVやfuboといったアプリで考えてみましょう。こうしたアプリは様々なジャンルにわたって数百のチャンネルを提供しています。そして、各チャンネルには豊富なコンテンツが含まれています。バイヤーがバンドルのみを確認した場合、消費者がどの番組やエピソードを視聴しているかまで把握できるとは限りません。コンテンツは、ニュースからスポーツ中継、ドラマまで様々なものがあります。    その結果、安く入札するかもしれません。 例えば、バイヤーはアプリを信頼して10ドルで入札します。しかし、実際にどんなコンテンツがストリーミングされているかは把握していません。バイヤーがより多くの情報を入手し、コンテンツがオーディエンスに関連性の高いものと理解できれば、40ドルで入札したかも知れません。   このようにストリーミングTVで、さらに増す複雑さに対処し、バイヤーが必要とするレベルの透明性を提供するには、プログラマティック広告業界は、新たに、メディア企業からバイヤーへのシグナル送信方法を開発する必要がありました。   コンテンツシグナルの共有方法   コンテンツシグナルは、IABのOpenRTBプロトコルのコンテンツオブジェクトを介して、入札リクエストで共有されます。バージョン2.6には、ストリーミングTVのコンテクスチュアルデータを共有するフレームワークを定義した業界基準が存在します。    各インプレッション機会においてメディア企業はコンテンツオブジェクトのフィールドを用いてジャンル、ライブストリームの状況、コンテンツの対象年齢、言語、チャンネル、TV局、シリーズ番組名、シーズン数、各放送回タイトルなど、希望に応じて番組レベルのデータを送信できます。   そこで、メディア企業はどのシグナルをアドエクスチェンジに送信してDSPに渡すか決断します。バイヤーは、その情報を活用して適切なコンテンツで希望するオーディエンスにリーチする機会となるかどうかを判断します。   例えばマーケターが、イタリア料理の番組のサラダとブレッドスティックを紹介する放送回でファミリーレストランの広告を配信するとします。この放送回での、サラダとブレッドスティック食べ放題の広告は、非常に関連性の高い広告となります。また、マーケターは、望ましくない、もしくは関連性のないコンテクストに広告を表示させないようにもできます。例えば、クルーズ船の広告をハリケーンに関するニュースの後には、配信しないようにする等です。    メディア企業は、どのシグナルを共有するかコントロールできます。特定のシグナルに対してディールを作成することも可能です。例えば、特定のシリーズ番組名をバイヤーに公開せず、「コメディ」というジャンルに特化したインベントリパッケージを作成できます。あるいはランオブネットワーク、ジャンル、特定のシリーズ番組などの透明性のレベルによって、各在庫に異なる価格を設定できます。    コンテンツシグナルの透明性を向上  …

詳しく見る
FreewheelとIndex Exchangeの対談

FreeWheel対談:OpenRTB 2.6でより優れたストリーミングTV広告へ  

会話内容  アンドリュー・カサーレ(Andrew Casale):ストリーミングTVが著しく発展する中、プログラマティック広告エコシステムが革新的なソリューションとその導入に向けてすばやく移行し、市場規模の拡大と視聴者の広告エクスペリエンス向上を同時に実現しています。 特に業界標準であるOpenRTB 2.6が、効率、パフォーマンス 視聴者の体験を改善することを目的としてフレームワークを提供しました。  アンドリュー・カサーレです。Index Exchangeの代表取締役兼CEOです。本日は、デイビッド・ドゥオーリンにお越しいただきました。FreeWheel(英語)の最高プロダクト責任者です。本日はストリーミングにおけるTVコマーシャル枠の改善についてお話します。  デイビッド・ドゥオーリン(David Dworin):こんにちは。お招きいただきありがとうございます。  アンドリュー・カサーレ(以下AC):ご出演ありがとうございます。これまでプログラマティック広告において、業界標準は成長に伴って発展してきました。同様のことが、急速に成長する当チャネルで、ストリーミングTV広告とOpenRTB 2.6の標準でも起きています。幸いにも標準が確立され、FreeWheelは、最も早くに採用した企業の1つです(英語)。まずOpenRTB 2.6は、御社にとってどのようなものか伺います。  デイビッド・ドゥオーリン(以下DD):当社で解決しようとしている大きな問題をまとめるとすれば、既存のプログラマティック広告における標準が、ストリーミング用に作られたものではなかったということです。ディスプレイ広告向けに作られたもので、時間ではなく配置の最適化を行うものでした。ページやアプリ上で表示する広告を様々な広告の中から選別します。つまり、各入札リクエストは、ページ上の1つの広告枠に対して行われます。  しかし、ストリーミングでは異なります。ストリーミングでは、1つもしくは複数の広告ポッドがあり、同時に決断を行います。そうした場合、古い標準を上手く活用する必要性が出てきます。30分間、1時間、1本の映画など、広告ポッド全体で構成し直す過程で、1つの決断を行います。接続している様々なDSPとSSP、ヘッダー入札者にも送信します。また、それらの企業がその他企業にも送る場合があります。  最終的に、何が起こるかと言いますと、例えば、当社が2分の広告ポッドを引き受け、それを30秒で4本の広告、もしくは30秒で2本の広告と15秒で4本の広告に分割します。しかし現行、もしくは古い仕様では、インプレッション機会の度に、それぞれの入札リクエストを作成する必要がありました。つまり単一の決断に対して、数十件の入札リクエストを送信し、さらに、業界全体に入札リクエストを通知することで、様々なバイヤーと様々なデマンドサイドのプラットフォームに送信されるので、数百件の入札リクエストとなります。  当社が、2.6で最も素晴らしいと考えていることは、当社で送信する必要がある入札リクエストの数を圧倒的に減らしてくれることです。TVコマーシャル枠に関する情報を伝達するのに、プログラマティック広告エコシステムのパートナー企業に対して、単一のリクエストを送信するだけで済みます。さらに、当社に対して様々な種類の広告を送信できます。そこで、当社がパブリッシャーに対して 決断を下すことができます。  毎回、それぞれの入札レスポンスを各社からまとめる代わりに、各社から返ってきたレスポンスを一覧で確認できます。   AC:つまり2.6は、最後のストリーミング・プログラマティック広告の活用法であり、新たな時代の始まりということですか?  …

詳しく見る
Topics APIの動画

プライバシーサンドボックス:Topics APIとは

Chromeのサードパーティクッキーの廃止に向けて、Googleは「プライバシーサンドボックス」と呼ばれる一連のAPIを展開します。その内の1つのAPIである「Topics API」は、マーケターが関連性の高い広告を配信し、パブリッシャーがコンテンツを収益化できる一方で、消費者のプライバシーを保護できると提唱しています。この動画では、Index Exchangeの上級主席ソフトウェアエンジニアであるロニ・ゴードン(Roni Gordon)が、Topics APIの仕組みについてお話します。  Topics APIを利用したインタレストベース広告  プライバシーサンドボックスTopics APIは、FLoC(Federated Learning of Cohorts)の提案に代わるもので、消費者をインタレストベースのコホートに分類する代わりに、インタレスト(興味)を反映するものです。FLoCのプライバシー保護措置やGDPRとの互換性についての懸念から、Googleはこの新しいAPIを開発しました。  Topicsでは、サードパーティクッキーのように、消費者の閲覧履歴がウェブ上で共有されることはありません。その代わりに、ブラウザは閲覧履歴に基づいて消費者のデバイスをいくつかのインタレストベースのTopicsに割り当てます。それらのテゴリは、消費者に関連性のある広告を配信するために使用することができます。  例えば、閲覧履歴から、Chromeが音楽、アメリカンフットボール、旅行に関心が高いと把握します。ユーザーは、アメリカンフットボールのスコアをいつもチェックしていたり、いつか行きたいと思っている観光地へのフライトを見たりしています。  次に、Chromeはデバイスを、どのTopicsに割り当てるか決定し、それらのTopicsを利用可能にすることで、インタレストベースの広告を有効にします。  ただし、ユーザーに関するデータや特定の閲覧履歴が、外部の第三者に公開されることはなく、ユーザーのデバイス上のブラウザに全て保存されます。これにより、消費者のプライバシーを守りつつアドレッサビリティと関連性の高い広告を実現します。  Topics APIの仕組み Topics APIがどのような仕組みなのか解説いたします。  …

詳しく見る
Protected Audience APIの動画

プライバシーサンドボックス: Protected Audience APIとは

Protected Audience APIの仕組み Protected Audience(旧称:FLEDGE)は、インタレストグループという概念を利用します。マーケターは、プライバシーを保護し、消費者がウェブサイトを越えて追跡されるのを防止すると同時に、過去に自社のウェブページを訪れたことのある消費者に広告を表示できます。関連性のある広告が維持されつつプライバシーが保護されることは、消費者にとって良い変化です。 現在のサードパーティクッキーを利用したリターケティング まず、ある靴のブランドを例に、現在のリターケティングがどのような仕組みなのかを見てみましょう。  一方、この比較的基本的な例以外では、デモグラフィックやサイトを横断した閲覧行動を基に、消費者に関するかなり多くの情報を収集するためにサードパーティクッキーが使用される場合があります。  そのため、業界とChromeは、サードパーティクッキーを廃止することで、消費者データが追跡されることを防止し、広告におけるアドレッサビリティの価値を維持するモデルの移行に動き始めています。  Protected Audience APIを使ったリターケティング Protected Audience APIを使えば、マーケターはインタレストグループを通じてオーディエンスを定義できます。オーディエンスセグメントのように考えてみてください。例えば、ショッピングカートに商品を入れたが、購入しなかった消費者などです。サイトを越えて追跡可能なサードパーティクッキーとは異なり、インタレストグループは、デバイス上で消費者のブラウザに保存されAPIへのアクセスは制限されます。オーディエンスデータは、マーケター、パブリッシャー、アドテクプラットフォームには共有されません。 Protected Audience APIが、具体的にどのように機能するのかご説明します。再度、冬用のブーツを探して靴のブランドのウェブサイトを訪れた消費者を例にします。 Protected Audienceの大きな違いは、クライアント側のヘッダー入札のように、広告オークションをウェブページからブラウザのSandboxに移行することです。 …

詳しく見る
アドレッサビリティソリューションを解説する動画

クッキー廃止後のアドレッサビリティソリューション

プライバシー優先のアドレッサビリティソリューション サードパーティクッキーは、Safari、Firefox、 Edgeなどのブラウザで既に制限されています。Google Chromeは、2024年までにクッキーを完全に廃止する予定です。これは、私たちが知っているようなクッキーの終焉を告げるものであり、私たちが現在利用しているアドレッサビリティへの比較的単純で不完全なアプローチを終わらせるものです。  私たちの業界には、強化されたプライバシー優先のアプローチを採用する機会がもたらされ、さまざまなIDベースおよび非IDベースのソリューションがすでに登場しています。ここで明確にしたいのは、正解は一つではないという事です。ポストクッキー時代のアドレッサビリティにはさまざまな形式があり、あらゆるチャネルやオーディエンスタイプに対応するソリューションを組み合わせた、より確かなアプローチが必要になるでしょう。  それでは、各アドレッサビリティソリューションを見ていきましょう。  認証ID 認証ID(英語)は、消費者が同意の際に、ログインデータ、メールアドレス、または電話番号のいずれかを選択でき、それを利用し暗号化されたオンラインIDが作成されます。  認証IDは個人のログインに紐づけられるため、マーケターは、IDプロバイダーによってはスマートフォン、ノートPC、さらにはコネクテッドTVなどログインしているデバイス全体でオーディエンスにリーチすることができます。マーケターは、現在のアプローチを根本的に変更する必要はなく、人ベースマーケティングのあらゆる利点を享受することができます。それにはデバイスをまたいだ視聴者へのリーチ、個人レベルのフリークエンシーキャップ、デバイスを横断した測定とアトリビューションなどが含まれます。The Trade DeskのUnified ID 2.0やLiveRampのRamp IDは、これらのIDの一例です。また、安全なデータ共有を可能にするクリーンルーム・ソリューションも登場しています。 未認証ID 次に、未認証のオーディエンス、またはログインや同意しないことを選択したオーディエンスに対する最適化に話を移しましょう。現在は、3つのパスがあります。1つ目は推定IDです。これはデバイスレベルの確率的推論やその他のシグナルを使用して、ブラウザ上で訪問したサイトと消費者を関連付けることができます。次に、パブリッシャーのファーストパーティデータです。今日のプライバシーを重視する状況において、その価値はますます高まっています。そのソリューションの1つがIAB Tech LabとPrebidのSeller Defined Audiencesです。まだ導入の初期段階ですが、このソリューションは標準化されたタクソノミーを提供し、拡張性のあるクロスサイト・ターゲティングを可能にします。その他にも、消費者の閲覧行動に基づいたインテントデータや興味や意図をシグナリングできるコンテクスチュアルマーケティングがあります。マーケターは、関連性のあるコンテンツシグナルを基にオーディエンスにリーチできます。  そして最後に、Googleプライバシーサンドボックスです。これは、クッキーベースの広告に代わる一連のAPIです。Googleは、単にクッキーを無効にするのではなく消費者のプライバシーを保護しながら、コンテンツ制作者にとって効果的な広告を維持するための新しいソリューションを開発してきました。現時点での主な欠点は、これらのソリューションがFirefox、Safari、Edgeのブラウザ環境のニーズに対応していないことです。  …

詳しく見る
Lindsey Kurland Index Explains

ストリーミングTVにおけるプログラマティックギャランティードの仕組み

プログラマティックギャランティードの仕組み プログラマティックギャランティード(PG)は、1社のメディア企業とバイヤー間で、固定価格で綿密にインプレッション数について交渉する取引方法です。これによりメディア企業は、決められた予算内で予測、計画することができます。またバイヤーは、オークションに入札するより確実に広告が配信される保証が得られます。 PGは、メディアバイヤーがテレビ局と交渉し次年度の特定の番組に、キャンペーン予算をコミットする従来のテレビの年間先行取引(アップフロント)と似ています。先行取引をプログラマティック化することに加えて、メディア企業とバイヤーはPGを利用していつでも保証ベースでキャンペーンを実行することができます。 プログラマティックギャランティードの交渉 PGがどのように交渉され、構築されるかを詳しく見てみましょう。まず、バイヤーはメディア企業と直接交渉し、ディールで希望するパラメータを設定します。  価格とインプレッションの他に、PGでは複数の追加条件について交渉することができます。  すべてのディール条件が確定されると、メディア企業はそれらのパラメータに基づいて予測しディールを有効化するために広告サーバーに予約可能なインベントリを決定します。これで、バイヤーは保証されるインプレッション数と費用を正確に把握できます。  プログラマティックギャランティードの有効化 メディア企業とバイヤーが、ディールの構成に合意したところでプログラマティックエクスチェンジを通じて、PGがどのように有効化されるかを見てみましょう。  SSPとメディア企業は、PGの予算のペースと配信を完全に把握できます。その一方で、キャンペーンのペースと配信をコントロールするのはメディア企業の広告サーバーです。  ストリーミングTVにおける保証型取引 保証型取引は、従来のテレビの広告収益の大部分を占める、長く人気のある購入方法でした。プログラマティックギャランティードは、同じ考え方をストリーミングTVに取り入れており、メディア企業とバイヤーが自動化とプログラマティックがもたらす効率性、コントロール、柔軟性というメリットを得られます。  バイヤーは、メディア企業の広告サーバーで、より高い優先順位を持つことでメリットを得られ、キャンペーンがターゲットのオーディエンスにリーチするために完全に配信されることを保証します。また、メディア企業は、保証された取引がもたらす安心感から、より正確に収益予測を立てられます。  そして何よりも、プロセスの大部分をプラットフォームが自動化することで、複雑な取引形態から摩擦が取り除かれ、双方にメリットをもたらします。  ストリーミングTVがもたらす機会について

詳しく見る
lind

ストリーミングTVにおけるプログラマティックディールの作り方

プログラマティックディールの作成 ストリーミングTVには複数のディールタイプがあります。プログラマティックギャランティード、プリファード、プライベートオークション、インベントリパッケージで、それぞれ特長があります。インベントリのキュレーションと、細かいターゲティングが可能なディールは、プレミアムな環境でオーディエンスにリーチしながら効率性を向上し、サプライをコントロールする効果的な方法です。しかし、期待する結果を効果的に生み出すディールを作成するには、ちょっとしたコツが必要です。  それでは、ディールのさまざまなパラメータの注意点を見ていきましょう。  利用可能なインベントリ まず、利用可能なインベントリについてお話します。ストリーミングTVに関しては、プレミアムで関連性の高いインベントリが鍵となります。ストリーミングにおける最大の課題は、バイヤーが利用可能なさまざまなオプションがありますが、同時に、絶好の機会ももたらしてくれます。  消費者がストリーミングTVコンテンツにアクセスできる方法が数多くあるため、数多くのコンテンツ配信業者や配信経路が存在し、オーディエンスにリーチできる新たな機会を生み出します。まず第一に、コンテンツ所有者や放送局から購入できます。また、LG、Samsung、Vizioなどのデバイスメーカーや、Pluto TV、Philo、FuboTVなどのアプリ事業者からも購入可能です。  これらの配信業者は、多様なオーディエンスとプレミアムで独自のコンテンツ体験を提供しているため、より幅広くリーチできるようになります。  ターゲティングパラメータ 様々なターゲティングパラメータが存在しますが、その多くは、ストリーミングに特化したもので、アプリやウェブチャネルには存在しません。コンテンツの対象年齢、ジャンル、ライブ配信のステータス、アプリのバンドルなどのコンテンツ・アトリビューションを基にターゲティングを絞ることができます。また、長さやスキップ可否など、広告ユニットに基づいてターゲティングできます。  さらに、さまざまなファーストおよびサードパーティのデータソースから複数のオーディエンスターゲティングを適用できます。これらのターゲティングパラメータは、ディールが作成された後でも適用でき、キャンペーンを最適化するのに役立ちます。  これらのオプションはすべて、オーディエンスが視聴している際にリーチでき、より関連性の高いコンテンツを配信することでオーディエンスの関心を高め、ライブコンテンツ体験を通じて新たな視聴者にリーチできるようになります。  効率的で効果的なディールを作成 それでは、ディールはどのように構成されているのでしょうか?一例を挙げると、スポーツ好きなオーディエンスにリーチしたい企業は、スポーツのライブ配信インベントリをまとめるディールを構成できます。消費財メーカーは、複数の放送局やストリーミングアプリの料理番組をターゲットに絞り、さらにオーディエンスデータを適用することも可能です。あるいは、成人向けの新作映画を宣伝するエンターテイメント企業は、成人向けのドラマ番組だけにターゲットを絞れます。  正確なターゲティングとインベントリキュレーションには、入札ストリームにおけるコンテンツシグナルの透明性(英語)を頼りにしている事を理解しておくことが重要です。ジャンル、言語、ネットワーク、番組ごとのデータのようなシグナルは、オーディエンスが視聴している動画配信や、どの広告ユニットが配信されるかをメディア企業が明確にできる手段です。  一方で、ストリーミング市場はまだ完全な透明性を目指している過程であり、これらのシグナルは常に入札ストリームで利用できる訳ではありません。あるいは、利用できる場合は、高いコストが発生します。現在では、メディア企業と寄り添って協働することで、インベントリ全体で、どのようなシグナルが利用できるかを理解できます。  それと同時に、市場は透明性を高める方向に進み続けるでしょう。より多くのシグナルが利用されれば、より効果的にディールをキュレーションでき、適切なオーディエンスにターゲットを絞った広告を配信できます。バイヤーは、広告機会とオーディエンスにリーチする場面をよく理解でき、メディア企業はインベントリをさらに収益化することができます。  ディールは、正しいタイミングで、適切な場所にいる、的確なオーディエンスにリーチするためのキュレーションやターゲティングをより細かくコントロールできます。しかし、ここで注意していただきたいのは、ディールに適用するパラメータが多ければ多いほど、規模を狭め、CPMが上昇する可能性があるという事です。キャンペーンのKPIを効率的かつ効果的に達成するためには、希望するオーディエンスに対して利用可能な規模と予算を慎重に検討することが重要です。  また、1対1ディールは、何をどのように購入するかをコントロールできるため人気がありますが、その他にも効率性と高品質なインベントリを確保しつつ、より大きなスケールを提供する、キュレーションされたインベントリパッケージのように、プログラマティックを最大限に活用する機会もあります。  TV購入のプレミアムな特性により、ディールはしばらくの間、主要なプログラマティック取引方法となるでしょう。プログラマティックディールの作成方法を詳しく理解することで、利用可能なインベントリとターゲティング機能を活用でき、貴社のストリーミングTVキャンペーンに大きなチャンスをもたらします。  …

詳しく見る
Blonde, Hair, Person

ストリーミングTVのプログラマティックディールについて

プログラマティックディールのタイプ 従来のリニアTVや放送の取引は、1対1または直接交渉を基に構築され、ストリーミングTVにもその取引方法が利用されています。ストリーミングTVでディールを使った取引をするのは、従来のTVの取引モデルにまで遡り、表示のされ方やプログラマティックインベントリの取引方法が異なります。  TVの在庫を購入する方法は、いくつかあり、従来の広告掲載オーダー(IO)やプログラマティック取引を介した方法があります。  一般的に使われているプログラマティックディールの様々な種類について詳しくお話します。  プログラマティックギャランティードは、手動の先行取引やプログラマティック購入の広告掲載オーダーの代わりとなります。これらは、1社のメディア企業と1人のバイヤー間で、特定の予約されたインベントリを事前に交渉した価格で取引する方法です。  プリファードディールとは、プログラマティック・ノン・ギャランティードと呼ばれることもあり、メディア企業が特定のインベントリを決められた価格でバイヤーに提供する取引です。ただし、このインベントリは保証されていません。バイヤーは、より大きなオークションに移行する前に、合意した価格で最初に入札するチャンスが与えられます。  プライベートオークションは、PMP、つまりプライベート・マーケットプレイスのことでメディア企業が特定のバイヤーをマーケットプレイスへ招待します。メディア企業が希望するフロアプライスを設定し、参加しているバイヤーは、予約または保証されていないインベントリに入札できます。メディア企業は、市場内の全てのバイヤーではなく、厳選されたバイヤーとのみ強化したコンテンツシグナルを共有できます。  これら3つのディールタイプは、メディア企業が発端となります。広告サーバーとSSPは統合され、ディールの仲介の役割を果たします。  最後に、SSPにより選別しまとめられたインベントリのインベントリパッケージまたはオークションパッケージです。バイヤーは、メディア企業の特定のリストを使用して、カテゴリ、ジャンル、ライブ配信、デバイス、フォーマットなどの条件でカスタマイズすることができます。バイヤーは、オープンオークションと同様に入札しますが、効率的なワークフローで、プレミアムな関連性の高いインベントリのみをメディア企業のコレクションから選びます。インベントリパッケージは、ストリーミング市場にシンプルさとスケーラビリティをもたらすと同時に、メディア企業がバイヤーにインベントリへのアクセスを提供する方法の1つでもあります。  これらの取引はすべて、ディールIDを使用して取引されます。メディア企業の広告サーバーまたはSSPによって生成された固有のIDです。ディールIDは入札リクエスト内で共有され、メディアバイヤーは、それを自社側で照合し同じディールIDを持つ入札レスポンスを返すことでディールで取引することができます。  ディールは、プレミアムインベントリが存在するプログラマティック・ストリーミング市場の取引で必要不可欠です。プログラマティックの効率性、コントロール性、柔軟性と従来のTVの購入方法を兼ね備えた完璧な取引方法です。  メディア企業は、さらなる透明性または、付加価値を適切に反映した価格のシグナルを提供でき、メディア企業が、需要とコスト効率のバランスをとり、最適なインベントリの購入方法を選ぶことができます。  ストリーミングTVの機会について詳しく見る

詳しく見る
Adult, Female, Person

ストリーミングTVに特化したApp-ads.txtコンプライアンス

app-ads.txtとは何か、またストリーミングTVにどう透明性をもたらすか? IAB Tech Labの「認可されたデジタル販売者基準(英語)」の一環として、app-ads.txtにより、メディア企業がどの会社が自社のインベントリ販売を認められているのか把握できるようになりました。   この標準が、さらなる透明性をもたらし、なりすましや未承認のリセラー対策、サプライチェーンの安全性をサポートします。メディア企業は、承認されたチャネルを介して安心して、安全に取引できます。また、メディア企業が自社のインベントリの価値を適切に反映して維持することが可能です。  ストリーミングTVのためのapp-ads.txt ads.txtとapp-ads.txtは、ウェブとモバイルアプリで幅広く長期に渡り使用されています。ストリーミングTVは、メディア企業が消費者に対してコンテンツを提供する方法が多いため、実装をさらに複雑にしています。  例えば、Warner Brothers Discovery、A&E NetworksまたはFoxのようなメディア企業は、自社で所有・運営するアプリでコンテンツを配信する場合がありますが、デバイスメーカーであるSamsungやLG、Pluto TVやPhiloのようなサービスにコンテンツの使用権を提供する場合もあります。  インベントリ共有契約のもと、アプリまたはデバイスが全ての広告リクエストの一部と広告販売権を取得し、サードパーティを介さないセラーとなります。このような関係性に取り組むため、IAB Tech LabはストリーミングTV専用に改善したapp-ads.txt(英語)を発表しました。  マーケターがストリーミングやコネクテッドTVへの投資を増やしており、 app-ads.txtの導入が加速しています。しかし、正しい実装とコンプライアンスを確保するには考慮すべきことが多くあります。  これは、サプライチェーンの品質に影響を及ぼすだけでなく、メディア企業の収益にも影響があります。app-ads.txtの入力がなかったり、間違って実装されたりすると、バイヤーが未承認のサプライの価値は低いと思い、入札をしないのでメディア企業は収益を失うことになります。  実際、CTVにおける承認を受けたサプライは、3倍のインプレッション収益(RPM)を獲得しています。  ストリーミングTVにおけるapp-ads.txtの役割 …

詳しく見る
広告ポッド、動画

広告ポッドがサステナビリティの向上にどう役立つか

デジタル広告のCO2排出量を削減 広告業界では大量のCO2を排出している一方、多くの企業がネットゼロ排出量の目標達成に向けて、サステナビリティの取り組みに投資する予算を増やし始めています。  このシリーズの他の動画で説明したように、広告ポッドではOpenRTB 2.6を導入しておりメディア企業、バイヤー、TV視聴者にメリットをもたらしています。ストリーミングTVのプログラマティック取引に効率性をもたらし、さらにはCO2排出量を削減しています。  全体像を見てみましょう。広告ポッドとは、コマーシャル枠内の広告スロットの集まりです。120秒の広告ポットには、15秒、30秒、60秒、90秒の広告スロットが含まれています。 OpenRTB 2.6で広告ポッド入札を導入するまでは、メディア企業やバイヤーは、広告スロットを個別に取引する必要がありました。今ではこうした複数の広告スロットを1つの広告ポッドにまとめ、1つの入札リクエストで取引することができます。  広告ポッドがプログラマティックに更なる効率性をもたらす これにより取引量が大幅に削減されることが理解いただけると思います。具体的に考えてみましょう。木曜日の夜だとして、スマートTVのアプリ上で好きな番組を視聴しています。最初のCMが流れて来そうです。  まず、サプライチェーンで広告ポッドサポートが無い場合のフローを見てみましょう。 つまり1人の視聴者に対する120秒の広告ポッドが、120件の入札リクエストになり、その処理に必要な電力の使用がCO2の排出につながります。さらに、各リクエストには、識別子やアプリのバンドル情報など重複データも含まれます。余分な電力を消費し、大量のデータを送信することになります。  エコシステムで業界全体がOpenRTB 2.6を導入して広告ポッドをサポートした場合 これは大きな削減です。特に、番組に対して多数のコマーシャル枠があり、多数の番組に何百万人もの視聴者がいると考えるとなおさらです。  しかし、広告はまだ表示されていません。収益を確保する方法を考えなければいけません。 分かりやすく説明いたします。1つの広告サーバー、1つのSSP、3つのDSPがあるとします。各DSPには異なる入札レスポンス率があります。  広告の重複を避けて、良い視聴体験を提供するためです。1つの広告ポッド内で、同じ企業やクリエイティブが繰り返し表示されるのは適切ではありません。誰も同じCMを連続で見たいとは思いません。  例えば、DSPのAは、マクドナルドとナイキで3つレスポンスを返す可能性があります。 DSPのBはバイエル、コカ・コーラ、フォードで4つレスポンスを返すかもしれません。 DSPのCは、4つのレスポンスにマリオットとドミノで返す可能性があります。  …

詳しく見る