The symptom
Three sales calls, three quotes, three completely different numbers for what looks like the same job. One vendor puts your site comfortably on a free tier. Another says you will blow through it in the first week and need a paid plan. A third throws an auto-upgrade warning at you a few weeks into the contract you already signed, because the traffic estimate you gave support turned out to be wrong in a way nobody explained in advance. The bill for server-side Google Tag Manager hosting keeps landing as a surprise, and the reason is not that any vendor is lying about their price. It is that "request" does not mean the same thing on every pricing page.
Agencies usually pick a tier the way they would pick any SaaS plan: look at monthly visitors, round up, add a bit of headroom. That works when the unit being sold is stable across vendors. Here it is not. What a server-side setup costs already covers the total bill for a project. This is narrower and more mechanical: what actually gets counted as one billable request, on the three vendors agencies compare most, Stape, Taggrs and Addingwell, using only what each of them states about it in their own pricing pages.
Why does the same traffic produce different request counts?
Stape's own knowledge base is direct about it: "a request means every incoming hit your Google Tag Manager server container receives. That includes tracking hits and also script loads like gtm.js, gtag.js, analytics.js." The same page adds that only incoming traffic counts, so one event that triggers several tags and sends data to five different ad platforms still counts once, and outgoing calls from the container are free. Addingwell's pricing page states the same mechanism almost word for word: incoming requests to the container are billed, including script downloads such as gtm.js, analytics.js and gtag.js, outgoing requests are not, and one event fanning out to many destinations is still one request. Stape and Addingwell are, on their own published wording, counting the identical thing.
Taggrs describes it differently. Its pricing page defines a request as "every event that happens on your website. Examples include page views, clicks and purchases." That reads as a marketing-event count rather than a server-hit count, and Taggrs does not state anywhere on its public pages whether the script loads that accompany those events, the same gtm.js, gtag.js and analytics.js calls Stape and Addingwell bill separately, are counted as additional requests or folded into the one event. That is not a difference of opinion between the vendors. It is a gap in what one of the three has actually published, which is exactly why a like-for-like comparison from the pricing pages alone is not possible yet.
The practical effect shows up in the numbers. Stape's own documentation states that server container requests typically run roughly 30 percent higher than the equivalent GA4 event count, giving 10,000 GA4 events as producing around 13,000 Stape requests, because every script load adds its own hit on top of the tracking call. Addingwell's counting method implies the same inflation, since it bills the identical set of incoming hits. Whether Taggrs' event-based count runs closer to the raw GA4 number or carries a similar markup is not answered on its pricing page, so treat any side-by-side "requests per month" comparison across all three as an estimate, not a fact, until that gap is closed.
What each tier actually buys
Stape: Free up to 10,000 requests a month, Pro up to 500,000, Business up to 5,000,000, Enterprise up to 20,000,000, Custom above that. No published per-request overage rate, upgrade or a sales conversation instead.
Addingwell: Free with 100,000 requests included, Pay as you go from roughly 90 euros a month for 2,000,000 requests, Enterprise on custom volume. Extra requests are tallied at the end of the billing cycle and added to the invoice, without a published per-unit rate.
Taggrs: Free up to 10,000 requests a month, resetting monthly, then Basic at 750,000, Pro at 3,000,000, Ultimate at 10,000,000, Enterprise unlimited. Once the allocation runs out, new data stops reaching the connected platforms unless the account auto-upgrades.
What good looks like
Before signing on a tier, count real hits instead of trusting an estimate. If you already run a server container on any vendor, or a trial account, pull one representative day of incoming traffic to it and multiply out to a month, rather than accepting a sales estimate based on your monthly sessions. Since Stape and Addingwell bill the same unit, a count on either one transfers reasonably well to the other, with headroom for growth. A count from a Taggrs account does not necessarily transfer to Stape or Addingwell without adjustment, given the unresolved gap in how it treats script loads, so re-verify after a migration rather than assuming the numbers carry over.
Keep the vendor question separate from the recovery question, because they are decided by different things. Which host you pick changes your invoice and your dashboard. It does not change how many conversions actually reach your reporting, that is set by the configuration built on top of whichever container you choose, same-domain cookie serving, consent handling, click ID persistence, event validation against what each ad platform actually reports back. We covered why the vendor itself is not the deciding factor in stape vs taggrs, does the server-side tool matter. A typical account still has 15-30% of conversions going uncaptured before that configuration work is done, and ad blockers strip another 30-40% of events regardless of which host is billing you for requests. Fixing that setup, on whichever vendor you have already committed to, is what Archon Signal does.
Frequently asked
If one page view fires five tags, does that count as five requests?
On Stape and Addingwell, no. Both state explicitly that one incoming event triggering multiple tags to multiple destinations still counts as a single request. Taggrs has not published whether the same holds for its event-based definition, so confirm directly with their support before assuming it behaves the same way.
Why does my Stape request count look higher than my GA4 event count?
Because Stape bills script loads, gtm.js, gtag.js and analytics.js, as separate incoming hits on top of the tracking call itself. Stape's own documentation estimates requests run roughly 30 percent above the matching GA4 event count for that reason. Addingwell's identical counting method implies the same gap.
Can I estimate my request volume before switching vendors?
Yes, and it is more reliable than any vendor's traffic-based estimator. Pull one real day of incoming hits from a live or trial container and extrapolate to a month with headroom for growth. That count carries over reasonably between Stape and Addingwell since they count the same thing, but should be re-checked after a migration to or from Taggrs.
Does the cheapest vendor also fix uncaptured conversions?
No. Request pricing and conversion recovery are unrelated. Every vendor here runs the same underlying server container technology, and none of them changes the setup decisions, same-domain serving, consent handling, event validation, that determine how much of your traffic actually reaches your reports.
What happens if we go over the request limit mid-month?
It depends on the vendor and the plan. Taggrs states that data stops reaching connected platforms once the allocation is used up, unless the account auto-upgrades. Stape and Addingwell do not publish a hard cutoff or a per-request overage rate on their pricing pages, directing overage cases to a plan upgrade or a sales conversation instead.
If you want the real number for your account rather than a vendor's estimate, request a free tracking audit and we will check what your setup actually sends before you commit to a tier.