How to Track Bold Subscriptions Conversions in Meta, Google Ads and GA4

I see the same pattern on most Bold stores: Shopify shows a big month, Meta shows a fraction of it, GA4 lands somewhere between, and someone decides the pixel is broken. Usually it isn't. It reports what it can see, which is new checkouts. Most of the gap is renewals that were never sent anywhere.

You don't want every renewal training your campaigns. But you should decide that on purpose, and refunds should flow back so platforms aren't bidding on money you returned.

How is a Bold Subscriptions first order tracked on Shopify today?

Exactly like a normal Shopify order, on the current version of the app. Bold's help center says the product "is designed to work with the standard Shopify Checkout." Subscriptions are sold through Shopify selling plans, and after purchase Shopify creates a subscription contract that Bold manages.

Because the first order goes through Shopify's checkout, Shopify's customer events fire. The checkout_completed event triggers once per checkout, normally on the Thank you page, or on the first upsell page if you run post-purchase offers. Any pixel subscribed through Customer events (Meta's app, Google & YouTube, or a custom pixel feeding GTM) gets it.

Shopify's Web Pixels API reference lists two fields worth wiring up (both need Checkout Extensibility):

• sellingPlanAllocation on each line item. If it's non-null, that line was bought on a subscription plan. This is how you tell "subscribe and save" from a one-off purchase in the same cart.
• isFirstOrder on the order's customer. Useful for splitting genuinely new customers from existing buyers who added a subscription.

One version check first. Older Bold setups (Bold Subscriptions V1) ran on Bold's legacy checkout, and Bold has been migrating those merchants to "Bold Subscriptions for Shopify Checkout." On the legacy version the first-order flow is different, so confirm which one you're on before building anything.

Why don't Bold renewal orders show up in Meta, Google Ads or GA4?

Because nobody is on your website when a renewal happens. On the billing date, Bold charges the stored payment method against the Shopify subscription contract and an order gets created in your admin. No storefront page loads, no Thank you page renders, no customer event fires. Browser pixels, including Shopify's Web Pixels, only see what happens in a browser.

Bold's Shopify Flow guide for tagging recurring orders confirms it: it uses the Order created trigger with a condition on the order's app name including "Bold Subscriptions." Renewals are real Shopify orders, created by the app, not by a shopper.

What should you send for first orders versus renewals?

The first subscription order is your acquisition conversion, so it goes to every platform as a Purchase with value. Renewals are retention. They belong in your revenue reporting, and they rarely belong in bidding. Here's the mapping I use as a default:

Event	Meta (Pixel + Conversions API)	Google Ads	GA4
First subscription order	Purchase with value, browser and server, shared event_id	Primary purchase conversion with enhanced conversions	purchase with transaction_id, key event
Renewal order	Custom event (for example SubscriptionRenewal), action_source: "system_generated", server only	Separate conversion action set to Secondary, or skip	Measurement Protocol event, reused client_id
Refund on first order	Nothing automatic; fix value at the source	Retraction or restatement by order ID	refund event with the same transaction_id
Subscription cancelled	Audience signal only, not a negative conversion	Not a conversion adjustment by itself	Optional custom event for churn reporting

A few opinions behind that table.

Don't send renewals as Purchase to Meta. If month seven of an existing subscriber lands as a Purchase, Meta credits whatever ad that person last touched and learns that showing ads to current customers "works." Meta's own Conversions API docs define system_generated as a conversion that happened automatically, and their example is literally a subscription renewal on auto-pay. Use it, with a non-standard event name, and keep it out of your optimization events.

Make the first order carry the lifetime story. A $29 first box worth $180 over its life loses auctions to a $60 one-off order if you report face value. On Meta, pass predicted_ltv, which Meta describes as the predicted lifetime value of a conversion. On Google Ads, send a value blending first-order revenue with expected retention, calculated from your own cohort data and refreshed quarterly. A guessed multiplier is worse than face value.

In GA4, decide whether renewals are purchase. Sending them as purchase with an order_type parameter keeps revenue reports complete, but if you import GA4's purchase into Google Ads, renewals would start counting there too. In that case use a separate event name. The logic mirrors subscription conversion tracking for SaaS.

Google Ads adds a hard limit: click conversions only count inside the conversion action's window, which tops out at 90 days. A month-eight renewal can't be credited to the click that started it, which is one more reason to put lifetime value on the first order.

Which Bold and Shopify webhooks tell you a renewal happened?

You have two sources, and I'd use both. Bold's Subscriptions v2 developer guide lists its webhook topics, registered through the API with a callback URL and a shared secret. Every delivery carries an x-bold-signature header, a SHA-256 hash of the payload and your secret, which you verify before trusting anything in it. The topics that matter for tracking:

• subscription_created: a new subscription, fired alongside the first order.
• subscription_order_created: fires on every processed subscription order, first one included, so you classify it yourself.
• subscription_cancelled, subscription_paused, subscription_payment_failed: lifecycle and churn signals.

On the Shopify side, the standard orders/create, orders/paid and refunds/create webhooks give you the money. Shopify's subscription contract and billing attempt webhooks require the read_own_subscription_contracts scope, which only covers contracts your own app owns, so in practice those go to Bold, not to your tracking pipeline.

To classify an order reliably:

1. Receive orders/paid from Shopify. Paid, not created, so you don't send conversions for orders that fail payment.
2. Check whether any line item has a selling plan. No selling plan means a normal one-time order; let your regular purchase flow handle it.
3. Check the order's app. Bold's own Flow guide identifies recurring orders by an app name including "Bold Subscriptions," while first orders come through the Online Store channel.
4. Cross-check against Bold's webhooks: if subscription_created fired for this order, it's a first order. If the subscription already existed, it's a renewal.
5. Store the result against the Shopify order ID for later refunds.

How do you handle cancellations and refunds?

Treat them as different things, because they are. A cancellation stops future renewals but doesn't undo revenue you collected, so it should never retract a first-order conversion. A refund gives money back, and that's what ad platforms need to hear. Bold's compatibility notes make the split explicit: refunding a subscription order does not cancel future orders.

For Google Ads, refunds go back as conversion adjustments: a retraction removes the conversion, a restatement changes its value. Match on the order ID you sent as the transaction ID, upload at least 24 hours after the conversion and within 54 days. Google says adjustments within 7 days of the conversion are the ones bidding can use, so run a nightly job. Partial refund? Restate to the net value.

For GA4, send a refund event with the same transaction_id through the Measurement Protocol. For Meta, the cleanest lever is upstream: report honest first-order values, and use subscription_cancelled to feed exclusion or win-back audiences.

Why does first-party server-side tracking fix the Bold renewal gap?

Because renewals happen on a server, and only a server can report them. No pixel can see an event that never touches a browser.

For a Bold store, server-side Google Tag Manager runs on your own subdomain, something like data.yourstore.com. The first order's checkout_completed goes from the browser to that container, which forwards it to Meta's Conversions API, Google Ads and GA4 using the Shopify order ID as the event_id. The browser pixel sends the same ID, so Meta counts the order once whichever copy arrives first. At the same moment the container records the identifiers that will matter months later: the GA4 client_id, Meta's _fbp and _fbc, the click ID, and the customer's email and phone, normalized and SHA-256 hashed.

Then the renewals. Bold's and Shopify's webhooks hit the same server. It classifies the order, looks up the identifiers stored at the first purchase, and sends a system_generated renewal to Meta with hashed customer data so it matches the right person, a Measurement Protocol event to GA4 under the original client_id, and nothing to Google Ads bidding unless you've chosen otherwise. Refunds follow the same path as adjustments.

What changes versus the default setup:

• Renewal revenue exists in your measurement instead of only in Shopify's admin, tied to the customer who started it.
• First orders stop leaking. Ad blockers and Safari's cookie limits chip away at browser-only Purchase events; server copies fill the gaps. See Meta Pixel vs Conversions API for why you want both, deduplicated.
• Match quality goes up on the events that train bidding, because hashed first-party email and phone ride along on every server event.

More on the mechanics: Shopify server-side tracking, and the same pattern for another app in Recharge conversion tracking.

What do US privacy rules change for subscription tracking?

Mostly they change what you send for people who opted out, and renewals make that harder because the opt-out happened months ago. Under CCPA/CPRA and the other state laws, sending customer data to ad platforms for cross-context behavioral advertising is "sharing," and customers can tell you to stop, including through Global Privacy Control.

The practical rule: capture the opt-out state at the first order, store it with the customer, and check it before every renewal event. For opted-out customers, don't send renewals to ad platforms, or send them with Meta's Limited Data Use and Google's restricted data processing applied. If someone opts out later through your Do Not Sell or Share link, update the stored flag. EU subscribers still fall under GDPR consent, another reason to keep the state on the customer record, not in a long-expired browser cookie.

I'm a tracking engineer, not a lawyer. If your products touch health or wellness, get counsel involved.

Frequently asked questions

Does Bold Subscriptions use Shopify's checkout or its own?

Current installs, "Bold Subscriptions for Shopify Checkout," use Shopify's standard checkout. Older V1 setups ran on Bold's legacy checkout, and Bold has been migrating those stores, so check which version you have.

Why does Meta show far less revenue than Shopify on my subscription store?

Mostly because Bold creates renewals in the background and no browser pixel sees them. The rest is normal browser loss on first orders.

Should Google Ads bid on renewal orders?

Usually not. Renewals come from existing customers and can't be tied to clicks older than the 90-day maximum window. Put lifetime value on the first order and track renewals as a Secondary action if you want them visible.

Which Bold webhook fires on a renewal?

subscription_order_created fires every time a subscription order is processed, including the first one. Pair it with subscription_created or the Shopify order's app and selling plan to tell first orders from renewals.

What happens to my conversions when a subscriber cancels?

Nothing should, by default. A cancellation stops future revenue but doesn't refund past orders. Only refunds should trigger Google Ads retractions or restatements and GA4 refund events.

Can GA4 attribute a renewal to the original campaign?

Not as a session conversion, since there's no session. If you reuse the original client_id in the Measurement Protocol event, the renewal sits on the same user, so user-level acquisition reports can still connect it to how they first arrived.

If your Bold store's numbers don't line up, we can rebuild the whole thing on first-party server-side tracking: first orders deduplicated across browser and server, renewals and refunds sent from webhooks, opt-outs respected. Setups like this typically land around 98% conversion accuracy, and we guarantee 95% or better. Tell us how your store is set up and we'll show you where the gap is.