Skip to main content

FAQ

Why dataLayer.push instead of direct fbq('track', ...)?​

Direct fbq tags only Meta in the browser. You lose:

  • Forwarding to GA4 and Google Ads
  • Server-side (CAPI)
  • Pixel/CAPI dedup
  • Routing N events to M platforms (every new platform = re-dev)

With dataLayer.push, you speak once, GTM dispatches.

The client already has fbq('track') calls in the code. Keep them?​

Remove them once the dataLayer.push equivalent is wired and validated. Otherwise:

  • Double counting on Meta
  • EMQ drops because the old calls lack user_data
  • The agency loses control of the pixel

Should we push events on every scroll / hover?​

No. Only high–business-value actions. Scroll tracking can be added later via GTM (auto-tracking, not in dataLayer).

Should we hash user_data on the front-end?​

No. Send in plain text. GTM Server hashes before sending to Meta. Hashing on both sides = double hash = broken matching.

What about Safari / iOS ITP?​

Server-side GTM (Stape) solves ~90% of the issue:

  • Cookies set by your domain → full lifetime (~6 months) vs Apple's 7 days.
  • CAPI sends from your server → bypasses Pixel blocking by ITP.

Apple may still truncate UTMs via Mail Privacy Protection. Handled agency-side.

How are staging vs production handled?​

The agency runs:

  • Staging GTM container → tied to a Meta test dataset + a GA4 test property.
  • Production GTM container → tied to production datasets.

You load the GTM snippet matching the environment (different GTM-XXXXXX).

The user denied cookies. Still push?​

Yes, always. GTM filters by Consent Mode v2:

  • analytics_storage: denied → GA4 in "consent denied" mode (modeled).
  • ad_storage: denied → Pixel doesn't drop _fbp, Ads doesn't drop _gcl_au.
  • ad_user_data: denied → CAPI sends a "no PII" event for aggregate measurement.

Everything goes through GTM — you push regardless.

How do we handle purchase when payment is validated by async webhook (Stripe, Klarna)?​

Two cases:

  1. Confirmation page arrives after webhook (e.g. 3DS redirect that returns once validated) → classic browser-side push.
  2. Webhook validates after the page → don't push browser-side. Configure a server-to-server push from your backend directly to GTM Server (HTTP POST to https://analytics.biosphereskincare.com/data). Coordinate with the agency.

We have a cart that mutates without page reload. What do we push?​

Each interaction = one push:

  • Quantity up → add_to_cart with delta
  • Quantity down → remove_from_cart with delta
  • Removal → remove_from_cart with current qty
  • Coupon applied → ⚠️ no standard event; the coupon will appear on the next begin_checkout / purchase.

Multiple brands or sites?​

  • Same id everywhere in feeds.
  • Separate GTM containers per brand/site (agency-side).
  • Separate Meta Pixels if Business accounts differ.

Checkout on a subdomain (checkout.biosphereskincare.com). Issue?​

No, as long as:

  • The GTM snippet is on this subdomain too.
  • The _fbp cookie is set on .biosphereskincare.com (parent domain) → Pixel coordination.
  • Stape CNAMEs cover both (already the case with analytics.biosphereskincare.com).

Can't expose an HTTPS product feed. Alternatives?​

Options (coordinate with the agency):

  • Push a CSV / Google Sheet on a daily cron.
  • Native Shopify / WooCommerce connector (if applicable).
  • Private API consumed by the agency.

But ideally: HTTPS auto-generated feed is the standard.

Question not covered?​

Ping Charles: charles@agence-bb.ch or via the shared Slack.