Googleは、2019年8月27日からアプリ用のads.txtであるapp-ads.txtの運用を開始するとAdMobブログで発表しました。対象はGoogleAdExchangeとGoogleAdMobの両方です。

すでにwebでは2017年からads.txtへの対応が行われていますが、今回Googleはアプリにおいても対応を発表したことになります。
（参考：Google AdMobブログ）

今後、Google以外にも対応するデマンドが増えてくると予想され、app-ads.txtの設置がないと広告枠の収益損失につながる可能性があります。この記事では、ads.txtについての解説と、appにおける導入方法を解説します。

※本記事は2017年に掲載したads.txtの解説記事をapp-ads.txtに対応させたものです。

そもそもads.txtとは

ads.txt（アズテキスト）とは、IAB（Interactive Advertising Bureau）の研究・開発組織IAB Tech Labが2017年5月に発表した「プログラマティック取引において、偽造された広告枠や不正なインプレッションの販売を防止するツール」です。

ツールと言っても、ads.txt自体はその名の通りテキストファイルです。adsとはAuthorized Digital Sellers（認定されたデジタル販売者）の略で、このファイルにサイトの広告枠の販売を許可している広告システムの情報を記載し、公開することで、パブリッシャーは公式に販売を許可している広告システムを宣言することができます。そしてそこに記載された情報をDSPが参照し、リストされている広告システムを通して広告枠の買い付けを行うことができるという仕組みです。

ads.txtが考案された背景には、昨今のアドフラウドの蔓延や広告在庫（広告インベントリ）の再販による、サプライチェーンの透明性の欠如というデジタル広告業界全体の課題があります。パブリッシャーがads.txtで公式に販売許可をした事業者を宣言し、DSPがその宣言を元に買い付けを行うことにより、透明性の高い広告取引を実現しようというのがads.txtの目的です。

app-ads.txtを導入するとどうなるのか

「透明性の高い広告取引の実現」は広告主側に主眼を置いた表現なので、パブリッシャーにとってどういったメリットがあるのか、導入をしないとどういった問題が起こるのかが少し掴みづらいかもしれません。ここでは、パブリッシャーの観点から、app-ads.txtの導入について解説していきたいと思います。

A:app-ads.txtを導入しない場合

B:app-ads.txtを導入した場合

A、Bいずれも、悪質なパブリッシャーによる「アプリなりすまし」にアプリが狙われた場合を想定しています。

Aの場合、DSPは買い付けた広告枠がなりすましによって偽造されたアプリのものだと気づくことができません。そして偽造アプリの広告枠の効果によって、本物のアプリの評価が下がってしまいます。パブリッシャーは、偽のアプリに広告料が支払われてしまうという直接的な被害に加え、なりすまされたアプリに悪評が付き、市場で適切な評価が得られられなくなってしまうという間接的な被害も受けます。また、app-ads.txtに準拠する方針のDSPから買い付けがされなくなるという可能性もあります。

Bの場合、DSPは本物のアプリのapp-ads.txtを参照することで、リクエスト元が偽のアプリかもしれないと疑いを持つことができるので、Aのような被害を未然に防ぐことができます。またapp-ads.txtが参照されることで、パブリッシャーはDSPに安心して買い付けしてもらえるというメリットがあります。さらに、app-ads.txt参照枠に関しては高単価で買い付けされる、と言った可能性も今後は出てくるかもしれません。

app-ads.txtの導入の仕方

では実際にどうすればapp-ads.txtを導入することができるのか、詳しく解説していきたいと思います。前提として、ads.txtとapp-ads.txtは独立して機能します。（ads.txtの記述はweb広告のみ、app-ads.txtはアプリ広告だけに機能する。）
※サブドメインの記述が2019年8月現在だとサポートされないこと以外はads.txtと記述方法は同一になります。

app-ads.txtの書き方

