푸시 알림 발송 빈도: 뉴스 사이트는 얼마나 자주 보내야 할까?

정직한 답은 "상황에 따라 다르다"이고, 쓸모 있는 부분은 무엇에 따라 다른가입니다.

뉴스 사이트가 푸시 알림을 얼마나 자주 보내야 하는지에 대해 공개할 수 있는 숫자는 없습니다. "퍼블리셔는 하루 2~5회"라고 말하는 사람은 표본을 밝히지 않은 공급사 블로그를 되풀이하고 있거나, 여러분의 사이트와 공통점이 전혀 없는 사이트들을 평균 낸 것입니다. 실제로 존재하고 오늘 바로 활용할 수 있는 것은 브라우저가 강제하는 상한, 독자가 쥐고 있는 예산, 그리고 개별 발송이 실제로 지닌 가치가 정하는 하한입니다.

헷갈리기 쉬운 두 가지 빈도

푸시 발송 빈도를 둘러싼 쓸모없는 논쟁은 거의 다 이 둘을 섞는 데서 나옵니다.

하루에 20번 보내지만 보통의 독자는 두 번 받는 뉴스룸과, 네 번 보내고 모든 독자가 네 번 다 받는 뉴스룸은 완전히 다른 제품입니다. 더 공격적인 것은 두 번째인데, 대시보드의 발송 수는 그 반대를 말합니다.

그러니 "얼마나 자주 보내야 하나"라는 질문은 사실 두 개의 질문이고, 피로와 관련된 답이 있는 것은 두 번째뿐입니다. 구독자별 숫자를 먼저 정하세요. 그러면 사이트 빈도는 오디언스 신뢰의 문제가 아니라 편집과 타기팅의 문제가 됩니다.

Chrome이 실제로 강제하는 상한

이 부분은 의견이 아니고 예측도 아닙니다. 2026년 1월부터 시행되고 있습니다.

Chrome은 사이트 참여가 낮으면서 알림을 많이 보내는 사이트를 대상으로 Push API 속도 제한을 배포하기 시작했습니다. 방해가 된다고 판정된 사이트도 분당 1,000건 아래로는 제한되지 않으며, 초과 요청은 HTTP 429를 받습니다. Chrome이 밝힌 일일 판정 요소는 사이트 체류 시간 대비 푸시 메시지 수, 사이트 체류 시간 대비 권한 요청 수, 그리고 사이트 참여 점수와 포그라운드 시간(분)으로 측정한 참여도입니다. 제한 기간은 1일, 그다음 7일, 그다음 14일로 늘어나고, 방해가 아닌 상태가 42일 연속되면 초기화됩니다. Push API에만 적용되고 Notifications API에는 적용되지 않습니다. Chrome은 거의 모든 웹사이트가 영향을 받지 않을 것이라고 밝힙니다.

이와 별개로 2025년 10월부터 Chrome은 참여가 매우 낮고 알림 발송량이 높을 때, 사용자가 최근에 상호작용하지 않은 사이트의 알림 권한을 자동으로 제거합니다. Chrome은 사용자에게 알리고, 사용자는 Safety Check나 사이트에서 권한을 다시 부여하거나 자동 회수를 끌 수 있습니다. 설치된 웹 앱은 영향을 받지 않습니다. 데스크톱과 Android에 적용됩니다.

여기서 두 가지가 나오고, 둘 다 숫자를 생각하는 방식을 바꿉니다.

첫째, 강제되는 기준은 횟수가 아니라 비율입니다. 사이트 체류 시간 대비 푸시 메시지 수. 사이트 체류 시간 대비 권한 요청 수. 독자가 머무르고 다시 오는 사이트는 발송 수가 같고 참여가 없는 사이트보다 여유가 더 있습니다. 즉 "하루에 몇 번"은 잘못된 단위이고, "얻어 낸 주의력 한 단위당 몇 번"이 올바른 단위입니다.

