Nanobag · nanobag.com · freelance / contract · remote

Server-Side Tracking Specialist
Stape + sGTM on Shopify

We've part-built a server-side tracking stack and we want a specialist to audit it, finish it, add TikTok, and own its reliability. One non-negotiable brief: nothing that currently works may break.

Shopify · 14 markets Stape Pro · own domain Cookiebot / EU consent Audit-first milestone Live A/B program running

The architecture you're inheriting

Every system runs on its own independent path. Stape receives copies — it is deliberately not in anyone's critical path. Your job is to finish the build without ever breaking this property.

Shopper's browser Shopify servers Google & YouTube app pixel GA4 + Ads feed Facebook app pixel Meta (browser) checkout orders — 100%, unblockable Shopify Analytics webhook copies Stape · nb.nanobag.com CAPI events Meta CAPI gAds · TikTok → ⌁ Stape down or over quota → the three lanes above never notice
The fail-open design: GA4 rides Google's own Shopify app (it also runs the Merchant Center feed + server-assisted Ads conversions — untouchable), Meta rides Facebook's app, the money truth lives in Shopify's ledger, and Stape hangs off webhooks as a parallel enrichment pipe. Dashed = copies, not dependencies.

Current state — what you'll audit on day one

● Live today

  • Server GTM container"Nanobag Shopify Server" on Stape Pro (500k req/mo)
  • Custom domainnb.nanobag.com — DNS-verified, first-party
  • Order + refund webhooksverified flowing into the Data Client, server-to-server
  • Web GTMGTM-WNJCZ75Z hand-wired in the theme

◐ Staged, unpublished

  • Setup Assistant pendingcontainer tags will be generated with Stape's Setup Assistant (run by our team; you validate + extend). An old imported template (fb-ga4-gads-server, now deprecated by Stape) sits in the container — discard it, don't build on it
  • A colleague's [Stape] workspacesits unpublished in web GTM — review before any publish
  • Written rollout planphases below — yours to challenge in the audit

○ Off by design

  • Stape custom pixelexists, deliberately disconnected until rollout
  • GTM injection & custom loadernever enabled — inline risk handled in phases 4–5
  • Dead legacy containerGTM-WHXM36M still referenced; removed during the swap

Also in the estate: Zipify OneClickUpsell fires extra purchase events (dedup landmine) · Brevo, Microsoft Ads, Clarity, Hotjar client-side (a tracker diet is planned) · Cookiebot auto-blocking governs EU pre-consent script execution — this store once lost a day of EU conversions to a careless script-order change, so consent behavior is verified on every change, no exceptions.

The mission — nine phases, sequence agreed

  1. 1Audit

    Written review of everything above: gap list, risk register, a dedup map of every platform's event sources (channel apps, Zipify, planned server events) — and a per-platform recommendation memo for the rest of the stack we run (Brevo, Microsoft Ads, Microsoft Clarity, Hotjar, plus anything you surface): move server-side, keep client-side, or drop, with the quota/effort/signal trade-off for each. We want your advice before your build — not a blanket migration.

  2. 2Meta Conversions API

    Server-side only, so it can start immediately. Base container config comes from Stape's Setup Assistant (run by our team; you validate and extend — the old imported template is deprecated and gets discarded). Purchase-first from order webhooks, event_id dedup against the Facebook app's browser events. Proof in Events Manager (Received vs Deduplicated) before any funnel events. Target: the ~20–25% of purchases browser pixels miss — with zero double counting.

  3. 3Reconnect the Stape pixel

    Goes live once the current A/B test window closes. Browsing + checkout events into the Data Client. Fail-open; EU consent-gating via Shopify's privacy API is correct behavior and must be preserved.

  4. 4GTM injection — as a swap

    Stape app injects; the hand-coded theme snippet and the dead legacy container come out in the same change. One GTM loader, ever. Theme edits executed by our in-house dev on your spec.

  5. 5Custom loader

    Loader pageviews count against the 500k/mo plan — exhaustion with the loader inline = store-wide GTM outage. Ships only with headroom verified and a working fallback to Google's CDN (hand-rolled if Stape has none).

  6. 6Google Ads server-side

    The channel app already server-assists Ads conversions — this phase needs a transaction_id-level dedup design of its own, after Meta proves out.

  7. 7TikTok — new platform, built right from day one

    We sell via TikTok Shop but have no on-site TikTok tracking yet. You design and ship pixel + Events API via Stape with dedup between them — and the pattern becomes the template for every future platform.

  8. 8Approved platform expansions + Cookie Keeper

    Execute whichever moves we green-light from your audit memo (Brevo, Microsoft Ads, or others) — each to the same dedup-proof standard. Enable Cookie Keeper and remaining power-ups where they add signal without adding coupling risk.

  9. 9Monitoring & handover

    Stape usage alerts with headroom policy, per-platform event-health checks, a runbook a successor could operate from, monthly health report.

