AboutAll ServicesFree EmailOur WorkGuidesFAQContact
Services
SEO ServicesEcommerce RankingSpeed OptimizationWebsite AuditGoogle Ads ManagementMeta Ads ManagementSocial Media ManagementAnalytics & TrackingShopify Catalogue SEO
Build & Solutions
WordPress DevelopmentEcommerce DevelopmentCustom EcommerceFlying CartFlying AdsFlying Blog
Dedicated Sites
ServicesCareFirstlightTruefeedWoo2ShopifyShopifyRealty LeadsAnkShakti

Guide

Stape or Google Cloud for server-side Tag Manager

Should I host server-side Google Tag Manager on Stape or Google Cloud?

6 min read

Short answer

For most Indian stores, Stape. Both run the same server Tag Manager container. Google Cloud bills for always-on instances and leaves setup, scaling and monitoring to you. Stape charges a flat monthly plan and adds a first-party loader, Cookie Keeper, ready-made integrations and readable request logs, which is what you need when proving that purchases reach the ad platforms.

Same container, different host

Server-side Tag Manager is a container that receives events and forwards them to Google Ads, GA4, Meta and others. It needs somewhere to run. Google's own route is Cloud Run on Google Cloud. Stape is a hosting service built only for these containers.

The tags, triggers and clients inside are identical. What changes is cost, maintenance and how easy it is to see what happened to a single request.

Cost and upkeep

On Google Cloud you pay for the instances and the traffic, and Google's production guidance keeps several instances running at all times, billed whether or not traffic arrives. You also own the updates, the scaling limits and the monitoring.

Stape bills a flat plan based on request volume, in your own account. On the stores we run, the plan has been the smaller cost and the time saved matters more than the fee.

What Stape adds that matters in practice

A custom loader serves the Tag Manager script from your own subdomain, so fewer ad blockers stop it.

Cookie Keeper keeps first-party cookies alive longer than Safari otherwise allows, so a returning shopper still links to their original ad click.

A Shopify app with a webhook option sends paid orders straight to the server container, server to server. On a store with a third-party checkout that is the path that makes tracking work at all.

Request logs that show each incoming event and the outgoing requests it caused. That is how you prove an order reached Google Ads rather than hoping.

Traps we hit, so you do not have to

A 200 response proves nothing. The container accepts an order and returns success whether or not any tag used it. One Shopify webhook arrived on every order, returned 200, and fired no conversion, because the client that claimed it did not turn it into a purchase event.

Google Ads needs the click cookie, not just the click id. A server-side purchase with the Google click id in its data produced nothing. The same event with the conversion linker cookie set landed. Always verify the outgoing conversion request carries the click id and order value.

Logs cap and truncate. Stape's log views stop at 1,000 records without an obvious warning. Filter by request path until the view covers the whole period.

Some features depend on the plan. Log export and monitoring are not on every plan, so check before relying on them for proof.

When Google Cloud makes sense

Very high traffic with an in-house engineer who already runs Google Cloud, strict requirements that data stays in infrastructure you control, or an existing Cloud contract. Outside those, the extra cost and upkeep buy nothing a store owner will notice.

Server-side tracking setupShopify checkout tracking fixGoogle Ads not tracking Shopify orders

Want free stats on your site first?

Send us the URL. We pull the numbers from your own accounts and tell you what is wrong before there is any quote, and before there is any contract.

No pitch deck, no obligation. Bring your URL and we will look at it together.