What OpenCourt sends to Meta and Google — and what it never sends
A plain-English breakdown of the conversion data OpenCourt shares with ad platforms, how it protects your customers' privacy, and what stays private.
When you turn on Ad and Conversion Tracking, OpenCourt reports your online sales to the ad platforms you connect — so Meta and Google can see which ads actually bring in paying customers. This page explains exactly what gets sent, and just as importantly, what never does.
The events OpenCourt reports
Four things get reported, and only these:
- A page view — someone visited your club's booking pages (sent from their browser).
- A checkout started — someone reached the payment step (sent from their browser).
- A purchase — someone actually paid for something online. This one is sent from OpenCourt's servers using Meta's Conversions API, not from the customer's browser — so it still arrives even when ad blockers or iOS privacy settings block browser tracking. Your purchase data is the signal that matters most, and server-side delivery is what keeps it reliable.
- A new membership — when someone buys their first membership, a
Subscribeevent is sent alongside the purchase (never instead of it). Renewals, bookings, events, and store sales report a purchase only. So does a presale deposit: a deposit is not a recurring membership yet, so it reportsPurchaseonly —Subscribefires later, if and when the presale converts.
Google gets the same picture: GA4 receives page_view, begin_checkout, and purchase, and Google Ads receives the purchases as offline click conversions.
The value reported is what the customer actually paid
Each purchase carries the net cash captured — the amount after any promo code, pass, or account credit — never the list price. That keeps your ad optimization honest: the platforms learn to find customers based on real revenue, not inflated sticker prices.
Front-desk sales are excluded — on purpose
Sales your staff ring up at the front desk (admin and POS sales) are never sent. A walk-in who paid at the counter didn't come from an online ad, and mixing that revenue in would teach the ad platforms the wrong lessons about which ads work. Only online sales — the ones an ad could plausibly have driven — are reported.
Sales that cost $0 are not reported
If a customer covers a booking entirely with a pass, account credit, or a 100% promo code, no cash is captured — so there is nothing to report, and no event is sent at all. Free events work the same way.
This matters if you run a free-first-session offer: those signups will not appear in Meta or Google as conversions, even though they happened. If free registrations are the goal of a campaign, tell your OpenCourt contact before you launch so we can talk through what your reporting will and won't show.
Refunds do not reverse a reported sale
When you refund a booking or a membership, OpenCourt does not send a reversal to the ad platforms. The original purchase stays in Meta and Google as reported revenue.
If you refund often — weather cancellations, for example — the revenue your ad platforms show will read higher than the revenue you actually kept, and your return on ad spend will look better than it is. Reconcile against OpenCourt's own reports, never against Meta's numbers alone.
Purchases made in the OpenCourt app
The OpenCourt customer app runs the same booking site inside a native shell. Inside the app, OpenCourt deliberately does not run the browser pixel — firing a tracking pixel inside an iOS app without Apple's tracking permission prompt is a policy exposure we will not take on your behalf.
In-app purchases are still reported. They go out server-side through the Conversions API exactly like web purchases, so no sale is lost. What is missing is the browser-side context: the page views, the checkout-started events, and the click identifiers Meta uses to tie a sale back to one specific ad. So an in-app purchase is more likely to be counted as revenue without being credited to the ad that caused it.
What travels with each purchase
A few extra fields go along with every purchase so the platforms (and you) can tell sale types apart:
| Field | What it contains |
|---|---|
content_category | Which kind of sale it was — one of: space (a court, bay or lane booking), event, day_fee, add_on (equipment rental), membership, membership_presale (a deposit taken before the club opens), pass_package (a punch card or lesson bundle), membership_renewal, store, coach_lesson, gift_card. A charge OpenCourt cannot classify — a few legacy and manually entered charge types — is sent without this field rather than in a catch-all bucket |
content_categories | Every category in the order, comma-joined in the same order as above (membership,space). content_category can only name one thing, so use this one with a contains rule to build "any order that included a membership" |
event_type | Present whenever the purchase is attached to something on your schedule: OpenPlay, OpenGame, League, Clinic, Tournament, Lesson or Other. This includes space bookings (usually OpenGame) and coach lessons (Lesson) — it is not limited to the event category |
content_name | The name of what was bought — the event's name, the membership plan, the product, the rented equipment, or (for a booking) your own space category or space name. When none of those can be resolved it falls back to the charge's own description, so this field is never empty |
content_ids / contents / num_items | The itemized contents of the order |
is_new_customer | Whether this was the person's first purchase at your club |
membership_status | A coarse label only: member, non-member, or lapsed |
Customer identifiers are hashed before they leave OpenCourt
For an ad platform to credit a sale to an ad, it needs to recognize which of its users made the purchase. OpenCourt handles this with one-way hashing (SHA-256): the customer's email, phone number, and a per-club customer ID are scrambled into a fingerprint before sending. Meta or Google can match that fingerprint against the hashes of their own logged-in users — but the raw email and phone number are never transmitted, and a hash can't be reversed back into them. You get accurate ad attribution without handing over your customer list in readable form.
Your responsibilities
When you turn the feature on, OpenCourt shows a data-sharing disclosure that you accept — that covers OpenCourt's side of the sending. Your club remains responsible for its own privacy disclosures: your privacy policy should mention ad-platform data sharing, and your region may require a cookie or consent banner (for example under GDPR in Europe or CPRA in California). This isn't legal advice — if you're unsure what your region requires, check with a legal advisor.
Related articles
- Set up Meta conversion tracking
- Set up GA4 conversion tracking
- Set up Google Ads conversion tracking
- Understand your conversion data — how to use these fields for reporting and optimization
- Monitor and troubleshoot
Send a test event
Use OpenCourt's built-in test console to prove your Meta connection works before real ad money depends on it.
Understand your conversion data in Meta
How to read OpenCourt's Purchase and Subscribe events in Meta, break out sale types with content_category, and set realistic attribution expectations.