16. How Stape Works
What Stape actually is — managed sGTM hosting plus a convenience layer — with every power-up demystified against the concepts in this guide, and an honest look at the trade-offs.
If you work in tracking, you meet Stape weekly — in tutorials, in client audits, in "just use Stape" advice. This chapter exists for two reasons. Practically: you'll operate or migrate Stape setups, and you should know what's under the labels. Pedagogically: Stape is Chapters 9–14 productized, and decoding its feature list against those chapters is the best review exercise in this guide.
What Stape actually is
Three facts orient everything:
- It's not a Google product, and it's not a different technology. Stape runs the same official server-container image you met in Chapter 10, on their infrastructure, in data centers around the world.
- It's a hosting company with a convenience layer. The core offer is Path 2 from Chapter 15 — they run the container, you configure it from the normal GTM console — wrapped in a dashboard that automates deployment, domains, and monitoring.
- Its real product is the gap Google left. When sGTM shipped (2020) with a ~$120/month GCP default, Stape sold the same capability from free/cheap tiers — and grew into the category's default answer. Pricing is by request volume, with a free tier for tiny sites and paid tiers stepping up from roughly the cost of a lunch.
The mental model: Stape : sGTM :: a managed WordPress host : WordPress. Same engine; rented operations; proprietary conveniences around it.
The power-ups, demystified
Stape's feature list — "power-ups" — reads as magic until you map each one to a chapter of this guide. Then it reads as a checklist of everything server-side tagging enables:
| Power-up | What it actually is | The concept |
|---|---|---|
| Custom Loader | serves the web container script from your domain under randomized, per-account paths instead of /gtm.js |
first-party script serving + path-rule evasion — Chapter 11, verbatim |
| Cookie Keeper | re-issues key vendor cookies (_fbp, _ga…) as long-lived, HTTP-set first-party cookies via the server response |
Chapter 11's server-managed cookies, generalized from FPID to the whole identifier zoo |
| User ID | mints its own persistent server-side identifier and attaches it to events | a vendor-neutral FPID — durable identity feeding match keys (Ch. 13) |
| Anonymizer | strips or masks PII and IP fields from events before forwarding to vendors | Chapter 14's redaction tier, productized for consent-constrained setups |
| Proxy Files | serves vendor scripts (fbevents.js, etc.) through your tracking domain |
first-party serving extended beyond Google's scripts |
| GEO Headers | resolves the visitor's IP to country/region/city and attaches it to events | edge enrichment — useful when you anonymize the IP afterwards |
| Bot Index / filtering | flags datacenter and known-bot traffic | Chapter 14's filtering tier |
| Custom domains with dedicated IPs | your tracking subdomain points at IPs provisioned for you — A records, not a shared CNAME | Chapter 11's gold standard, sold as a feature precisely because of Safari's CNAME rule |
| Logs & alerts | request logs, error notifications | Chapter 14's silent-decay monitoring, rented |
Two things follow from reading the table. First — there is no magic: every power-up is an implementation of something you now understand from first principles, which means you can also implement, audit, or replace each one. Second — the table is good product taste: it's a faithful list of what actually matters operationally in server-side tagging, which is exactly why we built our own stack around the same fundamentals (first-party edge with client-specific stealth paths, server-set cookies, preview isolation, per-client logs).
What you trade
The honest ledger, because "just use Stape" deserves the same scrutiny as any architecture decision:
- A vendor inside the data path. Every event your visitors generate transits Stape's infrastructure; they terminate TLS for your tracking subdomain. That's a data-processor relationship (DPA, sub-processor lists, jurisdiction questions — Chapter 17), and a trust decision. Not a criticism — the same is true of any managed host, ours included — but it should be a decision, not a default.
- Request-volume pricing compounds. Cheap at 100k requests/month; do the arithmetic again at 10M, where dedicated infrastructure (Chapter 15, Path 3) is often several times cheaper.
- Convenience is soft lock-in. Custom Loader paths, Cookie Keeper behavior, User ID continuity — leave, and each must be re-implemented or identity continuity breaks. Migrations are very doable (the underlying container config is yours, in Google's console); the conveniences are what you rebuild.
- Multi-tenancy posture varies by tier. Shared infrastructure and shared IP ranges at the entry tiers; dedicated IPs higher up. After Chapter 11 you know exactly why that tier difference is not cosmetic.
The market around it
Stape is the category leader, not the category. Addingwell (French, EU-residency-forward) and Taggrs (Dutch, similar pitch) compete on the same shape; agencies white-label all three; GCP remains the reference path; and self-hosting underpins agency-grade and privacy-maximal builds. The category exists for one reason worth internalizing: Google shipped the engine without affordable wheels, and everything in this market — Stape's power-ups, Addingwell's residency pitch, our own Pixel Logic Server — is a different answer to "what should the wheels look like".
Where we position ours, stated plainly: dedicated per-client stacks (Chapter 10's pixel-agent / tracker-live / tracker-debug anatomy) on infrastructure we operate — Stape-class convenience in provisioning, DNS, and monitoring, with the isolation and DNS posture of the self-hosted path. That's the deliberate trade-off we sell; these docs are how we make it inspectable.
Choosing, in five questions
- Volume? Tiny → Stape free/entry tiers are unbeatable. Mid → managed convenience usually wins. High → dedicated infrastructure economics take over.
- Who must control the data path? "A reputable processor is fine" → managed. "Our infrastructure, our jurisdiction" → dedicated/self-host.
- Ops appetite? None → managed, full stop. An agency amortizing one host across many clients → dedicated flips the math.
- Safari posture? Whatever you pick, end the DNS chain at dedicated IPs / A records (Chapter 11). On managed hosts, that's typically a paid tier — budget for it.
- Exit story? Your container config always lives in Google's console (portable by design); list the conveniences you'd need to rebuild and decide with eyes open.
One chapter of machinery remains — the one that governs all the others. Server-side tagging concentrated your data flow into one pipe you control; the law has opinions about that pipe: Chapter 17 — Consent & Privacy.