ファイルに盛り込むのは①広告システムのドメイン（必須）、②広告システムから付与されているパブリッシャーのID（必須）、③広告システムとパブリッシャーの関係（必須）、④認証機関の ID（任意）の4つの情報です。①～④は「,（コンマ）」で区切り、販売を許可している経路ごとに行を分け記載します。#記号で始まる行はコメントとみなされます。

①FIELD #1 広告システムのドメイン（必須）

入札者が接続するSSP、エクスチェンジ、ヘッダービディングソリューションなどの広告システムの正規ドメイン名です。システムの運用ドメインが親会社のドメインと異なる場合は、運用ドメインを指定します。SSPやエクスチェンジからドメイン名が指定されていれば、そちらを参考にしてください。

②FIELD #2 広告システムから付与されているパブリッシャーのID（必須）

①の広告システムの委託者またはリセラーのアカウントから発行されているパブリッシャーを識別するためのIDです。ここには、OpenRTB入札リクエスト時にSSPやエクスチェンジが利用している、Publisherを識別するためのIDを記述します。OpenRTBの場合は publisher.idフィールド、OpenDirect（予約型広告在庫のプログラマティック取引など）の場合はパブリッシャーの組織IDになります。

③FIELD #3 アカウントタイプ（広告システムとパブリッシャーの関係）（必須）

ここには「DIRECT」か「RESELLER」と記載します。パブリッシャーが②のアカウントを直接管理している場合は「DIRECT」で、サイト運営者またはパブリッシャーが広告システムと直接のビジネス契約を結んでいることを意味します。管理を第三者に委託し、広告枠の再販を許可している場合は「RESELLER」とします。今後、「DIRECT」「RESELLER」以外のタイプも追加される可能性があります。

④FIELD #4 認証機関の ID（任意）

認証機関で広告システムを識別するIDを記載します。これは①の広告システムにマッピングされます。現在の認証局は、Trustworthy Accountability Group（TAG）で、TAGIDをここに記載します。
たとえば、ex1.com、ex2.com、ex3.comという3つの広告サービスを使用し、いずれもアカウントの管理をパブリッシャーが直接行っており、ex3.comのみ管理を第三者に委託しているアカウントも存在する場合は次のような内容になります。

#sample publisher ads.txt
ex1.com,pub-123,DIRECT
ex2.com,4567,DIRECT
ex3.com,p89012,DIRECT
ex3.com,p34567,RESELLER

この内容を記したテキストファイルを「app-ads.txt」という名前で保存します。

ファイル設定および配置場所

ファイル設定および配置場所については次のルールが敷かれています。

• 設置場所は、アプリストア（iOSはApp Store、 AndroidはGoogle Play Store）の各アプリの詳細ページにある開発元ウェブサイトのリンクで示されているドメインのルートに app-ads.txt というファイル名で設定する
• ウェブサイトからHTTPまたはHTTPSを介してアクセス可能な形で配置する
• Content-Typeは「text / plain」、charsetは「utf-8」の指定が推奨されている

更に詳しい設置方法など詳細はIABから発表されている仕様書をご参照下さい。

ads.txt「ads.txt Specification Version 1.0.2」
app-ads.txt「app-ads.txt Final specification version 1.0」

ルートドメインにapp-ads.txtを設置できない場合、app-ads.txtのPDFファイルの最後にあるAppendix Bに関する記述が参考になります。

Google Ad Managerのヘルプページはこちらをご参照下さい。
※2019年8月現在英語版のみ（邦訳はおそらく近日にも掲載）

app-ads.txtの対応

アプリにおいてはデマンド各社の対応はいまだ不透明ではありますが、webではGoogle社が対応を開始して以降対応するデマンドが増えていきました。おそらく、アプリにおいても同じことが起こるのではないかと予想しています。

現時点でディベロッパーサイトにapp-ads.txtを設置しているパブリッシャーは少ないですが、今後対応していく必要がでてくるでしょう。

fluctでは引き続き、Googleをはじめとしたデマンド向き合い情報収集を行ってまいります。