Monetising an Owned Web Push Base Without Burning It

In every push base we have inherited, subscribers who granted permission more than 120 days ago made up over half the list and under a fifth of the clicks. Selling the whole base at one price is what caps the yield. We split it by permission age, capture surface and click history, price the parts separately, and stop sending to a segment when its opt-out rate per send passes 0.8 percent. The list gets smaller in month one. The revenue does not. Reading the base: We work from the subscription table, not the dashboard. The endpoint host tells us the real browser mix, and the first correction is usually arithmetic rather than strategic: push services return 410 Gone for a subscription that no longer exists, and a base that never pruned on 410 carries a large share of endpoints that have been dead for months. A base of 900,000 that is actually 600,000 deliverable has been sold to advertisers at the wrong CPM, and both sides eventually notice. Then the cohorts: grant date, the page and prompt pattern that captured it, browser, hour-of-day click behaviour, and consecutive ignored sends. A subscriber with fourteen ignored sends is not a subscriber, and continuing to send to them is what pushes a site into Chrome's Abusive Notifications report in Search Console. After that the permission prompt is suppressed for new visitors and the base stops replacing itself. Pricing the inventory: Segments that click get sold direct at a floor CPC, to advertisers who can be named in the contract. The tail goes to network fill. We hold the floor rather than fill the slot; a send at half the floor costs a subscriber who would have been worth ten more sends. Frequency is set per segment, not per base, and the daily cap is a decision we make and defend rather than a slider handed to ad ops. Japan: A Japanese-language base competes with LINE for the same slice of the same lock screen, and tolerance is lower than a US base at identical frequency. We run Japanese bases at a lower cap and a higher floor, and we write send windows around commute hours rather than the office day. Safari has supported web push only since 16.4 and only for sites added to the Home Screen, which is why an iPhone-heavy Japanese audience produces a base that skews Android and desktop far harder than the site's own traffic does. What we refuse: No prompt on page load. No incentivised or purchased subscribers; a bought endpoint clicks once and poisons the cohort maths for a quarter. No pharmaceutical, medical device or supplement claims in push copy for the Japanese market, because the Act on Pharmaceuticals and Medical Devices reaches the creative and a 40-character title has no room for the qualifying language the law requires. We do not sell placements to advertisers who will not disclose the landing domain. Who this is not for: Bases under roughly 200,000 deliverable subscribers, where the segmentation work costs more than the lift returns. Publishers whose board tracks subscriber count as the headline number, because the first month makes that number fall. Anyone who wants the base monetised without changing how it is grown. What arrives: The cohort file with a keep, sell or retire decision on each segment and the reasoning attached. A written send policy with caps, floors and quiet hours. The pruning job running against 410 and 404 responses. A monthly yield read that separates price movement from list movement, so you can tell which one moved.