[Founder Notes #2] 広告プラットフォームの構築に1年もかける必要はない。

前回のノートで、私たちは少し居心地の悪い事実にたどり着きました。需要はあった。仕組みがなかった。広告主はすでに来ていて、難しいのは、誰かが「広告を出したい」と言った後に起こる、すべてのことだったのです。

そこで次の問いはシンプルでした。まず何を作るのか。

彼らに必要だったのは、もう一つの広告ネットワークではなかった

最初からはっきり見えていたわけではありません。しばらくのあいだ、私たちは何度も違う形の答えに手を伸ばしていました。広告主を連れてくるマーケットプレイスなのか。広告在庫を束ねて再販売する広告ネットワークなのか。

でも、そのどれもが、結局は私たちを取引の真ん中に戻してしまうものでした。

パブリッシャーに本当に欠けていたものは、もっと単純で、もっと地味なものでした。届いた広告需要を受け止め、キャンペーンに変えるための、自分たちの場所。つまり、自分たち自身の販売レイヤーです。

私たちの創業メンバーは長年アプリを作ってきたので、この痛みを身をもって知っていました。広告主が直接連絡してくると、その対応のために長いメールのやり取りが続き、その間、開発チームは本来のプロダクト開発を止めることになります。しかも購入体験がぎこちないため、広告主が再び戻ってくることはほとんどありませんでした。

大手の広告プラットフォームは、自分たちの側の課題をとうに解決していました。広告主は、洗練されたセルフサーブの仕組みに慣れていたのです。けれど小規模なパブリッシャーは、自分たちの広告在庫のためのそのレイヤーを、一度も手にしたことがありませんでした。そこに隙間がありました。

必要だったのは、より賢いターゲティングマシンではありません。すでに持っている需要を受け止め、価格を決め、運用できる場所だったのです。

ROIが合わなかった — — だから「試すコスト」を変えた

この問いを、チームのAngieに持っていきました。彼女はGoogleの広告組織で、市場の反対側を間近で見てきた人だったからです。私は、彼女がプロダクトの範囲を一緒に詰めてくれると思っていました。けれど彼女は、むしろ前提そのものに疑問を投げかけました。

ほとんどの小規模な開発者にとって、これを自社で作っても採算はまず合わない。本体のプロダクトだけでも手一杯なのに、広告プラットフォームはそれ以上に複雑だからです。

その言葉を反芻するほど、本当の課題が見えてきました。パブリッシャーが広告を売れないのではありません。広告を売るためのインフラ、つまりアドサーバー、予約フロー、ターゲティング、レポート、精算が、広告で得られる収益よりも高くついていたのです。インフラが、機会そのものより大きくなっていました。

だから打ち手は、パブリッシャー一社ずつを説得してその費用を払わせることではありませんでした。そのレイヤーを一度だけ標準化し、誰もがスイッチを入れるだけで使えるようにすることでした。自社で作れば1年と6桁ドルの予算がかかるのなら、中核となるセットアップは、数か月ではなく数分に近く感じられるべきでした。

できるだけ地味なものから始めた

対応したいフォーマットのリストは長いものでした。動画、ネイティブ、リワード、スポンサーシップパッケージ。けれど、新しいフォーマットを一つ加えるたびに、最初のバージョンは信頼しづらくなっていきました。

そこで私たちは、できるだけ地味な単位から始めました。バナー一つ。バナーを一つ確実に配信できないなら、それを広告プラットフォームと呼ぶ資格はないと考えました。

そして作り込むほど、プロダクトは地味になっていきました。パブリッシャーが最も必要としていたのは、もう一つの美しいダッシュボードではありませんでした。誰も作り直したくない、運用の土台です。予算を均等に消化するペーシング、フリークエンシーキャップ、不正クリックの防止、クリエイティブの取り扱い、レポート、精算。

このどれか一つが崩れても、広告主はシステムを責めません。パブリッシャーを責めます。だから私たちは、まず目立たない部分にこだわり抜きました。

パブリッシャーが実際に手にするもの

その土台が固まって初めて、残りが形になりました。ここは具体的に語る価値があります。「広告プラットフォーム」という言葉は、ほとんど何でも指せてしまうからです。

パブリッシャーは二つのものを手にします。どちらも自社ブランドで。ひとつは広告運用を管理するコンソール。もうひとつは、広告主が商品を見て、自分でキャンペーンを予約できるプラットフォームです。

価格は自分たちで決めます。インプレッション単位、クリック単位、あるいは期間固定のパッケージで。自分たちだけが提供できる1stパーティデータのターゲティングを重ね、配信のペーシングや残りの運用はシステムが処理します。

ひと言で言えば、広告の問い合わせを、もう一通のメールではなく、予約済みのキャンペーンに変える仕組みです。

顧客が、これを本物にした

うまくいくかもしれないという最初の兆しは、私たちが説得に時間を使うつもりだった営業ミーティングで訪れました。けれど返ってきたのは、「作ってくれてありがとう」でした。

まだ粗削りなベータだったにもかかわらず、いくつものチームが「これを待っていた」と言って導入し始めました。そして、彼らがこのプロダクトを本物にしました。日々使う道具になった瞬間、フィードバックが押し寄せ、私たちはそれに追いつこうと全力で走りました。

今あるプロダクトは、私たちと同じくらい、初期の顧客たちによって形づくられたものです。

私たちが作らないと決めたもの

もっと大きくしたい誘惑はありました。もっと多くのフォーマット、もっと多くの自動化、もっと多くの設定。フォーマットを加えるたびに、プロダクトがより完成に近づくように感じました。けれど実際には、より信頼しづらくなり、私たちが手助けしようとしていたまさにそのチームが、使いづらく感じるものになっていきました。

最も分かりやすい例が、大手プラットフォームが動かしているAI自動ターゲティングでした。問うべきは、それが印象的に聞こえるかどうかではありません。そもそも広告主がなぜ小規模なパブリッシャーを訪れるのか、その理由と噛み合っているかどうかでした。

広告主は、巨大な広告在庫をまたいだ自動マッチングを求めて来るのではありません。そのパブリッシャーだけが持つ1stパーティデータで、特定の文脈の中にいる、特定のオーディエンスに届けるために来るのです。だから私たちは、大手プラットフォームのプレイブックを追いませんでした。代わりに、その種のターゲティングを、鋭く、かつ柔軟に作り込むことに集中しました。

私たちが守った原則

守り続けた原則はシンプルでした。

パブリッシャーは承認するだけ。あとはシステムが処理する。

それがAd Controlです。パブリッシャー自身のダイレクト広告の裏側で動く運用レイヤー。一度きちんと作り、標準として共有することで、誰も作り直さなくて済むようにしたものです。

次回

実際のパブリッシャーがこれをオンにしたとき、何が起きたのか。そして、これまで取りこぼしていた需要が、ついにどこに着地したのか。

─────────────────

✨ AdControlについて、もっと知りたい方へ

🔗 Adrop 公式サイト: https://adrop.io/ja 🔗 LinkedIn: https://www.linkedin.com/company/adrop-openrhapsody 🔗 X (Twitter): https://x.com/Official_Adrop

📚 リソース ・ AdControl ヘルプセンター: [リンク]\ ・ お問い合わせ: contact@adrop.io