Whop ships a browser pixel and a server-side Events API for conversion tracking, but no Google Tag Manager templates. I built both: a web container tag that replaces the pixel snippet, and a server container tag that sends conversions to the Events API with automatic data mapping. Both are open source under Apache 2.0.

What Whop tracks for you (and what it cannot see)

Whop records every checkout view, purchase, subscription, and trial on its own platform automatically, server-side, with zero configuration. Their docs are explicit: do not track purchases that happen on Whop checkout.

What Whop cannot see is your own funnel. Leads from your landing pages, bookings, registrations, and purchases that happen outside Whop checkout are invisible to Whop's attribution unless you send them. That is what the pixel and the Events API exist for - and without GTM templates, most setups end up as custom HTML tags in the web container and hand-rolled API calls on the server.

The two templates

Browser → Whop Pixel tag → t.whop.tw (page views, light engagement)
Browser → GA4 / Stape Data Tag → sGTM → Whop Events API tag → api.whop.com (conversions)

  • Web tag - loads the Whop pixel and tracks page views, standard events, and custom events
  • Server tag - sends events to POST /api/v1/events with Bearer auth and automatic field mapping

The split matters: the pixel generates its own event IDs and its dedupe behavior against server events is undocumented, so the same action tracked in both containers can double-count. Pixel for page views, server tag for conversions.

The web tag: the pixel without custom HTML

The template recreates the official snippet's stub in sandboxed JavaScript: the timestamped command queue, the scope state, and the script loader. The script loads once regardless of how many tag instances fire, and later fires call the pixel API directly.

You get a dropdown with all seven Whop standard events (lead, schedule, submit_application, contact, complete_registration, view_content, add_to_cart), a custom event field, value and currency, and a customer data table for email, phone, name, and address fields. Permissions are locked to script injection from t.whop.tw and the whop.* globals - a real upgrade over an unrestricted custom HTML tag if you hand containers to clients or teammates.

One sandbox lesson from building it: copyFromWindow throws when the value is a function. You cannot check whether whop.track exists by reading it. The template tracks loaded-state with its own flag and only touches window functions through callInWindow.

The server tag: conversions that survive ad blockers

The server tag reads the incoming event and builds the Whop payload automatically. It understands both the standard GA4 client event model and the Stape Data Tag / Data Client model, including the cookies the Data Tag forwards nested inside its common_cookie object - a detail that is easy to miss and silently costs you attribution data if you only read top-level fields.

Out of the box it maps:

  • Event names: GA4 names auto-map to Whop standard events (page_view and view_item to view_content, generate_lead to lead, sign_up to complete_registration). Unknown names pass through as custom events - Whop forwards custom names under ~34 characters to Meta as custom conversions.
  • Click IDs: gclid, gbraid, wbraid, fbclid, ttclid, msclkid, li_fat_id, rdt_cid, sccid, and twclid from event data, cookies, or the page URL. gclid is also parsed out of the _gcl_aw cookie, and fbc is constructed from fbclid when the Meta cookie is missing.
  • User data: email, phone, name, and address in both GA4 shape (email_address, nested address) and Stape shape (flat fields). Hashed emails are skipped - Whop wants plain values.
  • UTMs, IP, user agent, language, and screen resolution into Whop's context object.

Visitor stitching via the pixel's _wuid cookie

Whop's docs never mention how the pixel identifies visitors. The pixel source does: it stores a visitor ID in a first-party _wuid cookie and sends it with every event. The server template reads that cookie and sends it as user.anonymous_id, which ties your server-side conversions to the same visitor the pixel has been following since their first page view.

This only requires what a first-party sGTM setup already has: the server container running same origin with your site, so the cookie rides along on every request.

Setup

Web container:

  1. Import whop-pixel-web-tag.tpl as a tag template
  2. Create a tag with your business ID (biz_..., from your dashboard URL), event = Page view, trigger = All Pages
  3. Remove any hardcoded Whop snippet so page views are not counted twice

Server container:

  1. Create a Whop API key with the event:create scope
  2. Import whop-events-api-tag.tpl, set the API key and your business ID
  3. Leave the event name on Inherit and fire the tag on your conversion triggers
  4. Pass a stable event ID from the browser so retries deduplicate

Verify at whop.com/dashboard/{biz_id}/pixel - the status turns green once data flows.

Limitations

  • The Events API sits in Whop's beta API surface and may change.
  • Pixel-to-server dedupe is undocumented. Split by event type instead of sending the same event twice.
  • Custom event names max out at 35 characters. Keep them short and stable, and reuse a small set.
  • Whop checkout purchases should never be sent - Whop already records them.

Get the templates

Both templates, setup docs, and the full field mapping are on GitHub under Apache 2.0.

If you run into issues, open a GitHub issue or reach out.

Disclosure: the Stape and Whop links in this post are affiliate links. If you sign up through them I earn a commission at no extra cost to you.