beehiiv 推荐计划不是「放一个链接，等读者帮你拉人」。奖励会改变读者行为，也可能把只想拿资料包的邮箱带进列表。先把奖励、展示位和监控表定死，再上线。
上线前先盯哪 6 个字段？
进入 beehiiv 的 Grow / Referral Program 后，先别急着改奖励。把 rewards、referral URL、pending referrals、Manage Referrals、referral card、自定义 referral section 这几项逐个确认。
| 字段 | 你要看什么 | 红灯信号 |
|---|---|---|
| referral URL | 每个读者是否有可分享链接 | 链接藏在邮件深处，几乎没人点 |
| pending referrals | 被推荐订阅是否完成确认 | pending 也被计入发奖 |
| rewards | 奖励档位和门槛 | 奖励成本高于一个订阅的长期价值 |
| referral card | 默认推荐卡片是否显示清楚 | 读者看不懂推荐几人能拿什么 |
| custom section | 邮件固定展示位 | 每期位置变来变去，数据不可比 |
| unsubscribe rate | 推荐订阅的留存质量 | 推荐来源退订明显高于自然来源 |
beehiiv 的 Referral Program FAQ 提到，被推荐订阅者可能先显示为 pending，直到完成确认。pending 只能当线索，不能当有效增长，更不能当发奖凭证。
奖励怎么设才不会被薅？
冷启动只设 2 到 3 档。第一档要容易完成，用来证明读者愿不愿意分享；第二档给重度读者一点成就感；第三档留给真正愿意长期传播的人。
优先选低边际成本奖励：模板、资料包、闭门问答、社群活动名额。这类奖励的好处是兑现快、库存压力小，也不容易把动机完全扭成「拿奖品」。
| 奖励 | 成本 | 更适合放在哪一档 |
|---|---|---|
| 资料包 | 低 | 第一档 |
| 模板库 | 低 | 第一档或第二档 |
| 闭门问答 | 中 | 第二档 |
| 1 对 1 咨询 | 高 | 第三档 |
| 实物周边 | 高 | 有履约能力后再测 |
一开始别送高价实物。推荐计划如果吸引来的是为奖品而来的邮箱，短期新增会好看，后面的打开率和退订会把问题暴露出来。
推荐入口放在邮件哪里最稳？
入口要固定，最好连续 4 周放在同一个区域。可以用 referral card，也可以用自定义 referral section，但规则必须写清：推荐几人、奖励是什么、什么时候发放、pending 算不算。
文案别写成硬广告。更自然的说法是：「如果这封邮件帮你节省了调研时间，可以把你的 referral link 发给同事。」这句话给了读者转发理由，而不是只强调奖品。
不要今天放头部，明天放尾部，后天又取消。入口位置频繁变化时，你很难判断数据变化来自奖励、内容，还是单纯因为读者没看到入口。
Referral Program 和 Recommendations 怎么分账？
Referral Program 是读者带新读者；Recommendations 是刊物之间互推。beehiiv 有单独的 Recommendations 帮助文档，两类入口带来的订阅意图不同，必须分开记。
报表列可以拆成 organic、referral、recommendations、paid、manual import。每个来源都看 open、click、unsubscribe、reply 和 paid conversion。只看新增人数，会把低质量增长误当成胜利。
一个简单判断：referral 来源打开率接近自然订阅，且退订没有明显升高，才说明推荐计划在放大口碑。反过来，如果 recommendations 带来的读者更爱退订，就不要把问题归到 Referral Program。
4 周实验怎么排？
第 1 周只上线入口和奖励说明，不改内容频率。第 2 周在文末提醒一次。第 3 周重点看 pending 和异常邮箱。第 4 周把推荐订阅和自然订阅放到同一张表里比较。
| 周次 | 动作 | 这一周只判断一件事 |
|---|---|---|
| 1 | 上线 referral section | 读者是否看得到入口 |
| 2 | 文末提醒一次 | referral click 是否增加 |
| 3 | 抽查 pending 和邮箱质量 | 是否有刷奖或低质邮箱迹象 |
| 4 | 对比自然订阅 | 是否值得扩大入口和奖励 |
推荐订阅打开率低于自然订阅 50%，或退订明显更高，就先降奖励、提高门槛或暂停入口。不要用更大的奖品去掩盖质量问题。
多人协作发奖怎么管？
Newsletter 后台、推荐奖励和付费设置不要多人随意修改。远程团队常见问题不是「谁不会点按钮」，而是同一周里运营改奖励、编辑改邮件区块、负责人又手动发奖，最后没人说得清数据为什么变了。
如果团队分布在多个地区，可以把 beehiiv、支付、表格和素材库这些核心后台固定在同一套工作规范里；需要承载账号后台操作时，再用海外做号专用住宅 IP减少环境频繁变化带来的排查成本。
发奖要有表格记录：读者邮箱、推荐人数、奖励档位、确认状态、发奖日期、负责人。奖励兑现不能只存在聊天记录里，否则 4 周后复盘会变成翻消息记录。
社区讨论给的提醒是什么？
beehiiv 社区里，小刊物经常问推荐计划到底有没有用。更现实的答案是：内容已经有口碑时，推荐计划会放大它；内容还没有稳定打开率时，推荐计划只会把不稳定放大。
先让 4 到 8 期内容跑出自然订阅、回复和稳定打开，再上推荐计划。读者愿意转发，是因为内容真的有用，奖励只是提醒他们顺手分享。
相关阅读
FAQ
pending referrals 可以马上发奖吗？ 不要。beehiiv FAQ 提到被推荐订阅者可能先显示 pending；发奖前至少等确认完成，再抽查打开、点击、邮箱域名和短期退订。
奖励应该设几档？ 冷启动用 2 到 3 档就够。第一档给资料包或模板，第二档给活动名额，第三档再考虑咨询；实物奖励先别碰，履约和滥用成本都高。
Referral Program 和 Recommendations 一样吗？ 不一样。Referral Program 是读者把自己的 referral URL 发给别人；Recommendations 更像刊物之间互推。两类来源要分列统计，不能混算新增。
推荐增长多久复盘一次？ 上线后每周看一次，4 周后做第一轮决策。新增订阅只算入口效果，打开率、退订、付费转化和奖励成本才决定能不能继续放大。
小 Newsletter 适合做推荐计划吗？ 可以小范围试，但别把它当主增长引擎。先让 4 到 8 期内容跑出自然回复和稳定打开，再用奖励提醒读者转发。
来源与时间戳
最后核对：2026-05-22。依据 beehiiv Referral Program 设置、FAQ、Recommendations、自定义 referral section 文档，以及 beehiiv 社区关于 referral program 和 newsletter growth 的讨论。