> ## Documentation Index
> Fetch the complete documentation index at: https://docs.upstackdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# [DRAFT] How Server-Side-Only Tracking Protects Health & Wellness Stores

> Learn why Upstack removes the Meta browser pixel entirely for Health & Wellness flagged stores and sends all data through the Conversions API instead.

# The Short Version

For stores flagged under Meta's Health & Wellness category, Upstack Data operates in **server-side-only mode** — meaning the Facebook browser pixel (the JavaScript snippet that normally runs on your website) is completely removed. All event data is sent directly from Upstack's servers to Meta through the Conversions API (CAPI).

This gives Upstack complete control over what data reaches Meta, which is the foundation of the entire Health & Wellness solution.

# Why the Browser Pixel Is a Problem for H\&W Stores

The standard Meta pixel is a JavaScript snippet that runs in your customer's browser. When someone visits your store, the pixel automatically reads information from the page and sends it to Meta. This includes:

* The **page URL** (e.g., `yourstore.com/products/organic-ashwagandha-supplement`)

* The **page title** (e.g., "Organic Ashwagandha Supplement - 60 Capsules")

* **Product data** embedded in the page (names, descriptions, categories)

* **Referrer URLs** that may contain health-related search terms

* **Content IDs** and other metadata tied to your product catalog

The problem is that this happens automatically. The browser pixel scrapes whatever is on the page and sends it along with the event. For a Health & Wellness flagged store, this means Meta is constantly receiving data full of the exact keywords and content that triggered the flag in the first place — product names with words like "supplement," "vitamin," "collagen," "probiotic," or "CBD."

Even if you've already been flagged, continuing to send this kind of data through the browser pixel can:

* **Reinforce the flag**, making it harder to resolve

* **Trigger a re-flag** if you've set up a new pixel

* **Reduce Event Match Quality** as Meta discards or downgrades events it considers non-compliant

You cannot selectively control what the browser pixel sends. It reads the DOM (the page content) and transmits what it finds. This is by design — Meta wants as much signal as possible for optimization. But for H\&W stores, that same signal is what causes the restrictions.

# How Server-Side-Only Mode Works

When Upstack activates the Health & Wellness container, the tracking flow changes completely:

## Standard Tracking (Browser + Server)

In a normal Upstack setup, events are sent two ways:

1. **Browser pixel** fires in the customer's browser and sends data directly to Meta

2. **Server-side (CAPI)** sends the same event from Upstack's servers to Meta

Both carry a shared `event_id` so Meta deduplicates them into a single event. This redundancy improves match rates and ensures events aren't lost to ad blockers or browser restrictions.

## Health & Wellness Mode (Server-Only)

In H\&W mode, the Meta browser pixel is removed entirely:

<Steps>
  <Step title="Customer actions are captured">
    Customer actions (page views, add to cart, purchases) are captured by Upstack's Theme App Extension on your store.
  </Step>

  <Step title="Data is sent to Upstack">
    Event data is sent to **Upstack's servers** — not to Meta.
  </Step>

  <Step title="Data is sanitized">
    Upstack **processes and sanitizes** the data (see the [Data Sanitization](/guides/health-wellness/data-sanitization-health-wellness) article).
  </Step>

  <Step title="Clean event is sent to Meta">
    The clean event is sent to Meta via the **Conversions API only**.
  </Step>
</Steps>

No JavaScript from Meta ever runs on your site. Meta never sees your page content, URLs, or product data directly.

# What Data Gets Sent to Meta

In server-side-only mode, Upstack sends only what Meta needs for attribution and optimization:

**Always sent:**

* **Event type** — the action that occurred (mapped to a custom H\&W event name)

* **Event time** — when the action happened

* **User identifiers** — hashed email, hashed phone number, Facebook click ID (`fbclid`), and browser ID (`fbp`) for matching the event to a Meta user

* **Event source URL** — the alias domain URL (not your real store URL)

**Sent for conversion events (Purchase, Add to Cart, etc.):**

* **Value** — the purchase amount or cart value

* **Currency** — e.g., USD

**Never sent:**

* Product names, descriptions, or categories

