Skip to content
TopAdsROI
FAQ

Questions buyers ask most

Plain-English answers to the questions buyers and new learners ask most about server-side tracking and data sovereignty across our 14 markets — APAC + North America + United Kingdom.

Quick answer

What is server-side Google Tag Manager?

Server-side Google Tag Manager runs the tagging container on a server that the advertiser owns — typically a container service inside the advertiser's own cloud (for example Cloud Run on Google Cloud, or equivalents on AWS, Azure, or private cloud). It improves data quality and, when run on the advertiser's own first-party subdomain, is far more resilient to ad-blockers and Safari ITP, and it lets the advertiser control exactly which fields leave the perimeter before going to ad platforms. TopAdsROI deploys this container plus Meta CAPI, TikTok Events API, LINE Conversion API, Google Ads CAPI, and LinkedIn Conversions API inside the advertiser's own cloud.

FAQ

Frequently asked questions

The questions buyers and new learners ask most — answered in plain language. Missing yours? Reach out.

  • What is server-side Google Tag Manager (sGTM), and why does it matter?
    Normally your website runs its tracking tags inside the visitor's browser — but browsers (especially Safari) and ad-blockers increasingly block them, so ad clicks and sales get lost and your reported ROI looks worse than reality. Server-side GTM moves that tracking work to a server you control instead, so fewer signals are blocked. When it runs on your own first-party subdomain, requests look first-party rather than third-party, which makes them far more resilient to Safari ITP, Firefox ETP, and ad-blockers — and the data lands in your own cloud, not a vendor's.
  • Why do online ad campaigns 'lose' conversions in the first place?
    A growing share of real purchases never make it back to the ad platform, so it looks like your ads worked less well than they actually did. The usual causes are Safari's Intelligent Tracking Prevention (ITP), which caps script-written browser cookies at 7 days; browsers blocking third-party cookies; ad-blockers stripping out the tracking script; and visitors declining analytics consent. The sale still happened — the platform just never heard about it, so it can't credit your ad or learn from it.
  • What is a Conversions API (CAPI), and how is it different from the old pixel?
    A pixel is a small piece of JavaScript that runs in the visitor's browser and reports events like 'Purchase' to the ad platform. A Conversions API (CAPI) does the same job, but server-to-server — your own server sends the event straight to the platform's API instead of relying on the browser. Because it doesn't depend on browser cookies or scripts loading, CAPI keeps reporting conversions the pixel alone would have dropped.
  • What's the difference between server-side and client-side tracking?
    Client-side (browser-side) tracking runs in the visitor's browser, where ad-blockers, cookie limits, and tracking-prevention can interfere with it. Server-side tracking moves that work to a server you control, which then forwards clean, deduplicated events to the ad platforms. The browser only sends the event once, to your own domain — everything fragile and easily blocked moves off the browser and onto infrastructure you govern.
  • If I use a Conversions API, do I still need the browser pixel?
    Yes — the recommended setup runs the browser pixel and server-side CAPI together, not one instead of the other. The pixel captures rich browser context and fires fast, while CAPI fills the gaps the pixel misses, so together they recover far more conversions than either alone. The two are tied together with a shared event ID so the platform does not count the same sale twice — that's what deduplication handles.
  • What is event deduplication, and why does it matter?
    When the same conversion is reported twice — once by the browser pixel and once by the server CAPI — the platform needs to know it's a single sale, not two. Deduplication solves this by tagging both reports with the same unique event_id, so the platform keeps one and discards the duplicate. Without it your numbers inflate; with it, Meta's Events Manager simply shows the event as 'Deduplicated'.
  • What are fbp, fbc, and click IDs — and why do they go missing?
    They're small identifiers that link a visitor back to the ad they clicked: fbp identifies the browser, fbc carries Meta's click ID from the ad URL, and other platforms have their own (gclid for Google, ttclid for TikTok). They live in cookies, so when Safari ITP expires the cookie or a visitor clears their browser, the link breaks and the conversion can no longer be attributed to the ad. A server-side setup can store these for a window of time and backfill them onto a later conversion, rescuing attribution that would otherwise be lost.
  • What does BYOC mean, and why does keeping data 'in your own cloud' matter?
    BYOC stands for Bring Your Own Cloud — the tracking system is deployed inside a cloud account you own (Google Cloud, AWS, Azure, or private), not on a vendor's servers. That means your raw ad and customer data never leaves your perimeter: you choose the region, set the retention period, and query the data directly, with no vendor lock-in. For regulated industries, 'the data physically stays with us' is often the difference between a deployment a regulator accepts and one it doesn't.
  • Does recovering lost conversions actually improve ROI/ROAS — and how?
    Return on ad spend can only count conversions the platform actually receives, so recovering dropped conversions does two things. First, your reported ROI/ROAS reflects sales that were always real but previously invisible. Second — and more durably — the ad platform's optimisation algorithm gets a more complete signal of who really converts, so it targets and bids more accurately over time. The lasting gain comes from that better signal, not just a one-off reporting bump.
  • Does sending conversions server-side violate user privacy?
    It doesn't have to, and a well-built setup is designed not to. Personal data like email and phone is SHA-256 hashed before it is stored or sent — hashing is a one-way transform, so the platform can match it without ever receiving the plaintext — and consent choices are checked before any event is dispatched. The goal is accurate measurement of data you already collected, not collecting more about people or keeping identifiable details you shouldn't.
  • Will this conflict with my existing GA4 or Google Tag Manager?
    No — server-side GTM sits alongside what you already run rather than replacing it. Your existing web GTM container and GA4 keep working in the browser; the server-side container is a separate destination that receives events and forwards conversions to the ad platforms, and GA4 can even be routed through it for more resilient analytics. Nothing about your current tagging has to be torn out to add a server-side layer.
  • How quickly will I see results, and how do I measure them?
    Once events flow, the first place to look is the ad platform's event-quality view — Meta's Events Manager, for example — where deduplicated server events should appear alongside browser events within days. The clearest measure is the lift in attributed conversions and Event Match Quality versus your pixel-only baseline, so it helps to record that baseline before you start. Treat the reported ROI/ROAS change as the headline and the richer optimisation signal as the longer-term payoff.
  • How is TopAdsROI different from Stape, Addingwell, or gtmserver.com?
    Those are good hosted solutions, but they store your data on their infrastructure. TopAdsROI deploys into your own cloud — Google Cloud, AWS, Azure, or private — with the document store and data warehouse in your project (Firestore + BigQuery on GCP, or equivalents on AWS / Azure), so you get direct query access, your own retention policy, and your own region. We also pre-model 14 markets across APAC, North America, and the UK — each with its own privacy regime — while the others ship a generic platform.
  • Where is customer data stored?
    Inside your own cloud — Google Cloud, AWS, Azure, or private — in the region you choose (for example Sydney, Tokyo, or Singapore for APAC, US regions for North America, or London for the UK). Email and phone are SHA-256 hashed before they reach your data store, so plaintext personal data is not persisted by design.
  • Which ad platforms do you support?
    Day one: Meta Conversions API (CAPI), TikTok Events API, LINE Conversion API, Google Ads (via the Google Ads API / Enhanced Conversions), and LinkedIn Conversions API. And because TopAdsROI is BYOC, platform support is fully customizable — we can build a server-to-server integration for any destination that genuinely offers a Conversions / Events API (for example Microsoft/Bing, Snap, Pinterest, Reddit, and X), configured to your stack on request. The only boundary is honesty: we integrate platforms that provide a real server-side conversion endpoint, not browser-pixel-only channels.
  • Do you support LINE Conversion API?
    Yes — natively. LINE is a primary channel in Japan, Taiwan, Thailand, and Singapore, so we built first-class LINE Conversion API integration alongside Meta and TikTok.
  • Do you support native iOS / Android app conversions?
    TopAdsROI BYOC is a server-side web / H5 product: it recovers web conversions lost to Safari ITP and cookie limits through your own sGTM + CAPI — no app SDK is involved or required for that. If you also need native in-app conversions (iOS / Android / React Native / Flutter) forwarded to the ad-platform CAPIs, our sibling product topadroi.com ships those SDKs as a server-side signal forwarder (not an MMP — it does not do SKAdNetwork attribution). Run it alongside your MMP, or ask us and we will point you to the right fit.
  • Do I need engineers or a DevOps team to use this?
    For the BYOC model (this site), some cloud and DevOps capacity helps, because you're running a container and data warehouse in your own cloud — though deployment is a guided engagement, not a do-it-yourself project. If you don't have that capacity, our sibling managed product at topadroi.com runs the same sGTM + CAPI stack on Cloudflare's edge with no cloud setup, no Terraform, and no DevOps. You can compare the two side by side at /compare/.
  • Can we migrate from SaaS to BYOC later (or vice versa)?
    Yes — both products share the same regulatory templates and feature parity at the CAPI layer. Migration is a configuration export plus re-deployment in your target environment. A common path is to start on SaaS (topadroi.com) to validate channel coverage and ROI, then graduate to BYOC when scale, regulator pressure, or audit posture calls for data sovereignty. Ask us for the migration playbook.
  • How is TopAdsROI deployed, and how long does it take?
    A typical pilot runs 5–10 business days from kickoff to the first event flowing through your edge, depending on scope. A full multi-platform rollout (Meta + TikTok + LINE + Google + LinkedIn) usually completes within about 30 days. Timelines vary with the number of platforms and markets in scope.
  • Can we self-host on our own cloud?
    Yes — that's the default deployment model. We deploy into your own cloud (Google Cloud, AWS, Azure, or private) so the data never leaves your perimeter, and we retain operational responsibility under a Data Processing Addendum.
  • How do you comply with the Australian Privacy Act reform?
    Our policy template aligns with the Australian Privacy Principles (APP), the Notifiable Data Breach (NDB) scheme, and the new automated-decision-making transparency duty (APP 1.7, in force 10 December 2026). Your DPO inherits a working template instead of starting from a blank page.
  • How do you comply with Japan's APPI?
    We honour APPI's third-party-provision and personally-referable-information consent rules from the 2022 amendment, and the external-transmission notification rules under the amended Telecommunications Business Act (in force June 2023). Cross-border transfer disclosures are pre-drafted in Japanese.
  • What is the SLA?
    Availability is governed by the SLA we agree with each customer, not a blanket public promise — we are able to target levels such as 99.9% for our edge and orchestration layer, with the exact commitment set out in your order form. A Workers-bypass mode also lets your ops team manually replay events from your data store if any link in the chain degrades.
  • How is pricing determined?
    Pricing is calibrated to four variables: monthly event volume, number of active markets, ad platforms in scope, and data-residency choice. Three commercial models are available — pay-as-you-go, subscription, or perpetual buyout. Talk to us for a tailored quote.
  • Is there a managed version if we don't have a cloud account or DevOps?
    Yes — our sibling product at topadroi.com runs the same sGTM + multi-platform CAPI stack on Cloudflare's edge. Same 15 lines of defence, no cloud setup, no Terraform, no DevOps. 9 verified-live ad-platform CAPIs on day one (Meta, TikTok, Google Ads, GA4, X, Snap, Pinterest, Reddit, LinkedIn), with more in beta; the free tier covers 100K events/month with no credit card. Choose BYOC (this product) when you want data inside your own cloud; choose managed SaaS when speed and zero infrastructure matter more. Compare side by side at /compare/.
  • What happens if we cancel?
    You keep your cloud and all the data in it — it never lived anywhere else, so there is nothing for us to return. We revoke deployment-support access within 48 hours and hand you a decommission checklist. No vendor lock-in.

Have a question we missed?

A senior solutions engineer will reach out within one business day.