最近耳にすることが増えた「ads.txt（アズテキスト）」。
これはオンライン広告の透明性を高めて広告詐欺を減らすための仕組みとして、
IAB（インタラクティブ・アドバタイジング・ビューロー／米国のインタラクティブ広告業界団体）
が提唱しているものです。
そもそも「インターネット広告の仕組みは説明できますか？」
この記事では、ads.txtが必要になった背景や仕組み、
そして実際の書き方や設置方法も紹介していきます。
＼ 読みたい場所にジャンプする ／
メディアにおけるads.txtへの対応状況
国内大手SSP「Adgenerationを運営するSuperShip調べ」で、国内でads.txtを設置している
インターネットメディアは、2017年の10月26日時点で約2.35％でした。
- ＜調査結果サマリー＞
・「ads.txt」 は240,459ドメイン中、5,654ドメインで導入されており、導入率は2.35%
・UU数上位1,000の導入率は17.50% と、大規模媒体を中心にads.txtの導入が急速に進んでいる
・指定されている広告システムは「Google」で、導入サイトの91.74%で指定されている
・広告システムの指定数は1-9個が最も多い（平均指定数は20.56個）
・第三者の広告システムを経由した「RESELLER」が51.16%と、直接管理を示す「DIRECT」をわずかに上回った
広告システムの中で最もGoogleが指定されている
ads.txtファイルは、パブリッシャーが許可した広告配信事業者のみを
リストアップするテキストファイルです。
このファイルの中で、Googleが最も多くの指定を受けている理由は、
以下の３つが挙げられます。
- 圧倒的な市場シェア
- 高いブランド力
- 技術力と透明性
これらの理由から広告事業者の経由の有無問わず、
Googleの広告システムが活用されています。
詳しい解説はこちらで行っています。
ads.txtのトリビア「Googleが複数ある？」
最大手ブログ事業者の設定ミス
2017年10月に大手のブログシステム提供会社が誤ってads.txtを設定したため、そのブログシステムを使っているメディアに対しGoogle AdSenseから警告が出て話題になるなど、運用に関しても混乱が起きるという出来事がありました。
ここでは、オンライン広告におけるRTBの仕組みからads.txtについて解説しますが、後半は技術的な話も含みます。全員が技術的な記述方法を身に付ける必要はありません。
＼ 読みたい場所にジャンプする ／
ads.txtの前提： プログラマティック広告の現状と経緯
ads.txtはなぜ必要なのかを解説する前に、現状のオンライン広告（プログラマティック広告）がどのような経緯・仕組みで成り立っているのかを簡単に説明します。
オンライン広告はオンラインメディアの広告枠（在庫）と呼ばれる空きスペースを広告主が
買うことで成り立っています。
基本的な構造や仕組みはテレビや雑誌などの紙媒体の広告取引と本質としては、
変わりません。
たとえば最も古くから行われているオンライン広告のひとつとして
「トップページの一番上に表示されるバナーを1週間掲載するためには1000万円」
といった広告メニューがあります。
このような伝統的な期間保証型の広告の場合は、メディア自身が広告枠を管理しているので、
「どの広告案件のどんな広告素材がどこの枠にいつ掲載されているのか」が明確で、
広告主も掲載を直接確認でき、広告費の支払先も明確です。
このような広告取引は現在も行われており「純広告」と呼ばれています。
しかし、この仕組みだけではメディア自身で広告案件を獲得してくるだけでは限界があります。
マネタイズのためにメディアのトップ、右上、右下、記事内、記事下など広告枠の場所もどんどん増えていくため、次第にメディアレップやアドネットワーク業者が間に入って広告取引を仲介する仕組みに変わっていきました。
このように仲介立って配信される広告を、空き枠広告と呼びます。
すると、成果を上げるためによりターゲティングしようとする動きが出てきます。
広告主側も、広告効果を最大化するためのメディアの選定やコンテンツの内容に合わせた広告、訪れた人の属性（性別・年齢・趣味嗜好など）に合わせた広告を掲載しようとすると、とても人の手では運用しきれません。
そこでより適切にターゲティングした広告の自動取引（オークション）をリアルタイムに行う
プログラマティック広告が誕生しました。
RTB（Open Auction）の仕組み
プログラマティック広告では、
さまざまな広告の取引形態を組み合わせて最適に運用することを目指しています。
広告主が予算やターゲティングを指定し、メディアが自分の販売したい広告枠を指定するだけで、SSPやAd Exchange、DSPといった業者がそのメディアに訪れた読者に合った広告を自動的に選別してリアルタイムに掲載してくれます。
この仕組みをRTB（Real-Time Bidding）と呼びます。
RTBの基本的な仕組みを図1に示しました。
RTBの基本的な仕組み
- オンラインメディアに読者が訪れる
- SSP/Ad Exchangeを介して、どのページに読者が訪れたかという情報が各DSPに送信される
- それぞれのDSPで、ページのURL／枠の位置／ページのコンテンツ／訪れた読者の過去の行動履歴／属性情報（性別・年齢・趣味嗜好など）などをもとに各社独自のアルゴリズムを用いて、いくらで広告を出したいかを決定する
- SSP/Ad Exchangeが最も入札額の高いDSPからの広告で落札する
- 落札した広告主の広告をメディアに掲載する
RTBでは、ユーザーがアクセスするごとにこうした処理が瞬時に行われています。
このような仕組みで、効率的に広告枠のマネタイズを行いたいメディアのニーズ、
広告の掲載を効率的に行いたい広告主のニーズを満たし、急速に広がっていきました。
RTBを悪用したアドフラウド（広告詐欺）の出現
しかしそんなRTBにも良くない一面がありました。
いわゆる広告詐欺（アドフラウド）です。
RTBではSSPやAd Exchange、DSPといった業者が自動的に広告と広告枠をマッチングします。
そのため広告主側で実際に広告がメディアに掲載されていることを確認するのは難しく、
メディア側もどんな広告が掲載されているかをすべて把握することはできません。
そのため、実際に広告が掲載されているかのように装って、
広告費をだましとる詐欺が横行しています。
その手法を表したのが図2です。
先ほどの図1と見比べてみてください。
悪意を持った第三者が、広告枠を販売するメディアになりすましています。
図2の例では、悪意を持った第三者が、「自分がテックライフだ」と偽り、②の情報を改ざんして、広告のリクエストを送信します。DSPはその情報を信じて入札し、広告がニセのサイトに掲載されます（③④⑤）。
悪意のある第三者は嘘だとばれないように、その広告をたまにクリックしたり、
動画を再生したりという偽装も行います。
DSPは成果に応じて広告費をSSPに支払い、SSPはアカウントIDの情報に従って、
お金をメディアに分配します。
このSSPのアカウントIDが悪意を持った第三者のものであることから、
不正な収入を得られるという構造です。
「メスボット」と呼ばれるアドフラウドボットは、
この手法で1日に300～500万ドル（3.27億～5.45億円）稼いでいたという調査結果があります。
＼ 読みたい場所にジャンプする ／
ads.txtはどうやってアドフラウドを防ぐのか
SSPはアカウントIDの情報に従って収入を分配するので、「このSSPのアカウントIDが適切なものかどうか」を確認できれば、前項のような不正は防げます。
SSPのアカウントIDが適切なものかを確認するための仕組みがads.txtです。
図3に示すように、テックライフが、自社メディアにads.txtを設置して、使っているSSP/Ad ExchangeとそれぞれのアカウントIDをそこに記載しておくことで、悪意を持った第三者が「自分はテックライフだ」と偽ったとしても（②）、DSPがテックライフのads.txtを確認すれば（③）、アカウントIDが一致しないために偽物であることがわかります（④）。
結果として入札も行われないため、不正に収入を得ることもできなくなります。
仮に、悪意を持った第三者が図3 ②のSSP1 アカウントIDを正式なads.txtに書かれているアカウントIDと同じものにして広告のリクエストを送信したとしても、その収益は第三者のものにはならず本来のメディアに分配されるため、広告詐欺を行う金銭的なインセンティブがなくなります。
このように簡単な仕組みでアドフラウドを防止できることから、
いま、ads.txtは世界中で実装が進んでいます。
どういう時に必要なの？
ads.txtが不正取引対策に活用されていることは理解できたと思います。
ではどういう時に必要なのでしょうか？
下記のいずれかに該当する2つ以上の広告システムにまたがって取引をしているときです。
- SSPを使っている
- Ad exchangeを活用している
- Headerbiddingを行っている
- PTD(広告スタック）を使っている
反対にAdsenseなど単一の広告ネットワークしか掲載していない場合は、
あっても無くても特に問題はありません。
＼ 読みたい場所にジャンプする ／
ads.txtの設置方法（※2024年3月時点のads.txt Version 1.1）
ads.txtは簡単に設置できますが、その設置方法や内容の書き方に細かい決まりがあるため、
その決まりに添って運用していくことが必要です。
ここからは、ads.txtの設置にかかわる媒体社・プラットフォーム向けに解説していきます。
ads.txtにもバージョンがありますが、
ここでは2024年3月時点の「ads.txt バージョン1.1」の仕様に沿って解説します（公式文書はこちら）。
DSPは決まりに従ってads.txtを確認するので、設置方法や内容が誤っていると、
広告枠に広告が出なくなり、広告収入が得られなくなるリスクがあります。
そのため、ads.txtの作成やアップロードはよく注意して行う必要があります。
SSPやパブリックトレーディングデスクがを活用している場合はシステムや担当者の指示に従えば基本OKです。
- ads.txtはルートドメインに設置する
- ads.txtに関する問い合わせ窓口の情報（任意）
- パブリックトレーディングデスクががいるときはそのシステムドメインを明示的に記述しておく
- サブドメインにおいては基本ルートの内容と異なるときにのみ使う
- 一部ホスティングサービスの初期ドメイン（サブドメイン）は例外的な扱いをする
ads.txtはルートドメインに設置する(これもちょっと誤った認識）
まず、一番多いのは設置場所の誤りです。
以下、テックライフ（https://tech-life-media.com/）を例にして説明します。
ads.txt の設置場所は以下のとおりです。
○ https://tech-life-media.com/ads.txt
× https://sub.tech-life-media.com/ads.txt
上が正しい設置場所、下が誤った設置場所です。
なお、ads.txtのファイル名は必ず小文字で「ads.txt」とします。
メディアをサブドメインで運用している場合、「https://sub.tech-life-media.com/ads.txt」のみに設置してしまう間違いが多くありますが、ads.txtは正しくは「ルートドメイン」と呼ばれる、サブドメインを含まない「tech-life-media.com」に設置する必要があります。
なお「https://www.tech-life-media.com/」などの「www」もサブドメインと同じ扱いです。
「www」が付かないルートドメインにads.txtを設置する必要があります。
× https://www.tech-life-media.com/ads.txt
サブドメインでメディアを分けて運営していない場合は、設置場所については以上です。
サブドメインで別メディアを運営しており、
それぞれでads.txtの内容を変えたい場合の説明については、後ほど説明します。
正確には広告システムに申請・登録したドメインのルート内に置くです。
ホスティングサービスの初期ドメインは例外的に扱われる
Googleの広告システムでは、一般的なホスティングサービスの初期ドメイン（サブドメイン）に関して
例外的に扱われることがあります。
サイトの URL に関するエラー メッセージが表示された場合、そのサイトのプラットフォームはサポートされていません。WordPress.com などの一般的なホスティング プラットフォームでは、サブドメインを直接追加できます。
アド マネージャーに子サイトを追加する – Google アド マネージャー ヘルプ
| appspot.com |
| at.ua |
| azurewebsites.net |
| blog.hu |
| blog.jp |
| blox.pl |
| blogspot.com |
| cafe24.com |
| cocolog-nifty.com |
| com.nl |
| doorblog.jp |
| egloos.com |
| fc2.com |
| fc2web.com |
| firebaseapp.com |
| free.fr |
| github.io |
| hateblo.jp |
| hatenablog.com |
| hatenablog.jp |
| hatenadiary.com |
| hatenadiary.jp |
| herokuapp.com |
| infoteur.nl |
| jp.net |
| jpn.org |
| jugem.jp |
| ldblog.jp |
| livedoor.biz |
| livedoor.jp |
| main.jp |
| narod.ru |
| naturum.ne.jp |
| pixnet.net |
| sakura.ne.jp |
| blogs.sapo.pt |
| sblo.jp |
| seesaa.net |
| blog.shinobi.jp |
| blog.so-net.ne.jp |
| sourceforge.jp |
| sourceforge.net |
| ssl-lolipop.jp |
| blog.ss-blog.jp |
| squarespace.com |
| startpagina.nl |
| 3dn.ru |
| ti-da.net |
| tripod.com |
| tumblr.com |
| typepad.com |
| ucoz.ru |
| ucoz.ua |
| uol.com.br |
| web.app |
| wordpress.com |
| wpblog.jp |
| wpengine.com |
| yolasite.com |
| xsrv.jp |
| 000webhostapp.com |
これらに該当するホスティングサービスのの初期ドメインは例外的にGoogleの広告システムでは
登録されたサブドメインアドレス/ads.txtを直接クロールしに来ます。
PTD（パブリックトレーディングデスク）を使っている場合
PTD（パブリックトレーディングデスク）やGCCP（Google認定パブリッシングパートナー）
がと提携している場合は、その企業の担当者がads.txtを適宜管理します。
FourM（一例）と連携している広告配信事業者（SSP/AdX）の情報が反映されます。
この場合、我々パブリッシャーはメールなどで来る指示に従うだけで基本OKです。
＼ 読みたい場所にジャンプする ／
ads.txtの記述方法
ここからは自社で広告事業者を選定・接続したりGAMを運用する人向けに
実際の記述方法を例を用いて解説します。
- サイト情報と広告プラットフォーム情報を記述（推奨）
- どのSSP/Ad Exchangeに許可を与えるかという情報（必須）
- ads.txtに関する問い合わせ窓口の情報（任意）
- サブドメインに関する情報（適宜）
ads.txtの記述する順序はフォーマットに従っていれば順不同になっても問題ありません。
①サイト情報と広告プラットフォーム情報を記述（推奨）
ads.txtの冒頭１行目に、OWNERDOMAINディレクティブで、
まず管理するサイトのドメインを記入します。
ルートドメイン上にある場合は、ルートドメインのアドレスでサブドメインの場合は、
サブドメインを入れます。
次に、MNANAGERDOMAINディレクティブで使用している広告プラットフォーム
のドメイン名を一つ入れます。
ここで指す広告プラットフォームとは、第三者PrebidWrapperなど、
広告の運用を代行している事業者のことです。
当メディアは、AnymindグループのFourMのPrebidWrapperを借りているため、
OWNERDOMAIN=tech-life-media.com
MANAGERDOMAIN=fourm.jp
このようになります。
これをすることで、次回解説するサプライサイド事業者側のアドフラウド対策である、
serllers.jsonの透明性が強化されより代理店との関係を明確にすることができます。
行内の「#（シャープ）」以降に続く文字列はコメントとみなされます。
わかりやすいようにどの行が何を示しているのかのメモを書いておきましょう。
行内の半角スペースやタブは無視する仕様になっているため、
見やすくするために半角スペースやタブを入れても構いません。
個人的にコメントの余白を——-（ハイフン）で区切って線にして見やすくします。
②どのSSP/Ad Exchangeに許可を与えるかという情報（必須）
まずは一番重要な①「どのSSP/Exchangeに許可を与えるか」
という情報の記載方法について説明します。
1行に最大4つの情報（コメント除く）を記載でき、1～3つ目は必須項目で、
4つ目は適宜記入の項目です。
それぞれの情報を「,（カンマ）」区切りで記載します。
これらの情報のセットを、SSPのアカウントごとに1行ずつ記述します。
| 1つ目の情報 （SSPドメイン） | SSP/Ad Exchange を示します。Google AdSense/Google adxの場合は「google.com」と記載します。 |
|---|---|
| 2つ目の情報 （アカウントID） | アカウントIDです。1つ目に記載したSSP/Ad Exchangeに問い合わせて、自分のアカウントIDを調べる必要があります。グーグルの場合は、AdSenseにログインした後の、「アカウント情報」のページで確認できます。 |
| 3つ目の情報 （管理タイプ） | 2つ目に指定したアカウントの管理タイプで、自分で管理しているアカウントか、代理店等の第三者が管理しているアカウントか、を「DIRECT」または「RESELLER」で示します。わかりやすい例では、AdSenseからの収益が自分の口座に直接振り込まれる場合は、「DIRECT」、代理店を経由して支払われる場合は「RESELLER」となります。 |
| 4つ目の情報 （TAG ID） | 1つ目に記載したSSP/Ad Exchange が、TAG（Trustworthy Accountability Group）という認証団体によって認証されている場合に、記載します。 こちらは、SSP/Ad Exchange から指定があった場合には記載します。たとえばグーグルの場合には「f08c47fec0942fa0」となります。 |
ads.txtのトリビア「Googleが複数ある？」
上図の様にGoogleが複数出てくることがあります。
しかし、これらのうち6つは筆者個人のパブリッシャーアカウント（pub-id）です。
なぜこのようになるのかと言うとAdsenseとGoogleアドエクスチェンジ（GAM）は
別のプロダクトとして扱われているためです。
Adsenseでは申し込みが終わるとそれに付随したパブリッシャーアカウントが発行され、
Adsenseと言うサービスプロパティーに関連付けられたpub-idが発行されます。
Googleアドエクスチェンジにおいては、Googleより招待を受けアカウントが作成されると、
そのプロパティーに応じたpub-idがさらに一つ発行されます。
この時MA（アカウント管理）を行っている場合、親のAdxのpub-idも合わせて
記述することになります。
google.com, pub-親, DIRECT, f08c47fec0942fa0
google.com, pub-親, RESELLER, f08c47fec0942fa0
google.com, pub-子, DIRECT, f08c47fec0942fa0
google.com, pub-子, RESELLER, f08c47fec0942fa0
google.com, Adsenseのpub-id, RESELLER, f08c47fec0942fa0このため必ず４行になり、ここにAdsenseが加わると５~6行になります。
なぜ、DIRECTとRESELLERがあるのかと言うと、
Google adxはリアルタイム広告オークションシステムであるため、
再販と直販を兼ねるためです。
SSPなどでも稀に収益性の向上を目的にDIRECTとRESELLER両方登録を依頼される
ケースがあります。
上図、国内の広告プラットフォームadstirの記述です。
各事業者も必ず収益性と販売強化のためGoogleの広告システム（Adsense+Adx）を
活用しています。このためGoogle.comと言う記述が複数回にわたって出てくるわけです。
③ads.txtに関する問い合わせ窓口の情報（任意）
「ads.txt（広告掲載）に関する問い合わせ窓口の情報」は、書かなくてもいい任意の項目です。
ads.txt（広告掲載）に関する問い合わせ窓口がある場合は、問い合わせ先を記載してください。
この項目には、メールアドレス、電話番号、ウェブ問い合わせフォームのURLなどを記載します。なお、URLに半角スペースが入る場合は「%20」などURLエンコードした値を記入する必要があります。
図5では問い合わせフォームのURLを記載していますが、
メールアドレスの場合は次のように記載します。
contact=contact@sample.com
もちろん問い合わせフォームのURLと電話番号やメールアドレスを併記することも出来ます。
contact=contact@sample.com
contact=https://tech-life-media.com/contact-us/
contact=xxx-xxxx-xxxx
おそらく書いてあるからとプログラマティック直接取引が増えると言うことも無いと思います。
＼ 読みたい場所にジャンプする ／
④サブドメインに関する情報（適宜）
最後のサブドメインに関する情報は、
前述した「サブドメインで別メディアを運営しており、それぞれでads.txtの内容を変えたい場合」
に必要になる項目です。
- SSPやAdsenseのアカウントをドメイン毎に分ける（サイト所有者が異なる場合）
- サイト毎に使う広告プラットフォーム（Wrapperが異なる場合）
基本的にこれらに該当する時にサブドメインに関する情報（適宜）記述します。
記述内容
インプレスの場合がこの「サブドメインで別メディアを運営しており、それぞれでads.txt の内容を変えたい場合」に該当しますので、実際にどのように用いるか解説します。
まず、正しい設置場所である、
「https://tech-life-media.com/ads.txt」に次のような内容を記載します。
subdomain=game.tech-life-media.com
subdomain=news.tech-life-media.com
そして、それぞれのメディアのサブドメインのルートにもads.txtを設置します。
「ゲームテックライフ」用のads.txt設置場所
別メディア「テックライフニュース」用のads.txt設置場所
これらのサイトは存在していませんん。
この場合、ルートドメインである「https://tech-life-media.com/ads.txt」にはサブドメイン情報のみを記述し、各サブドメインのads.txtにはそれぞれのSSP情報を記述します。
ルートドメインの「https://impress.co.jp/ads.txt」にもSSP情報が必要な場合は、サブドメイン情報に加えて「https://impress.co.jp/ads.txt」用のSSP情報も記述します。
このように、サブドメインで分かれている場合に、DSPに対して「サブドメインでSSPのアカウントが分かれているから、ちゃんとこっちの情報も見てくださいね」と示すためには、ルートドメインのads.txt内で「subdomain=」を記述して明示的に設定する必要があります。
＼ 読みたい場所にジャンプする ／
ads.txtのチェック方法
ここまで説明してきたように、ads.txtはチェックポイントがいくつかあります。
すべてのチェックポイントを手作業で調べることは、意外と手間がかかります。
- 広告システムのインターフェイスを活用する
- 広告事業者の担当者に確認をお願いする
- サードパーティ製ツールを活用する
これらの方法で簡単にチェックしてもらうことができます。
広告システムのインターフェイスを活用する
Adsenseを含む広告プラットフォームはダッシュボードのユーザーインターフェース上に
ads.txtのクロール状態を表示する機能があります。
これを活用することで簡単にads.txtの記述の不備を確認することができます。
広告事業者の担当者に確認をお願いする
各デマンドにアカウントマネージャーなどのパブリッシャー担当者が
割り当てられたりしている場合は、その担当者宛にメールを送信することで
システムのクロール結果と目視で記述状態を確認してもらうことができます。
広告事業者名 担当者名 様
お世話になっております。
サイト名の氏名（法人名＋担当者名）です。
自社アカウントにおけるads.txtの記述に不備が無いか確認いただけますでしょうか？
以下ads.txtのURLです。
ads.txtのURL
お手数おかけしますが宜しくお願い致します。
署名
サードパーティ製ツールを活用する
パブリッシャーのads.txtを導入支援するために様々なアドテクプロバイダーが
サードパーティーのads.txtチェッカーを開発して提供しています。
ads.txt Validator (提供元：ads.txt Guru)
上記サイトにads.txtのURLを入力するだけで、設置場所、文字コード、
構文のチェックを自動的に行います。
＼ 読みたい場所にジャンプする ／
まとめ：適正管理が必要なads.txt
今回は、広告枠のなりすまし対策のads.txtをインターネット広告の仕組みと合わせて解説しました。
- 複数のデマンドと接続するときに必須
- 記述漏れは収益の低下に繋がる
- 定期的な更新が必要
まとめると以上の通りです。
ファンコミュニケーションズ社さんのnendの様に突然広告ネットワークがサービスを撤退・廃止する
場合もあるので常に最新を保てるよう管理のしやすい状態で記述しておくようにしましょう。
コメント