一开始，我以为 popunder 的频率会呈现非常直接的权衡：减少广告可以保护用户体验，提高频率则可以增加收入，直到用户参与度开始下降。实际生产环境中的关系并没有这么整齐。
在一个线上 Web 应用中提高频率后，我原本预期参与度数据会出现明显的前后分界。实际情况却是，整体指标仍大致在原有的日常波动范围内变化。有些天更好，有些天更差，但我没有看到从新策略启用后开始的、明确且持续的下降。
最后我保留了这组配置：
首次延迟：45 秒
成功触发 popunder 后的最小冷却时间：4 分钟同时保留了一个频率窗口：同一个四分钟周期内，最多允许一次成功事件。
const policy = {
initialDelaySeconds: 45,
cooldownSeconds: 240,
windowSeconds: 240,
maxEventsPerWindow: 1,
};这只是说明思路的伪代码，刻意不依赖任何特定广告供应商、SDK、应用或部署方式。真正值得复用的不是具体实现，而是它表达的策略。
实际上存在两个频率决策
最开始，我把问题简化成一句话：两次 popunder 之间应该间隔多少分钟？后来我发现这个抽象并不准确。至少有两个不同决策：第一次广告机会之前要等待多久，以及后续广告机会之间至少要间隔多久。
这两个时间点并不等价。新访客还没有判断产品是否值得继续使用，而已经参与进来的用户基本已经做出了判断。因此，我认为第一次打断应该获得比后续打断更多的保护。
为什么我不再激进地变现最开始的几十秒
缩短首次延迟会让更多访客更快具备广告触发资格，从机械意义上说，这确实会创造更多潜在广告事件。但它忽略了变现发生的时机。
如果广告几乎在用户进入后立即出现，它就会成为用户第一次评估网站的一部分。如果用户先有一段不受打断的时间去理解和使用产品，同样的广告机制就会出现在不同的上下文中。
我原本使用更短的延迟，后来改为45 秒。这仍然算比较早，并不是一种保守配置。它只是把访问开始和第一次变现机会稍微分开。我逐渐把这 45 秒看成产品证明自身价值的时间，而不是损失掉的广告库存。
45 秒只是门槛，不是固定的广告时间
延迟结束只意味着用户开始 eligible，并不代表广告会在 00:45 自动出现。实际事件仍然需要一次符合条件的用户交互。用户可能在 00:45 获得资格，而直到 01:03 的下一次有效操作才触发第一个 popunder。
冷却时间也是如此。四分钟意味着上一次成功事件发生后的四分钟内，下一次事件不能重新具备资格，并不意味着每四分钟自动出现一条广告。因此，配置中的时间都是最小间隔，实际间隔可能更长。
重复间隔比首次延迟更重要
确定第一次延迟后，重复节奏成了更重要的变量。更长的 cooldown 可以降低广告压力，但也可能让很多高参与用户永远无法产生第二次机会。
我希望同时满足两个条件：持续使用应用的用户应该有现实机会产生下一次变现事件，同时每两次事件之间仍应保留足够长、真正不受打断的正常使用时间。
最终我保留了四分钟。首次延迟 45 秒时，理论上最早的 eligibility 时点大约是 00:45、04:45、08:45 和 12:45。由于仍然需要一次符合条件的交互，真实事件可能更晚发生。
为什么四分钟和单纯最大化展示量不同
缩短 cooldown 几乎一定会增加理论机会。如果唯一指标是每位用户的广告机会数，间隔越短显然越好。但产品只有在继续对用户有价值时，才有持续的广告价值。
额外变现
-
行为损害
=
净价值四分钟给了用户一段有意义的正常使用时间，在这段时间里新的 popunder 不可能发生。对我来说，这个 invariant 比“每四分钟一个”更重要。
一次变现事件之后，用户会获得几分钟下一次事件绝不可能发生的时间。
我原本预期参与度会明显下降
上线之前，我最主要的假设是：提高广告频率会在 analytics 中形成清晰的前后下降。如果真的发生，我就有充分理由降低策略强度。
结果却是，aggregate engagement 仍像以前一样波动。我没有看到新的更低 baseline，也没有看到提高频率后指标长期维持在更弱水平。原本以为足够大、应该能被明显看见的 failure mode，并没有清楚出现。
我真正能够声称什么
我不能说广告毫无影响，不能说用户完全不介意，也不能说 retention 完全没变，更不能说这组配置在任何场景下都是最优。一个 aggregate average 证明不了这些结论。
我的观察真正支持的最强表述要窄得多：
提高频率之后，我没有观察到超出此前正常波动范围的、明确而持续的整体参与度下降。
这种说法仍然允许更小的影响、不同用户群之间的差异，以及被单个平均值掩盖的行为变化。我测试的是这组配置是否仍然足够可接受，可以继续保留，而不是证明自己找到了全局最优值。
稳定的平均值可能掩盖完全不同的用户行为
一个几乎没有变化的整体平均值可能对应很多不同情况。几乎所有用户都可能保持原有行为；一部分用户可能更早离开，而另一部分停留更久；一个小群体可能受到负面影响，但规模不足以明显拉低平均值；或者真实的负面影响可能只是小于正常的日常波动。
因此，我把稳定的平均值当成有用的监控信号，而不是“影响为零”的证据。
Engagement 并不等于字面意义上的访问时长
我也没有把 analytics 中的 engagement metric 当作精确的平均 session 时长。Active engagement 取决于分析系统的定义，并不一定等同于浏览器标签页保持打开的总时间。用户可能切换焦点、稍后返回，或者以某些方式导航，使简单的“time on site”模型失真。
因此，我没有使用“average engagement 是 X，所以 next pop 必须在 X 之前发生”这样的公式来确定广告间隔。我只把这个指标当成方向性信号：调整之后，产品是否明显比之前更弱？在我观察的 aggregate level 上，答案是否定的。
Cooldown 和 frequency window 有关，但并不相同
实现中同时存在 240 秒 cooldown 和 240 秒 frequency window，并且每个 window 最多一个成功事件。两者大部分作用重叠，但表达的 constraint 略有不同。
Cooldown 表示：距离上一次事件时间不够时，不允许下一次事件。Window 表示：在定义好的时间段内，不允许超过一个成功事件。我同时保留两者，是为了即使 integration 对某种机制的解释不同，核心 invariant 仍然清晰。
两次成功的 popunder 之间绝不能少于四分钟。
每个 window 一个 event，不等于每次访问一个 event
maxEventsPerWindow = 1 并不一定表示整个访问过程只显示一条广告。它的作用范围只是当前配置的 window；window 结束后可以开始新的 window。这个 1 也不代表一次用户操作，而是该时间段内一次成功的变现事件。
现在检查频率逻辑时，我会问三个问题：counter 到底在数什么？什么会 reset 它？reset window 有多长？如果这三个问题没有答案，像 1 这样的裸数值几乎没有意义。
我把策略和供应商相关实现分开了
需要复用的行为完全可以不暴露任何供应商特定 script、identifier 或 parameter name：
function isEligible(state, now) {
if (!state.hasShownFirstEvent) {
return now - state.arrivalTime >= 45_000;
}
return now - state.lastEventTime >= 240_000;
}这只是解释用伪代码，不是 production source code。Provider、SDK 和 deployment architecture 都会变化，更持久的是策略：保护访问开始阶段，等真实使用已经发生后再允许变现，强制 hard cooldown，并且只在它结束后再次允许。
Build 成功和行为正确是两件事
Typechecker、linter 和 production build 可以验证很多技术属性，但都不能证明浏览器中的广告 timeline 行为正确。这个功能还需要 behavioral validation。
1. 在干净的 browser state 中打开页面。
2. 在 initial delay 结束前交互：不应出现 popunder。
3. 等待 initial delay 结束。
4. 执行 eligible interaction：第一次 popunder 可以发生。
5. 在 cooldown 结束前继续交互：不应出现第二次 popunder。
6. 等待 cooldown 结束。
7. 再次交互：现在可以发生下一次 popunder。成功的 build 和成功的 behavioral test 回答的是不同问题，两者都需要。
整体广告体验比任何单一 placement 更重要
两个独立广告系统单独看可能都合理，组合起来却可能非常激进。例如两个各自限制为四分钟的 format 可以交错触发，让用户大约在 00:45、02:45、04:45 和 06:45 都遇到 interruption。
这让我得到一条更好的原则：
Frequency cap 应按整体用户体验评估，而不是按单个 advertising script 分开评估。
用户感受到的是所有 interruption 的总和，而不是产生每一次中断的配置文件。因此 production audit 真正应该问的是：在某个时间段内，一位用户实际上可能遇到多少次打断式广告事件？
原始 impression 数并不是正确的优化目标
通过缩短 cooldown 创造更多广告机会很容易。困难的问题是：在不降低用户整体经济价值的前提下，能够获得多少额外 monetization。
每次 visit 广告更少的配置，如果能更好保住 repeat usage，长期收入仍然可能更高。因此我更关心 revenue per user over time，而不是 impressions per visit。后者很容易最大化，前者才是真正的商业问题。
更强的实验应该超越一张 aggregate graph
这次 production observation 足以让我确认，自己担心的灾难性结果没有明显发生。但它不足以确定所有 downstream effect。
更强的 experiment 应同时比较每位 unique user 的 monetization revenue、每次 visit 的 revenue、每位 user 的 ad event、active engagement、产品内有意义的 interaction、returning-user rate、随时间变化的 retention，以及更长期的 user value。
两边都必须测量。只看 advertising output，几乎必然会得出“广告越多越好”；只看 engagement，则可能忽略几乎没有 behavioral cost 却能带来显著 revenue gain 的调整。
为什么我让策略保持简单
我没有找到继续增加 exception 的理由。最终逻辑仍然很容易解释：等待 45 秒，在下一次 eligible interaction 时允许 monetization，强制四分钟 hard cooldown，然后允许之后的 eligible interaction 再次 monetize。
少量强 invariant 比依赖大量隐晦 exception 的 policy 更容易理解、测试和 debug。
这种不对称是有意设计的
Policy 对新用户和 engaged user 的处理不同。新 visitor 得到更多保护；持续 interaction 的用户则随着时间产生更多 monetization opportunity。
也就是说，advertising pressure 会随着已经被证明的 engagement 增长，而不是一开始就施加最大压力。这种思维变化是本次 experiment 最有价值的收获之一。
我不会从这个案例中得出的结论
我不会说 45 秒在所有产品上都正确，四分钟就是 optimal interval，更高频的 popunder 永远不会伤害 engagement，或者 stable average 就意味着用户完全不受影响。我也不会把一个 production workload 推广到所有 Web 产品。
不同产品拥有不同用户、预期、acquisition source、usage pattern 和 economics。这个结果的价值恰恰在于它是具体场景的观察，而不是所谓的普遍定律。
真正改变我看法的部分
实验之前，我认为 advertising pressure 和 engagement 几乎是机械关系：把前者提高得足够多，后者就应该明显下降。Production behavior 没有那么整齐。
我把频率提高到自己认为相对较高的水平。用户仍在继续 interaction，aggregate engagement 也保持在熟悉的日常范围内。这不代表成本是零，只代表它没有大到足以在我监控的 metric 中产生预期的明显信号。
“没有影响”和“在这项测量中没有明显影响”之间的区别非常重要。Production system 很少给我们理想中那么干净的 causal story。
我现在遵循的规则
我不再问技术上可以多频繁地显示下一次 popunder。我会问：新用户在 monetization 开始前应该获得多少不受打断的产品体验？Engaged user 在下一次 event 可能发生前应该获得多少不受打断的使用时间？额外广告增加的是 total user value，还是只增加了 impression counter？
对这个应用，我最终保留的是：
首次 eligibility 前等待 45 秒
成功 event 之间至少间隔 4 分钟这些数值只是一种实现。真正值得复用的是更广泛的规则：
保护 user journey 的开始阶段，相比最初的好奇心，更积极地 monetization 已经被证明的 engagement，并用 user-level value 而不是原始广告量判断结果。