Who does what — so nobody steps on anyone

Three pairs of hands touch this stack. The split below is the working agreement: if a task isn't in your column, ask before touching it — especially anything inside the theme or Shopify Flow.

You — the specialist

  • Audit & designsgap list, risk register, dedup maps, the platform recommendation memo
  • Stape containertags, clients, transformations — validating and extending the Setup Assistant output
  • Platform dashboardsMeta Events Manager, Google Ads, TikTok; web GTM publishes (after reviewing the existing unpublished workspace)
  • Proof & monitoringdedup evidence per event class, usage alerts, runbook, monthly health report
  • Specs for theme changesyou write exactly what goes in/out (loader snippet, fallback, injection swap) — you don't ship it

Our in-house developer

  • All theme & repo codesnippet removal, loader install, any Liquid — executed from your spec through our dev→live process
  • Consent QAruns the consent-guard check + pre-consent EU probes with you on every script change
  • Shopify admin opstheme publishes, Flow workflows, order-tag attribution — off-limits to direct edits
  • A/B test calendartells you when change windows open and close

Our team

  • Stape Setup Assistantruns it to generate the base container config you build on
  • Access & credentialsStape, GTM, Meta BM token, Google Ads, TikTok, scoped Shopify collaborator
  • Decisionsgreen-lights your recommendation memo; owns budget and platform priorities
  • Measurement truthShopify analytics + order-tag reporting stays ours — not in scope for changes

The "nothing breaks" rules

These are contractual, not stylistic. The architecture's whole value is that no single failure can stop tracking — every change you make must leave that true.

Never route GA4 through sGTM.

GA4 rides Google's own app (which also runs the product feed + Ads conversions). Server-injecting sessions or checkouts double-counts — only purchases carry a dedup key, and they already read ~107%.

Fail-open, always.

Stape may receive copies and enrich. It may never become a dependency without a fallback. "Stape down or full" must stay a non-event for every other system.

One GTM injector.

Two container loads = double-fired tags. The injection swap removes the old snippet in the same change, and any web-GTM publish reviews the existing unpublished workspace first.

EU pre-consent proof on every script change.

Fresh pre-consent EU pageview before and after ship — we provide the automated consent-guard check. This rule exists because of a real, expensive incident.

No changes during live A/B windows.

Tests run on Shopify Rollouts with hard tracking freezes. The calendar is coordinated with us; order-tag attribution (Shopify Flow) is off-limits.

Dedup evidence before scale.

Every server event class ships with Events-Manager-level proof it doesn't double count — Zipify's extra purchase events included.

You're a fit if

Must have

  • Deep Stape + server GTM experience on Shopify specifically — you know what the Google & YouTube and Facebook channel apps already send
  • Meta CAPI dedup design in production: event_id strategy, EMQ, Events Manager diagnostics
  • TikTok Events API with pixel dedup
  • Consent mode v2 / GDPR fluency — Cookiebot or equivalent, pre-consent behavior, EU markets
  • Writes runbooks and risk registers — this is audit-and-own, not move-fast

Nice to have

  • Google Ads conversion architecture (OCT vs channel-app conversions)
  • Brevo / Microsoft Ads server-side
  • ShopifyQL / analytics literacy
  • Experience working alongside a live A/B testing program

How we'll judge success

More conversions, verified

Meta → TikTok → Google Ads report more attributed purchases with dedup proven — no inflation anywhere.

Zero regressions

EU conversion rate stable through every change; GA4 untouched; no double-fired events on any platform.

Outage-proof posture

Quota and failure modes documented + monitored. A Stape incident loses nothing outside Stape itself.

A real handover

A runbook good enough that a competent successor could operate the stack from it alone.

To apply

Send a short note covering three things:

  1. A comparable Shopify + Stape build you've run — what you dedup'd and how you proved it
  2. Your audit approach for a setup like the one above
  3. Availability + rate

We provide on start: Stape, web GTM, Meta BM, Google Ads, TikTok access, a scoped Shopify collaborator account, our written rollout plan, the consent-guard QA tooling, and the A/B test calendar. First milestone is the paid audit.