ProPush Constructor: DIY Facebook Postbacks with Claude Code

Running ProPush Constructor on Facebook is hot again. Last year, before it officially launched, I wrote “ProPush Constructor: Build Your Own Survey Lander for Arbitrage.”

I used Claude Code to build an Accumulator, a relay system that sits in the middle. It exists to solve one problem: ProPush Constructor fires multiple events per user, which makes it hard to optimize. The Accumulator packages them into a single offer: once a user’s on-page actions add up to a set value, it fires the postback.

What Constructor is

First, let’s be clear about how Constructor mode works.

When a user clicks Claim on your landing page, ProPush triggers multiple zones in the background at the same time. One Claim can trigger 7-9 zones. Each zone sends its own postback, and the category you pick determines how many zones there are.

The normal postback logic when we run an offer is: 1 user = 1 conversion = 1 postback.

What Constructor gives you is: 1 user = 7 postbacks.

If you throw all 7 at FB, FB’s CAPI receives 7 Lead events, all hanging off the same click. The algorithm decides this audience converts unusually easily and goes all out finding similar people, but your eCPM isn’t actually that high.

The signal is scrambled, so FB optimizes in the wrong direction. That’s the core conflict of running Constructor + Facebook.

Accumulator: turning 7 fragments into 1 clean signal

The idea isn’t complicated.

Since all 7 postbacks belong to the same clickId, I add a layer in between: accumulate those small postbacks by clickId, and once they reach a threshold, send 1 postback to the tracker, which then passes it on to FB.

For example: I set the threshold at $0.25. When the 7 zones add up to $0.35, the Accumulator triggers and sends 1 postback.

7 fragments, 1 clean signal. What FB receives is a normal 1 user = 1 Lead.

It feels a bit like a Zeydoo offer, doesn’t it: the user completes multiple steps, and only when the accumulated value hits the bar does it count as 1 conversion. The difference is that with a survey, the network sets the rules; with the Accumulator, I set them.

Each GEO gets its own threshold. The default is $0.25, and it can be tuned separately when I run other GEOs later. Or it can be automated: set the threshold dynamically based on real eCPM data.

Building the system with Claude Code

This is the second real-world project I’ve built with Claude Code.

The first was the Adv ad automation system (done in 3 days). This time it was the Accumulator: a few hours of back-and-forth with Claude Code, iterating through 2-3 versions.

The very first thing I told it was: ProPush sends small postbacks from multiple zones, and I want to accumulate them before firing the postback.

Then we went step by step. I set the direction, it proposed the solution, I tested, and anything broken went back for another round.

It wasn’t a one-shot process. I hit two pitfalls.

Pitfall 1: clickid casing

The parameter ProPush sends in its postback is clickid. The parameter Skro expects is clickId. One lowercase i, one uppercase I.

This thing doesn’t throw an error. Skro receives a parameter name it doesn’t recognize and silently ignores it. You look at the Skro dashboard and the data is spotless, because nothing ever arrived.

It took me a good while of digging before I realized it was a casing issue. Honestly, this kind of bug is the nastiest: no error, so you have no idea where the chain broke.

Pitfall 2: ProPush doesn’t support a zone_id macro

Originally I wanted to use a {zone_id} macro in the postback URL, so every postback would carry its zone identifier and I could see how much each zone contributed.

Turns out ProPush doesn’t support that macro.

Claude Code offered a workaround: call the ProPush Statistics API and pull zone-level data. One extra step, but the problem was solved.

The traffic arbitrage model

It’s still in the testing phase, running on small traffic. But some interesting distributions are already visible.

In Zone Revenue, Back Button accounts for roughly 50%, and MainExit plus NewTab together make up around 30%. The rest is scattered across the other zone types.

What does that mean? Not every zone is worth the same. If I want to get more granular later, I could weight zone types differently. But for now the priority is getting the pipeline running; optimization can wait until there’s enough data.

The dashboard shows the accumulation process for each Click ID. Take test_e2e_001: postbacks from several zones trickle in, the amount climbs bit by bit, and at $0.25 it triggers automatically.

The real-time feed makes it obvious at a glance: which clicks are accumulating, which have already fired, and which are still short.

One last thing

If you’re also thinking about running ProPush Constructor + Facebook, here’s my summary:

1. In Constructor mode, one Claim triggers multiple zones, and each zone posts back separately. Left unhandled, that makes it hard for FB to optimize.

2. Add an accumulation layer in the middle: merge the small postbacks by clickId, and only fire the postback once the threshold is reached. 7 becomes 1, 9 becomes 1.

3. Set the threshold per GEO. I use $0.25 by default, and later I can let AI adjust it in real time.

4. Watch out for the clickid/clickId casing issue. Sometimes even AI gets it wrong, even on the Opus 4.6 model.

5. Not being able to code isn’t a problem; Claude Code can build it for you. The prerequisite is that you know exactly what problem you’re trying to solve.

That last point matters most. The tool is built by AI, but the requirement is something you have to think through yourself.