iOS 9でリリース後の話題をさらったのは広告ブロックが許可されたことですよね。実際に広告ブロックを入れるような人はクリックすることもなく、アクティビティが低いから広告主のためにもならないから広告ブロックをした方が良い、という意見もあります。とはいえ、今後の可能性としてはそう穏やかに終わらない可能性もあると思っています。
僕自身は変な広告を見るのが好きだし、Facebookの居住地はUSのままにしているので「英語圏だと、こういう広告で攻めてくるのかー、これは面白いな」みたいな気づきもあるので、入れることはありませんが可能性をいろいろ考えてみました。僕は広告の専門家ではないので、用語とか変なところがあるかもしれませんが、ご容赦ください。
一番穏やかなケース
広告を表示するものの、クリックする確率が低いユーザが減りました。出稿した広告数に対するクリック数が増えて、広告を出す費用に対して広告効果がアップしました。めでたしめでたし。
難易度ハード
最初は、アーリーアダプターぐらいしか使わなかった広告ブロックですが、徐々に多くの人が使うようになりました。当初は有料版しかなかったのですが、有料版の広告ブロックアプリが、体験版として一日に数時間だけ使える無料版をリリースしはじめたのが普及のきっかけです。
大手のサイトでも、あきらかにページビューごとのクリック数が少なくなりました。広告料収入はフリーミアムの極めて重要な構成要素で、フリーで楽しみたいと思う人にとっては必要悪的でしたが、大本営が広告ブロックを推奨している今、広告は本当の悪として扱われるようになりました。動画広告ですらも非難の対象となり、正義厨が無断転載しつつ広告を除外するといった活動を日々行っています。
ウェブの収益性は悪化の一途です。多くのウェブサイトは広告ブロックが難しいモバイルアプリにシフトしていきました。ウェブはもはや、コストを掛けて新機能を入れて発展させていくものではなく、FAXのように古い人のための窓口として残るのみです。
Dante Must Dieモード
201X年のWWDCの発表でCEOが壇上でSafariの新機能を発表しました。拡張機能を入れなくても、デフォルトで広告をオフする機能です。UIWebViewやWKWebViewでも有効です。ユーザは「なにもしなくても」最初からかつてないほどのすばらしい高速なウェッブブラウジングが可能になったのです。データ通信の使用量も減り、バッテリーの持ちも良くなりました。MLB.comで、San Francisco Giantsの結果を知る速度は某Androidよりも3倍高速です。
オプトアウトでオフにすることはできますが、ビューを見ても反応するかどうかよくわからない3Dタッチをいくつも組み合わせた難しいところに設定が隠れているので、一般人がオフにすることは基本的にありません。
毎年WWDCはサードパーティアプリの葬式会場になりますが、今年はウェブ広告ブロックの拡張が犠牲になったようです。
One More Thing。アプリの審査基準が厳しくなり、サードパーティ製の広告SDKを使っていると審査が通りにくいという噂がたちました。もちろん、本当にそれらをすべて却下してしまう事態になれば独占禁止法違反ですが、どうも広告SDKを入れると審査の期間が伸び、リリース時期が読みづらくなっているように思えます。クリスマス時期などの商機を逃したくないアプリベンダーは、サードパーティ製の広告SDKを徐々に使わなくなっていきました。
もちろん、スマートフォンOSの競合メーカーも黙ってはいません。競合メーカーは広告もビジネスの柱です。Android Xで広告ブロックを導入しますが、ユーザは予め許可する広告を細かく指定できます。このメーカーの広告は出稿時にジャンルを細かく設定できるため、欲しいユーザに適切に広告を配信します。もちろん、他のアドネットワークの広告はジャンル情報が取得できないため、デフォルトオフです。
広告を表示する側のレジスタンス活動
売上を上げて利益を上げるのが企業の存在理由だとすれば、ウェブページの作成にコストを掛けて、無料で見られる立派なウェブサイトを作ることそのものをビジネスとする場合、極端な話、広告がメインで、記事やウェブサイトは客寄せでしかありません。もちろん、広告のために嘘の内容を書いたり、広告であることを隠したネイティブアドなんかはフェアなビジネスとはみなされないので、企業価値を毀損してしまいます。
広告ブロックの仕組みは単純です。HTTPアクセスがあるたびに、拡張機能はそのURLを許可・不許可を判定して返します。その結果を元にブロックするだけです。
広告ブロックを検知して、広告がブロックされる場合、広告APIが提供するJavaScriptで作られるDOMが存在しないということで確認が可能です。つまり、広告がブロックされていたら、それを検知してコンテンツそのものを表示させないこともできます。もちろん、全部を見せないようにしてしまっては「読みたい」という気持を喚起できないので、最初の数段落だけ見せて、「続きを見るには広告をONしてね」と出すだけです。簡単ですね。
もちろん、HTTPアクセスがなければそもそも広告ブロックは仕事をすることもできません。また、URLが本家のサイトと同じであれば選択式のブロックも難しいでしょう。広告SDKにはサーバー版が登場します。Ruby on RailsやPlay Frameworkに組み込むだけで、一部のパスを、広告配信サーバに転送させることができます。広告ブロックアプリはこれでは手も足も出ません。かといってコンテンツを過剰にブロックしてしまえば、ブロックアプリはバグとして対応せざるを得ません。また、サーバーサイドでHTMLをレンダリングする際に、広告のコンテンツを埋め込んでしまうこともできるでしょう。欠点はキャッシュとの相性が悪いことですが、ビジネスの生き死にを左右する事態なので、そんなのは蚊帳の外です。キャッシュは3秒以内にexpireするのがベストプラクティスとして語られるようになります。
これまでの話はほぼ創作ですが・・・
これまでの話は、@akisuteとかとチャットしながら出てきた可能性についてをまとめた内容ですが、可能性としてはゼロではないと思います。いよいよ、パンドラの箱が開いてしまったという感じがします。
