I’m looking for advice on the cleanest way to handle a server-side conversion aggregation pattern in sGTM (hosted on Stape, pro plan). Hoping someone has solved this before.
Setup: Our partner fires 1-3 partial postbacks per lead within seconds (same click_id, different idempotency_id, partial payouts). I need to SUM the values and fire ONE conversion to Google Ads.
What I have working:
Stape Data Client receives postbacks at /data
Google Ads tag fires on each incoming event
The problem: With multiple postbacks per lead, Google Ads dedupes on order_id and only counts the first partial value, not the sum. I need to wait for all postbacks to come through (delay is a few seconds max), then fire ONE conversion with the aggregated total.
Constraints:
Pro Plan (can’t use Request Delay power-up)
Volume: ~50 conversions/day, clustered in bursts
Partner won’t aggregate on their end
What’s the cleanest architecture for this? Open to any approach.
I think the easiest way would be to use the Stape Store + Event Enricher Tag by Stape (you can find it in the gallery on sGTM).
The idea is that on all webhooks you store data to Stape Store and on the last one you run Event Enricher tag , collecting all previously recorded data in Stape Store.
Event Enricher sends a separate event on which your Google ADS conversion will work.
One question - how does the Event Enricher tag know which postback is “the last one” for a given click_id?
In our case all 1-3 postbacks for the same click_id arrive within seconds of each other or sometimes within the same second, but there’s no flag indicating “this is the final one.” And the amount of postbacks for each conversion varies.
In that case I think you can also store something like counter to the Stape Store with which you can count the number of webhooks.
On each webhook you store parameter with value “{{counter}}+1” and your event enricher will work on the condition “if {{counter}} >= 3”
One thing to flag on the counter >= 3 approach — you said postbacks vary between 1 and 3 per lead. If a lead only fires 1 or 2 postbacks, that condition never triggers and you lose the conversion entirely.
The core problem here is “detect when nothing else is coming” — which fundamentally needs a timer, and without the Request Delay power-up you don’t have one natively in sGTM.
Two directions that work for your volume:
1. Lightweight external buffer. Route postbacks through a Cloud Function that holds a 30-60s window per click_id, sums values, then fires one clean event back to your sGTM endpoint. At 50 conversions/day this is trivial to run and costs essentially nothing on GCP free tier.
2. Google Ads Conversion Adjustments. Fire the conversion on the first postback with the partial value (click_id as order_id). On subsequent postbacks, push a RESTATE adjustment to update the value to the running total. No delay needed — you let Google Ads handle the aggregation natively. The tradeoff is you need to set up the Conversion Adjustment upload (API or offline), which is more setup but zero external infrastructure after that.
At your scale I’d lean toward option 1 — a simple Cloud Function with a setTimeout is probably 30 lines of code and solves it cleanly without touching your Google Ads conversion setup.
Thanks @enricoforte for highlighting the variation in the number of postbacks. @Ion_R Yes, if the number of postbacks is not static and varies from 1 to 3 for each lead, and there are no identifiers at the postback level, there is no simple solution here(I mean internal sGTM functionality).Both options that @enricoforte suggested would work to solve this problem.