* Real page URLs from your flagged domain

* SKUs, product IDs, or catalog data

* Any content that could contain health/wellness keywords

This is enough data for Meta to attribute conversions to your ads, optimize delivery, and build audiences — without exposing any content that would trigger or reinforce the H\&W flag.

# Why CAPI-Only Still Works for Optimization

A common concern is that removing the browser pixel will hurt performance. In practice, for H\&W flagged stores, the opposite is true.

**The browser pixel was already compromised.** Once a store is flagged, Meta restricts what it does with browser pixel data from that domain. In many cases, browser events are partially or fully ignored for optimization. Removing a data source that Meta is already discounting doesn't hurt you — it removes a liability.

**CAPI events are treated as higher quality.** Server-side events carry hashed first-party data (email, phone) that provides stronger identity matching than cookies alone. Meta's own documentation recommends CAPI as the primary data source, with the browser pixel as a supplement.

**Event Match Quality stays strong.** EMQ depends on the quality of user identifiers (email, phone, click ID), not on the transmission method. Upstack captures these identifiers at key moments (checkout, account creation) and sends them via CAPI. Most Upstack H\&W customers see EMQ scores comparable to or better than their pre-flag performance.

**The flag was the real performance killer.** The biggest optimization hit comes from the flag itself — restricted audiences, blocked events, degraded delivery. By going server-side only with clean data from an unflagged domain, you're restoring what the flag took away.

# How This Differs from Standard CAPI Setups

Not all server-side tracking is the same. Here's how Upstack's H\&W implementation differs from a standard CAPI setup:

<table role="presentation"><tbody><tr><td><p class="no-margin"><b>Feature</b></p></td><td><p class="no-margin"><b>Standard CAPI</b></p></td><td><p class="no-margin"><b>Upstack H\&W (Server-Only)</b></p></td></tr><tr><td><p class="no-margin">Browser pixel active</p></td><td><p class="no-margin">Yes (redundant tracking)</p></td><td><p class="no-margin">No (completely removed)</p></td></tr><tr><td><p class="no-margin">Data sanitization</p></td><td><p class="no-margin">No</p></td><td><p class="no-margin">Yes (keywords, URLs, product data stripped)</p></td></tr><tr><td><p class="no-margin">Event source URL</p></td><td><p class="no-margin">Your real domain</p></td><td><p class="no-margin">Clean alias domain</p></td></tr><tr><td><p class="no-margin">Event names</p></td><td><p class="no-margin">Standard Meta events</p></td><td><p class="no-margin">Custom H\&W event mappings</p></td></tr><tr><td><p class="no-margin">Product data sent</p></td><td><p class="no-margin">Yes (content\_ids, content\_name)</p></td><td><p class="no-margin">No (stripped before sending)</p></td></tr></tbody></table>

A standard CAPI setup still relies on the browser pixel running alongside it. For H\&W stores, that browser pixel is the source of the problem. Upstack's approach eliminates it entirely and controls every byte of data that reaches Meta.

# What You Need to Do

Nothing — Upstack handles this automatically when the Health & Wellness container is activated during your onboarding call. The browser pixel removal, CAPI-only routing, and data processing all happen on Upstack's side.

<Note>
  **Watch for other tracking tools.** Any active browser pixel — from Shopify's native integration, Triple Whale Sonar, Elevar, or hardcoded JavaScript — will send unsanitized data to Meta and undermine the server-side-only approach. Make sure all other Meta pixel sources are disabled.
</Note>

[How to Disable Facebook and Instagram Data Sharing in Shopify →](/guides/facebook-ads/how-to-disable-facebook-and-instagram-data-sharing-in-shopify)

# Related Articles

* [How Upstack Data Solves Health & Wellness Restrictions](/guides/health-wellness/how-upstack-solves-health-wellness-restrictions)

* [How to Set Up a Health & Wellness Pixel for Meta](/guides/health-wellness/setup-health-wellness-pixel-for-meta)

* [How to Disable Facebook and Instagram Data Sharing in Shopify](/guides/facebook-ads/how-to-disable-facebook-and-instagram-data-sharing-in-shopify)