コミュニティの皆様へ
Uweと申します。このコミュニティへの投稿は初めてです。ドイツを拠点とする広告ネットワークの広告テクノロジー部門で開発者として働いています。最近、Discourseを使用しているパブリッシャーと協力しようとした際に、以下の問題に直面しました。
Ad Pluginを使用すると、以下のネットワーク/AdServer経由で広告を配信できます。
Google AdSense 565
DoubleClick for Publishers (DFP) (Google Ad Manager 145としても知られる)、カスタムターゲティングを含む
Google Double Click for Publishers 89
Amazon Affiliates 137 - バナーおよび商品リンク広告
Carbon Ads 140
問題点：選択肢が、収益化の可能性を全くカバーしていません。これはプラグインへの批判ではなく、Discourseを使用したウェブサイトの収益化に関する議論を開始し、Mediavine（米国市場）やSymplr（ドイツ市場）のような広告ネットワークからのサードパーティスクリプトを使用することがなぜ理にかなっているのかを説明したいと思います。
なぜこれが重要なのか？：
広告ネットワークは、さまざまなSSP（サプライサイドプラットフォーム）に接続されています。これらは、Googleと並んでオークションのためにリクエストされ、入札を行うことができます。これにより競争と広告プレッシャーがGoogleにかかり、最終的にはGoogle AdSenseまたはGoogle AdManagerのみを使用する場合よりも高いTKP（Thousand-Contact-Price）と収益につながります。
パブリッシャーにとっての利点：
競争とGoogleへの広告プレッシャーの増加による収益の増加。
技術的なハードル：
シングルページアプリケーションの収益化には、追加の技術的労力が必要です。
Ad Pluginでは、すべてのマーケター/広告テクノロジーパートナーのカスタムロジックを簡単に実装することはできません。
可能な解決策：
1つの可能な解決策は、Discourse内またはAd Plugin内に、ページロードまたはルート変更ごとにサードパーティスクリプトをリロードする方法を作成することかもしれません。これにより、すべての広告ネットワークが収益化の機会を得ることができ、収益化に焦点を当てたDiscourseユーザーにとってより有利になります。
そのような機能はすでに利用可能ですか？
広告ネットワークは、カスタムスクリプトを実行する必要があるのはなぜですか？：
これらはすべて基本的に同じテクノロジー（ヘッダービディングとしても知られる）で動作しますが、ターゲットオーディエンス、広告リフレッシュ、広告の遅延読み込み、特別なフォーマットの実装、ユーザーIDソリューションの統合などの追加ロジックを実装しています。そのため、すべてに適合するソリューションを提供することは非常に困難です。
広告テクノロジーパートナーの使用によるDiscourseユーザーへの利点：
パブリッシャーはコンテンツ作成に集中でき、AdTechパートナーが最適化された広告配信のための技術実装を処理します。
このトピックに関する皆様のご意見やご提案をお待ちしております！
「いいね！」 2
pfaffman
(Jay Pfaffman)
2
fork して ad プラグイン を作成し、pr を送信するか、それをモデルとして独自の ad network 用のプラグインを作成することで、すべて実現可能です（後者の方がより多くの制御が可能になりますが、対象はセルフホストされたサイトや任意のプラグインをインストールできるサイトに限定されます）。
Marketplace に投稿していただくか、まずはこちらのようなさまざまなプラグイントピックを確認していただけます。Developing Discourse Plugins - Part 2 - Connect to a plugin outlet。
「いいね！」 1
piffy
3
広告プラグインが積極的に開発されている可能性があることに言及する価値があるかもしれません
収益を上げたい誰かが、特定のプロバイダーのサポートを手伝ってくれる開発者を見つけるために、Marketplace に広告を掲載する必要があります。
私はしばらくの間、クライアントのために広告プラグイン拡張機能を維持してきました。
@pfaffman
迅速なご対応ありがとうございます。この点についていくつか強調したいことがあります。
開発者のリソース、時間、および費用:
私たちのロジックをDiscourseのプラグインに変換するには、間違いなく開発者のリソース、時間、および金銭的な投資が必要です。このプロセスには、Discourseプラットフォームの理解、ロジックをその構造に適合させること、および実装が含まれ、これらすべてにかなりの労力が伴います。
保守およびアップデート:
独自のプラグインを持つということは、長期的な保守および定期的なアップデートに責任を持つことを意味します。プラグインがスムーズに機能し、将来のDiscourseバージョンとの互換性を維持し、潜在的なセキュリティ脆弱性に対処するには、追加のリソースと注意が必要です。これはリソースを拘束します。
これらの要因を考慮すると、最初のステップでは、よりシンプルなソリューションを探す方が理にかなっているように思われます。3rdパーティスクリプトをページ変更/ルート変更ごとにリロードする既存のプラグインはありますか？
@merefield
広告ネットワークを統合したいパブリッシャーがマーケットプレイスのスレッドで投稿を開き、統合のサポートを求めている、ということでよろしいでしょうか？
「いいね！」 1
私の場合は、広告パブリッシャーの直接のサポートなしに、エンドユーザーのサイト管理者が作業を後援しました。
しかし、すべてを考慮すると、広告パブリッシャーが開発者コミュニティに参加し、広告が直接サポートされるように作業を後援してくれると素晴らしいでしょう。
ちなみに、私の作業はオープンソースでした（クライアントとの合意による）。そのため、他の人もその作業から恩恵を受けることができます（残念ながら無料サポートは提供できませんが）。
そのリポジトリに興味がある場合は、基本的な詳細をDMでお送りできます。
「いいね！」 2
ご意見ありがとうございます。特に、広告が表示されるまで不明な場合が多い様々な広告主が広告を配信するプログラマティック広告の性質を考えると、サイトのパブリッシャー/管理者が関連費用を負担することは理にかなっています。パブリッシャーが開発者コミュニティと連携し、直接サポートを確保するために作業をスポンサーすることは有益であることに同意しますが、最終的な決定はサイトのパブリッシャー/管理者次第です。
あなたの作品がオープンソースであったため、他の人が恩恵を受けることができたことに感謝します。リポジトリの基本的な詳細をDMで教えていただければ、さらに詳しく知りたいと思います。
念のため確認ですが、マーケットプレイスのリクエストを通じて開発者コミュニティの助け/作業なしに広告ネットワークを統合する他の方法はありませんか？
一般的に、パブリッシャーがカスタムスクリプトの実行を必要とする場合、通常は開発者が連携させる必要があります。
基本的な問題は、通常、問題の要素がDOMにレンダリングされた後にのみコードを「実行」できることであり、これにはコードでのスケジューリングが必要です。これは、シーケンスIDのような特別な要件によって悪化する可能性があります。
この理由は、DiscourseがWebアプリケーションとして構築されており、JavaScriptフレームワークを使用しているため、少し複雑になるためです。
「いいね！」 1
理解できます。すでに最初の投稿でウェブアプリケーションの問題に言及しました。
ご協力ありがとうございます。パブリッシャーと話し合います。サードパーティのスクリプトに開発者からの個別のサポートが必要な場合、この機能リクエストはクローズできるでしょう。
「いいね！」 1