광고 관리 파트너를 통한 수익화

커뮤니티 여러분께,

안녕하세요, 우베(Uwe)입니다. 이 커뮤니티에 첫 글을 올립니다. 저는 독일 소재의 애드 네트워크에서 애드 테크놀로지 개발자로 근무하고 있습니다. 최근 Discourse를 사용하는 퍼블리셔와 협력하고자 할 때 다음과 같은 문제에 직면했습니다.

Ad 플러그인을 통해 다음 네트워크/애드 서버를 통해 광고를 전달할 수 있습니다:

Google AdSense 565

DoubleClick for Publishers (DFP) (또는 Google Ad Manager 145라고도 함), 커스텀 타겟팅 포함

Google Double Click for Publishers 89

Amazon Affiliates 137 - 배너 및 상품 링크 광고

Carbon Ads 140

문제점: 현재 제공되는 선택지는 수익화(Monetization)의 전체 잠재력을 훨씬 능가하지 못합니다. 이는 플러그인에 대한 비판의 의도가 아닙니다. 저는 Discourse를 활용한 웹사이트 수익화에 관한 논의를 시작하고, 왜 Mediavine(미국 시장)이나 Symplr(독일 시장)과 같은 애드 네트워크의 3자 스크립트를 사용하는 것이 합리적인지 설명하고자 합니다.

왜 이것이 중요한가요?:

애드 네트워크는 다양한 SSP(Supply Side Platform)와 연결되어 있습니다. 이들은 Google과 함께 경매에 참여하여 입찰을 제출할 수 있습니다. 이는 경쟁과 Google에 대한 광고 압력을 높여 궁극적으로 더 높은 TKP(Thousand-Contact-Price, 천 회 노출당 가격)와 Google AdSense 또는 Google AdManager만 사용하는 경우보다 더 많은 수익으로 이어집니다.

퍼블리셔의 이점:

Google에 대한 경쟁과 광고 압력 증가로 인한 더 높은 수익.

기술적 장벽:

단일 페이지 애플리케이션(SPA)의 수익화는 추가적인 기술적 노력이 필요합니다.

Ad 플러그인은 모든 마케터/애드 테크놀로지 파트너를 위한 커스텀 로직을 쉽게 구현할 수 없습니다.

가능한 해결책:

하나의 가능한 해결책은 Discourse 또는 애드 플러그인 내에서 페이지 로드 또는 라우트 변경 시 3자 스크립트를 다시 로드할 수 있는 방법을 만드는 것입니다. 이는 모든 광고 네트워크에게 수익화 기회를 제공하며, 수익화에 초점을 맞춘 Discourse 사용자에게 더 유리할 것입니다.

질문: 이러한 기능이 이미 존재합니까?

왜 광고 네트워크는 자체 스크립트를 실행해야 하는가?:

이들은 모두 근본적으로 동일한 기술(또는 헤더 비딩(header bidding)이라고도 함)을 기반으로 작동하지만, 대상 청중 타겟팅, 광고 새로고침, 광고의 지연 로드(lazy loading), 특수 형식 구현, 사용자 ID 솔루션 통합과 같은 추가 로직을 구현합니다. 따라서 모든 상황에 적용 가능한 원 사이즈 핏(one-fits-all) 솔루션을 제공하기가 매우 어렵습니다.

애드 테크놀로지 파트너를 통한 Discourse 사용자의 이점:

퍼블리셔는 콘텐츠 제작에 집중할 수 있으며, 최적화된 광고 전달을 위한 기술적 구현은 애드 테크 파트너가 처리합니다.

이 주제에 대한 여러분의 의견과 제안을 기대합니다!

2개의 좋아요

광고 플러그인을 포크한 후 PR을 제출하거나, 이를 모델로 삼아 자신의 광고 네트워크 전용 플러그인을 만들어 보는 것도 충분히 가능합니다. (이 방법은 더 많은 제어권을 부여하지만, 대상 독자층이 셀프 호스팅 사이트나 임의의 플러그인을 설치할 수 있는 기타 사이트로 제한됩니다.)

Marketplace 채널에 게시물을 올리거나, 이 첫 번째 글과 같은 다양한 플러그인 관련 주제를 참고해 보세요: Developing Discourse Plugins - Part 2 - Connect to a plugin outlet.

1개의 좋아요

광고 플러그인이 적극적으로 개발되고 있는 것 같다는 점도 언급할 가치가 있을 것 같습니다.

수익을 올리는 데 이해관계가 있는 사람이 #marketplace에 광고를 올려야 개발자를 고용해 특정 제공업체를 지원할 수 있습니다.