둘째, 속도 제한은 사이트 단위로 적용되지만 자동 회수는 사람 단위로 일어납니다. 전체로는 괜찮은 빈도라도, 참여가 가장 적은 3분의 1에게서는 조용히 권한을 벗겨 내고 있을 수 있습니다.

Chrome의 기준치에 비해 내가 어디쯤인지는 계산할 수 없습니다. 내부 점수 방식은 공개되지 않았고, 그것을 모델링하는 것은 추측일 뿐입니다. 자체 상한을 그들의 상한보다 한참 안쪽에 두고, 경계를 찾으려는 시도는 그만두세요.

이 페이지에 업종별 벤치마크 표가 없는 이유

업종마다 한 줄씩, 그럴듯한 숫자를 넣은 표를 여기 둘 수도 있었습니다. 검색 순위는 잘 나왔을 것입니다. 그리고 지어낸 숫자였을 것입니다.

저희는 브라우저와 시장에 관한 사실을 1차 출처가 있는, 날짜가 붙은 클레임 레지스터에서만 공개합니다. "뉴스 사이트는 하루에 X개의 알림을 보낸다"에 대해 승인된 출처는 없습니다. 국가별 옵트인율과 발송 빈도를 공개하는 공급사 블로그는 분모를 밝히지 않고, 표본을 설명하지 않으며, 대부분 자기 고객 기반을 측정합니다. 기술 감지 스냅숏은 어떤 사이트가 푸시 플랫폼을 쓰는지는 알려 주지만, 그 사이트들이 얼마나 자주 보내는지는 알려 주지 않습니다.

그래서 이 페이지는 숫자 대신 틀을 드리고, 그 틀이 만들어 내는 결과는 여러분 자신의 것입니다. 저희가 공개하는 숫자에는 언제나 클레임 레지스터에서 가져온 방법과 출처가 함께 붙습니다.

나만의 숫자를 찾는 틀

1. 구독자별 상한에서 시작하세요

한 사람이 하루와 일주일에 받을 수 있는 최대치를 정하세요. 신중하게 고르고, 적어 두고, 다른 모든 것이 그 안에서 움직이는 제약으로 삼으세요. 뉴스룸이 반발한다면 그 숫자가 제 역할을 하고 있는 것입니다.

2. 횟수보다 가치 하한을 먼저 정하세요

어떤 발송은 빈도와 상관없이 나가지 말아야 합니다. 기사가 Nudge가 되기 전에 넘어야 할 기준을 정하세요. 콘텐츠 신뢰도에 대한 기준선이든, 기사 유형 규칙이든, 데스크가 받아들일 수 있는 무엇이든 괜찮습니다. 상한에 여유가 남아 있다고 해서 그것을 채우라는 뜻은 아닙니다.

3. 일상 발송과 긴급 발송을 명시적으로 나누세요

일상 발송은 상한 안에서 움직이고, 조용한 시간을 지키며, 휴면 구독자를 건너뜁니다. 긴급 발송은 이름이 붙고 기록되는 예외 처리를 통해 상한을 넘을 수 있습니다. 예외가 기록되지 않으면 한 달 안에 모든 것이 긴급해집니다. 저는 그런 일을 직접 지켜봤습니다.

4. 하루 발송 수가 아니라 발송당 품질을 기준으로 삼으세요

벽에 붙여 둘 만한 숫자는 몇 번 보냈느냐가 아니라, 발송 하나가 무엇을 쓰고 무엇을 돌려주느냐입니다.

쓸 만한 방식은 이렇습니다. 발송마다 전달 1,000건당 상호작용 수를 구하고, 거기서 전달 1,000건당 옵트아웃과 무효 엔드포인트 수를 빼세요. 그러면 약한 기사를 넓은 오디언스에게 보낼 때 떨어지는 발송당 순수치가 나옵니다. 바로 지표가 벌줘야 할 행동입니다. 이것은 업계 표준이 아니라 저희의 틀입니다. 경제성이 다르다면 가중치는 바꾸되, 빼기는 남겨 두세요. 비용 항목이 없는 지표는 언제나 더 보내자는 쪽을 편듭니다.

