ProPush Constructor 多事件回传难题：用 Claude Code 自建累积回传系统优化 Facebook 信号

本文面向跑 ProPush Constructor 和 Facebook 广告的 affiliate，讲解如何利用 Claude Code 自建 Accumulator 累积回传系统，将单用户触发的多个 zone 回传合并为 1 个干净 Lead 事件，解决 FB CAPI 信号混乱导致的优化偏差。内容涵盖系统搭建逻辑、阈值（如 $0.25）按 GEO 独立设置、clickid 大小写避坑指南，以及基于 API 的替代方案，无需编程基础，重在厘清需求。

Tags:

• ProPush Constructor
• Facebook广告回传
• Claude Code应用
• 累积回传系统
• 流量套利优化

最近 ProPush Constructor 跑 Facebook，又火了。去年还没正式发布前，我写过构建你的Survey Lander - 套利玩法。

我用 Claude Code搭了Accumulator的中转系统。专门解决Propush Constructor 多事件回传难优化问题，把它打包成一个offer，当用户在页面行为上积累到一定值，触发回传。

什么是Constructor

先说清楚 Constructor 模式的机制。

用户在你的 Landing Page 上点击 Claim，ProPush 在后台同时触发多个 zone。一次 Claim 有可能触发 7-9 个 zone。每个 zone 独立发 postback，根据你选择的 category 决定 zone 数量。

正常我们跑offer的回传逻辑是：1 个用户 = 1 次转化 = 1 个 postback。

但 Constructor 给你的是：1 个用户 = 7 个 postback。

你把这 7 个全丢给 FB，FB 的 CAPI 收到 7 个 Lead 事件，全挂在同一个 click 下面。算法会认为这个人群特别容易转化，然后疯狂找类似的人——但实际上你的 eCPM 并没有那么高。

信号乱了，FB 优化的方向就会偏。这是跑 Constructor + Facebook 的核心矛盾。

Accumulator：把 7 个碎片变 1 个干净信号

思路其实不复杂。

既然 7 个 postback 都属于同一个 clickId，那我在中间加一层——按 clickId 把这些小额 postback 累积起来，达到阈值再发 1 次回传给 Tracker，它再回传 FB。

比如：我设的阈值是 $0.25。7 个 zone 加起来跑到 $0.35 的时候，Accumulator 触发，发 1 个 postback。

7 个碎片，1 个干净信号。FB 收到的就是正常的 1 用户 = 1 Lead。

是不是有点 Zeydoo Offer 的味道——用户完成多个步骤，累积达标才算 1 次转化。区别在于 Survey 的规则是联盟定的，Accumulator 的规则是我自己定的。

每个 GEO 的阈值独立设置。 默认$0.25，后面跑其他 GEO 可以单独调。或者做自动调整——根据实际 eCPM 数据动态设阈值。

跟 Claude Code 造这套系统

这是我用 Claude Code 做的第二个实战项目。

一个是 Adv 广告自动化系统（3 天搞定），这次是 Accumulator，跟 Claude Code 对话了几个小时，迭代 2-3个版本。

第一句话我就跟它说：ProPush 多个 zone 的小额 postback，我想做累积回传。

然后分步走。我说方向，它出方案，我测试，有问题回来改。

整个过程不是一次到位的，踩了两个坑。

坑 1：clickid 大小写

ProPush 回传的参数是 clickid，Skro 接收的参数是 clickId。一个小写 i，一个大写 I。

这玩意儿不报错。Skro 收到一个它不认识的参数名，直接静默忽略。你在 Skro 后台看，数据干干净净——因为压根没收到。

我排查了好一会儿才发现是大小写的问题。说实话这种 bug 最恶心，不报错你根本不知道哪断了。

坑 2：ProPush 不支持 zone_id 宏

我最初想在 postback URL 里用 {zone_id} 宏，让每个回传自带 zone 标识，方便统计哪个 zone 贡献多少。

结果 ProPush 不支持这个宏。

Claude Code 给了个替代方案：调 ProPush 的 Statistics API，拉 zone 维度的数据。绕了一步，但问题解决了。

流量套利的模型

目前还是测试阶段，小流量在跑。但已经能看到一些有意思的分布。

Zone Revenue 里面，Back Button 占了大概 50%，MainExit 和 NewTab 加起来占 30% 左右。剩下的散在其他 zone 类型上。

这意味着什么？不是每个 zone 的价值相等。如果后面要精细化，可以考虑按 zone 类型设不同权重。但现阶段先跑通流程，数据够了再优化。

Dashboard 上能看到每个 Click ID 的累积过程。比如 test_e2e_001，几个 zone 的 postback 陆续进来，金额一点点加，到 $0.25 的时候自动触发。

实时流水一目了然，哪个 click 在累积，哪个已经触发，哪个还差多少。

最后一点

如果你也在想跑 ProPush Constructor + Facebook，我总结了这几点：

1. Constructor 模式一次 Claim 触发多 zone，每个 zone 单独回传——不处理的话 FB难以优化

2. 中间加一层累积逻辑，按 clickId 合并多个小额 postback，达阈值再回传，7 变 1，9变1。

3. 阈值按 GEO 独立设置，默认我用 $0.25，后续可以让 AI 实时调整。

4. 注意 clickid/clickId 大小写问题，有时候 AI 也会出错，即便它是 Opus 4.6模型。

5. 不会写代码没关系，Claude Code 能帮你搭——前提是你得清楚自己要解决什么问题

最后一点最重要。工具是 AI 造的，但需求是你自己想清楚的。

Peter的Affiliate之路

关注公众号获取更多Affiliate干货