저는 한동안 클라이언트를 위해 광고 플러그인 확장을 유지 관리해 왔습니다.

@pfaffman
빠른 답변 감사합니다. 이 문제에 대해 몇 가지 점을 강조하고 싶습니다:

개발자 리소스, 시간 및 비용: 우리의 로직을 Discourse 플러그인으로 변환하는 것은 분명히 개발자 리소스, 시간 및 재정적 투자가 필요합니다. 이 과정에는 Discourse 플랫폼을 이해하고, 우리의 로직을 해당 구조에 맞게 조정하며, 구현하는 작업이 포함되는데, 모두 상당한 노력이 필요합니다.

유지보수 및 업데이트: 자체 플러그인을 보유한다는 것은 장기적인 유지보수와 정기적인 업데이트에 대한 책임이 우리에게 있음을 의미합니다. 플러그인이 원활하게 작동하고, 향후 Discourse 버전과 호환성을 유지하며, 잠재적인 보안 취약점을 해결하기 위해서는 추가적인 리소스와 주의를 기울여야 합니다. 이는 또한 리소스를 묶어 두는 결과를 낳습니다.

이러한 요인들을 고려할 때, 초기 단계에서는 더 간단한 솔루션을 찾는 것이 더 합리적이라고 생각합니다. 아마도 매 페이지 변경/라우트 변경 시 3자 스크립트를 다시 로드하는 기존 플러그인이 있을까요?

@merefield
광고 네트워크를 통합하려는 게시자가 마켓플레이스 스레드에서 게시물을 열고 통합에 대한 지원을 요청한다는 것을 제가 올바르게 이해한 것인가요?

1개의 좋아요

제 경우, 최종 사용자 사이트 관리자가 광고 발행자의 직접적인 지원 없이 작업을 후원했습니다.

그러나 모든 것을 고려할 때, 광고 발행자가 개발자 커뮤니티에 참여하여 광고가 직접 지원되도록 작업을 후원해 준다면 정말 훌륭할 것입니다.

참고로 제 작업은 오픈소스였습니다(클라이언트와 합의에 따라), 따라서 다른 사람들도 그 작업의 혜택을 볼 수 있습니다(다만, 불행히도 무료 지원을 제공할 수는 없습니다).

해당 저장소에 관심이 있으시다면, DM으로 기본적인 정보를 보내드리겠습니다.

2개의 좋아요

관점을 공유해 주셔서 감사합니다. 실제로, 프로그램matic 광고의 특성상 광고가 표시되기 전까지는 어떤 광고주가 광고를 전달하는지 알 수 없는 경우가 많으므로, 사이트의 발행자/관리자가 관련 비용을 부담하는 것이 타당하다고 생각합니다. 발행자가 개발자 커뮤니티와 소통하고, 직접적인 지원을 보장하기 위해 작업을 스폰서링하는 것이 유익하다고 동의하지만, 최종 결정은 사이트의 발행자/관리자에게 있습니다.

귀하의 작업이 오픈소스였다는 점을 감사하게 생각합니다. 다른 사람들이 그 혜택을 누릴 수 있게 해 주었기 때문입니다. 리포지토리에 대한 기본 정보를 DM으로 보내 주시면, 더 자세히 알고 싶습니다.

안전한 측면에서 말씀드리자면, 마켓플레이스 요청을 통한 개발자 커뮤니티의 도움/작업 없이 광고 네트워크를 통합할 다른 방법이 없는 것인가요?

일반적으로 게시자가 맞춤형 스크립트 실행을 요구하는 경우, 모든 것을 연결하기 위해 개발자의 개입이 필요합니다.

기본적인 문제는 관련 요소가 DOM에 렌더링된 후에만 코드가 "실행"될 수 있다는 점이며, 이를 위해서는 코드 내에서 일정 관리가 필요합니다. 시퀀스 ID와 같은 특별한 요구 사항이 있으면 상황이 더욱 복잡해질 수 있습니다.

이유는 Discourse가 웹 애플리케이션으로 구축되어 자바스크립트 프레임워크를 사용하므로, 처리 과정이 다소 복잡하기 때문입니다.

1개의 좋아요

이해합니다. 첫 번째 게시물에서 웹 애플리케이션 문제를 이미 언급했었습니다.

도움 주셔서 감사합니다. 게시자와 이야기를 나눠 보겠습니다. 만약 서드파티 스크립트가 개발자의 개별적인 지원을 필요로 한다면, 이 기능 요청은 닫아도 될 것 같습니다.

1개의 좋아요