[Founder Notes #1] 広告主はすでに来ていた。パブリッシャー側に受け止める仕組みがなかっただけ。

notion image
ここ数年、私たちは数十社のパブリッシャーと話してきました。ケアサービス、コミュニティ、コマースアプリ、コンテンツプラットフォーム。事業の形はそれぞれ違っていましたが、つまずく瞬間は驚くほど似ていました。
広告を売り始めようとしているパブリッシャーに会うたび、同じような場面を何度も見ました。広告の問い合わせが受信箱に届く。本来なら良い知らせです。誰かが費用を払って、そのサービスに広告を出したいと言っているのですから。けれど担当者は、返信を前に手が止まります。
「いくらで提示すればいいのか? どの広告枠を売れるのか? クリエイティブはどこで受け取り、スケジュールはどう押さえるのか? 終了後のレポートや精算は誰が対応するのか?」
トラフィックも、熱心なユーザーも、向こうからやって来る広告主さえいる。それでも、広告ビジネスを始めること自体が大きな難所でした。これは、私たちのチームがその状況を見続ける中で、本当の課題を少しずつ定義していった記録です。

最初は「広告主が見つからないのだ」と思っていた

正直、その仮説にはかなり自信がありました。パブリッシャーが広告で収益を上げられていないなら、理由は広告主を見つけられていないからだろう。そう考えて、私たちは数か月のあいだ、需要の獲得経路や販路、営業について考え続けていました。
でも、私たちが解こうとしていたのは、間違った課題でした。
実際に話を聞いてみると、むしろ広告主のほうから先に連絡してくるケースが少なくありませんでした。あるケアサービスのパブリッシャーは、問い合わせは安定して入ってくると言っていました。問題はその次でした。届いた問い合わせをキャンペーンに変える手段がなかったのです。
1件の広告キャンペーンをきちんと運用するには、想像以上に多くのものが必要です。広告を配信するアドサーバー、販売できる在庫、配信状況を確認する計測、成果を見せるレポート。この一式がなければ、問い合わせにきちんと答えることはできません。だから返信がそこで止まっていたのです。

「じゃあ、作ればいい?」

私たちも同じことを考えました。けれど、作ること自体が最初の壁でした。
多くのプロダクトチームにとって、広告は馴染みのない領域です。ビジネス側の誰かが早い段階から入り、広告が実際にどう売られ、予約され、配信され、レポートされるのかを説明する必要があります。あるパブリッシャーでは、その認識合わせだけで数人が数週間を要しました。
しかも費用も大きい。複数の会話で聞いたのは、自社で作るなら1年がかりのプロジェクトになり、保守が始まる前の段階で6桁ドル規模のコストがかかるという話でした。外注しても完全には解決しません。初期費用は依然として高く、市場が変わるたびに同じ問いが残ります。「これは誰が保守するのか?」

作っても、それで終わりではない

作り切ったチームでさえ、本当の仕事はその後から始まりました。
広告主への見積もり、キャンペーンの準備、契約、クリエイティブの回収とアップロード、配信中の差し替え、終了後のやり取り。あるチームは、1つのキャンペーンで60〜100通のメールが往復したと言っていました。
その間にクリエイティブのバージョンがずれ、スケジュールが遅れ、小さなミスひとつが広告主との信頼問題に変わることもあります。ある高トラフィックのサービスでは、実質的に一人が広告運用を担い、すべてのクリエイティブを手作業で管理していました。別のチームはこう言っていました。「ツールを増やすほど、運用は複雑になった」と。
見続けるほど、はっきりしてきました。広告を売るというのは、広告枠を売ることではありません。システム、運用、営業を同時に回すことなのです。
それでも、採算は簡単には合いませんでした。直接取引には運用の時間がかかり、ときには営業の時間も必要で、絶えず調整が発生します。一方で、売上は不規則に入ってくる。だから多くのチームは後回しにしていました。需要がなかったからではなく、その需要を受け止める準備ができていなかったからです。

だから、みな同じ答えにたどり着く

こうした現実を前にすると、ほとんどのパブリッシャーは同じ結論に至ります。「とりあえずネットワーク広告、AdMobやAdSenseをつなごう」。コードを1行入れれば、すぐに動き出すからです。
けれど、その手軽さには代償があります。私たちが会った多くのパブリッシャーにとって、ネットワーク広告は低いCPM、価格や掲載位置に対する限られたコントロール、浅いレポート、そして広告がユーザー体験に与える影響をほとんど調整できないことを意味していました。
本当は、プレミアムな直接取引を売りたい。でも、それを受け止めるシステムがない。だから低単価と妥協したUXに留まるしかない。私たちが会った多くのチームは、それを望んでいたのではなく、ほかに方法がなかったからそこにいました。

だから、私たちが定義した課題

一歩引いて見ると、本当の課題が見えてきました。
どのサービスも、同じものを作り直していました。広告商品の管理画面、予約フロー、レポート、精算プロセス。業種も規模も違うのに、根本にある課題は同じでした。みなが同じ車輪を、少しずつ違う形で作り直し、その代償を高く払っていたのです。
そこで私たちは問いを反転させました。毎回その車輪を作り直すのではなく、そのレイヤーを一度だけ標準化し、誰もが使えるようにしたらどうか?
振り返れば、答えは当たり前に見えます。でも当時はそうではありませんでした。何か月ものあいだ、私たちは課題は需要だと思っていました。実際には、需要はすでにそこにありました。本当の課題は、誰かが「広告を出したい」と言った後に起こる、すべてのことだったのです。
その気づきが、Ad Controlの出発点になりました。需要が現れた後に、パブリッシャーが本当に必要としていたシステムです。

次回

私たちがこの課題を実際にどう解き始めたのか。まず何に集中し、最初のバージョンはどんな姿で、そして「お、これはいけるかもしれない」と感じた最初の瞬間はいつだったのか。次のノートで書いていきます。