5. 한 번에 한 단계씩 바꾸고 기다리세요

구독자별 상한을 하나만 바꾸고, 2~4주 유지하면서 리스트 순변동을 지켜보세요. 새로 허용된 권한에서 구독 해지와 무효 엔드포인트를 뺀 값입니다. 변수 하나를, 리스트가 반응하는 것이 보일 만큼 오래. 나흘짜리 빈도 실험은 정책이 아니라 뉴스 사이클을 측정합니다.

퍼블리셔에게만 해당하는 부분

모든 기자는 자기 기사가 푸시되기를 원합니다. 이것은 뉴스룸의 결함이 아니라 뉴스룸이 제대로 일하고 있다는 뜻이고, 개별 요청은 하나하나 그 자체로 합리적입니다.

문제는 오디언스를 책임지는 사람이 하나하나는 합리적인 요청 더미를 상대로 논쟁해야 하고, 그 자리에 있는 숫자라고는 지난 발송의 클릭 수뿐이라는 점입니다. 클릭 수는 언제나 더 보내자고 말합니다. 표준 대시보드 어디에도 그 발송이 구독자 측면에서 무엇을 대가로 치렀는지는 나오지 않으니, 절제는 의견으로만 등장하고 집니다.

그래서 정책을 하나도 바꾸기 전이라도 발송별 장부를 두어야 합니다. 클릭, 옵트아웃, 무효 엔드포인트, 그리고 그 주의 리스트 순변동을 발송당 한 행에. 그러면 논쟁은 산수가 되고, 산수로는 이기기가 훨씬 쉽습니다.

한계와 브라우저 관련 주의점

• Chrome의 속도 제한은 Notifications API가 아니라 Push API에 적용되며, Chrome은 거의 모든 사이트가 영향을 받지 않는다고 밝힙니다. 이것으로 누군가를 겁줘서 숫자를 정하게 하지 마세요.
• Apple 플랫폼은 다릅니다. Declarative Web Push는 2025년 3월 31일 Safari 18.4와 함께 iOS와 iPadOS의 홈 화면 웹 앱을 대상으로 출시되었습니다. 빈도에 대한 허용 범위와 돌려받는 신호는 Chrome과 똑같지 않습니다.
• 브라우저 구성비에 따라 이 모든 것이 여러분에게 갖는 의미가 달라집니다. StatCounter는 2026년 7월 전 세계 브라우저 점유율을 Chrome 68.22%, Safari 16.47%로, 유럽은 Chrome 60.71%, Safari 18.67%로, 스웨덴은 Chrome 57.37%, Safari 24.75%로 보고했습니다. Chrome의 동작에 맞춘 빈도 정책은 시장마다 리스트의 서로 다른 비율을 덮습니다.
• 이 페이지의 어떤 숫자도 EngageNudge가 측정한 것이 아닙니다. 틀은 저희 것이고, 브라우저 관련 사실은 Chrome과 WebKit의 것이며, 점유율 수치는 StatCounter의 것입니다. 모두 위에 날짜를 적었습니다.

EngageNudge는 발송 빈도를 어떻게 다루는가

EngageNudge에서 빈도는 캠페인의 입력란이 아니라 발송이 통과해야 하는 정책입니다. 구독자별 일일·주간 상한, Nudge 간 최소 간격, 조용한 시간, 휴면 규칙, 가치가 낮은 발송을 걸러 내는 기준이 전달 전에 평가되고, 이를 통과하지 못한 Nudge는 이유가 기록된 채 건너뜁니다.

그 아래에는 홀드아웃이 있어서, "추가 발송이 정말 누군가를 다시 데려왔는가"라는 질문에 클릭 수가 아닌 답이 있습니다.