ピクシブのメディア事業部で広告事業を担当しているdrillです。社内ではアドネットワーク・SSP等の配信広告の運用によるマネタイズを主な業務として行っています。

ウェブページにおけるコンテンツの表示や動作については、それぞれのブラウザの仕様に基づいて正常に働くように気を配るということがウェブ業界の常ですが、これはもちろん広告配信においても例外ではありません。意図したとおりに広告配信が行われていない環境があると、impやclick等の数値の正確性が担保されなくなったり、場合によっては収益的機会損失に繋がってしまうケースもあります。今回は広告配信に関わりそうないくつかの例を挙げつつ、ブラウザの動向に気を配ることの重要性についてお伝えできればと思います。

Better Ads Standards について

まずはGoogle Chrome関連で最近騒がれがちな話から。ユーザーに不快感を与えるようなあまりにアクロバティックな広告の出し方はやめてね、という話です。

Googleも所属する業界団体のCoalition for Better Adsが策定した基準に沿わない広告は、Google Chromeにて不適切とみなされブロックされるというものです。わかりやすく例をあげると、ポップアップ形式で表示される広告や、勝手に音を自動再生する広告等がこれにあたるとされています。以下はスマートフォン例の引用となります。

ちなみに「そんな変な広告の出し方してないから大丈夫だろう」と思ってる人でも意外と気をつけないといけないのが「Ad Density Higher Than 30%」という項目で、広告の総heightがページの総heightのうち30％を占めると該当するものです。通常のページが大丈夫であっても、極端にコンテンツの少ないページ（検索結果0件だった場合のような）においては該当してしまう可能性が考えられます。そこまで厳密に細かいページのチェックを行うものなのかはまだ不明瞭ではありますが、念のため気にかけておく必要はありそうです。（なお、別件となりますが、そもそもGoogleは「コンテンツの無いページへの広告掲載」を禁止しているので、それともあわせて考えたい事項となります。）

米国では2018年2月15日に本格的に導入をしたとの発表がありました。日本国内のサイトはまだ本格的に対象となっていないようですが、近いうちに導入されるという噂がありますので、いつ導入されてもいいように今のうちに見直しを行っておきましょう。

ITP について

こちらも有名です。Intelligent Tracking Preventionの略で、2017年9月にリリースされたSafari 11.0から搭載されたトラッキング防止機能です。

ユーザーのSafariのバージョンが11.0以上であればデフォルトでオンになっている機能です。複数のサイトにまたがったトラッキング用の（3rd Party）Cookieについては有効期限を極端に短く（24時間に）することで、第三者配信によるリターゲティング等のCookieを使用した配信を大きく制限し、これによってユーザーのプライバシーを保護するものとされています。

ブラウザがSafariに限定されるため、デスクトップにおいての影響範囲は小さいと考えられますが、iPhone・iPadにおいては多くのユーザーがSafariを使用しているため、それなりの数が影響範囲になります。ちなみにpixivのスマートフォン版（Web）においては、2018年2月時点で43％のユーザーがSafari 11.0以上からのアクセスでした。

対象となるユーザーに対してはリターゲティング配信やコンバージョン計測に制限がかかりますので、広告主側が認識する効果が低下して、入札単価や予算の縮小につながり、結果メディアの収益も低下する可能性があるという流れです。

広告配信事業者は、ユーザーのオプトインを得ることでこの問題を解決しようとしたり、Cookieに代わる新たな計測手法の確立を目指したりと、現在も各社ごとに方法を模索しています。パブリッシャー側としてもこの流れを理解した上で、ブラウザごとの数値把握を行うことや、パブリッシャー自身が1st Party Cookieを使用した分析や価値提供を行えるようになることが望ましいです。

`document.write()`の扱いについて

Google Chromeにおいて通信が遅い等の条件を満たした時にdocument.write()を実行しなくなるというもの。ユーザーの負荷を軽減して、より快適なアクセスを提供することを目指して昔からGoogle Chromeが行っている制限となります。

すでに2016年12月のGoogle Chrome 55から2G環境では起こっていることですが、将来的には対象環境が拡大していき、遅い3Gや遅いWi-Fiでもdocument.write()の実行が行えなくなるといわれています。そのため、document.write()を使用した広告配信が行われている場合、通信環境による制限が拡大した際により影響を受けていくこととなります。そもそもGoogle Chromeにおいて、サイトでdocument.write()を使用すること自体が基本的には非推奨となってきているので、広告に限らず見直しを入れていきたい部分です。

なお、iframeを使用した配信については問題無いようなので、iframeで切り出して広告配信を行っている場合やDFPを使用している場合は気にしなくていい話です。（iframe内でのdocument.write()の実行についても制限対象外とされています。）

Google ChromeにおけるSymantec証明書の扱いについて

要約すると、Symantecが昔に発行した証明書をGoogle Chromeが信頼しなくなるため、新しい証明書に置き換える必要があるという話です。

Googleからの公式なアナウンスはこちらになります。

公式発表のスケジュールを見ていくと、2018年3月15日にリリースされるGoogle Chrome 66のベータ版から、2016年6月1日以前に発行されたSymantec証明書に対する信頼が破棄されるとあるため、それまでに有効な証明書に更新されている必要があります。

パブリッシャー自身の対応はもちろんですが、気をつけたいのは第三者配信事業者についてです。Google Chromeからのアクセスにおいて第三者配信が2016年6月1日以前のSymantec証明書を使用している場合、メディア自体が危険視されることはなくとも、その第三者配信広告のリクエストが切れてしまい収益のロスに繋がる可能性があります。（正式にそういった扱いになるかは不確定で明言されてませんが、ピクシブ社内でGoogle Chrome Canaryで確認したところリクエストが切れる状況が確認されました。）

現在はGoogle ChromeのDev Toolsでのアラートの確認が可能なので、現在配信を行っている広告事業者にも対応状況を聞きつつ、問題が起こらないように準備を整えておくことを推奨します。