---
name: newsletter-monetization-strategy
description: Use when the user asks how to monetize a newsletter, whether to use sponsors, paid subscriptions, affiliates, products, services, events, directories, lead generation, community, or when to start monetizing without damaging reader trust.
---

# Newsletter Monetization Strategy

Choose and validate a newsletter monetization model that fits the category, audience, trust level, and operator capacity.

## Core Rule

Use connected analytics, sponsor history, paid-member data, product/service data, source attribution, and issue history when available. Do not invent revenue, conversion rates, audience willingness to pay, sponsor demand, or customer intent.

## Inputs

- Newsletter category, audience, cadence, size, engagement, and source mix
- Current revenue, costs, paid conversion, sponsor activity, affiliates, products, services, or lead-gen offers
- Operator goal: revenue, sustainability, sponsor readiness, paid tier, owned product, service funnel, asset value
- Trust constraints, excluded categories, compliance concerns, or editorial boundaries
- Available assets: audience proof, community, website traffic, issue archive, product/service offer, sponsor inventory

## Workflow

1. Diagnose the current monetization stage: pre-revenue, validation, repeatable, scaling, or asset optimization.
2. Identify the audience's likely monetizable intent from evidence, not assumptions.
3. Compare viable models: sponsors, paid subscriptions, affiliates, products, services, events, directories, lead gen, donations, or asset sale.
4. Score models by audience fit, trust risk, setup effort, time to cash, scalability, and data needed.
5. Recommend one primary model and one backup model.
6. Define the smallest 30-day validation test.
7. Save or hand off monetization assumptions, tests, and tracking notes for the connected workspace.

## Output Format

When a reusable artifact is useful, follow `templates/monetization-decision-tree.md`.

Include:

- Monetization diagnosis
- Model comparison table
- Recommended first model and backup model
- Trust and operational risks
- 30-day validation plan
- Tracking requirements
- Connected-workspace handoff notes

Model comparison table columns:

| Model | Fit | Why it could work | Risks | Data needed | First test |
| --- | --- | --- | --- | --- | --- |

## Guardrails

- Do not recommend scaling paid acquisition before retention or monetization is checked.
- Do not push paid subscriptions when the value is mainly sponsor, lead-gen, or service-driven.
- Flag high-trust categories like health, finance, politics, and local civic coverage before recommending ads or affiliates.
- Keep category-specific compliance and reader trust risks visible.
- Do not launch paid offers, publish sponsor inventory, or change pricing without explicit approval.