3.19x purchase inflation fixed for Writeless with server-side Stripe tracking | Sementa

Writeless is an AI writing tool built in Bubble, sold as Stripe subscriptions and advertised only on Meta. Before the rebuild, Meta Events Manager showed 2,256 purchases in three weeks against 708 new subscriptions in Stripe. Ads were being optimized on renewals and duplicates.

Sementa rebuilt the tracking server-side on Stape. Purchases now come from Stripe itself, one event per new subscription, with the browser data from sign-up stitched back on. In the first full week, GA4, Meta, and Stripe agreed on every purchase.

The old setup forwarded every Stripe event to Meta and GA4 as a purchase. Renewals, plan changes, and Stripe's own duplicate at checkout were all counted. From August 1 to 22, Meta received 2,256 purchases. Stripe had 708 new subscriptions and 2,790 renewals in the same period. 1,548 of the purchases Meta optimized on were not sales, and the real cost per purchase was about three times what Ads Manager showed.

GA4 had the same problem from a different angle: 1,406 purchase events plus four browser-side purchase events with no revenue, all against the same 708 subscriptions.

Sign-ups were inflated too. From July to August 23, GA4 recorded 3.8 sign_up events for every user who signed up, so its registration numbers were as unreliable as its purchases.

A third problem sat on the landing page. The A/B testing tool rewrote the address the moment the page loaded and dropped everything after the question mark, before the Meta pixel and Google Tag Manager ran. Meta's click ID (fbclid) and every UTM parameter were gone. Only 4 percent of events carried a click ID.

A server container logs every request it sends to Meta and GA4. Sementa used those logs as the source of truth, not the platform dashboards.

On September 20, the sign-up push in Bubble was moved into the Google login button's workflow. The logs showed registrations to Meta falling from 18.3 to 11.8 per hour, starting the exact hour the change went live: email and password sign-ups had stopped sending. The same logs showed duplicates had dropped from 10.1 to 0.8 percent, which looked like an improvement and hid the loss. The fix went live two days later, sending on both sign-up paths once per account. On October 1 to 2, the logs show 459 registrations to Meta, all accepted, with no duplicates.

The logs also gave field coverage per event (how many carry email, click ID, IP) and how many purchases found their sign-up session in the store, without depending on what Meta chooses to display.

• Purchases from Stripe, not the browser. A Stripe webhook goes to a custom client in the server container. It fires only on the first paid invoice of a new subscription. Renewals, plan changes, and failed payments are received and ignored.
• Browser identity stitched onto server purchases. At sign-up, the server stores the visitor's session (click ID, browser ID, GA4 client ID, IP, user agent) in Stape's Data Store under the hashed email. When Stripe reports the payment, the email is looked up, and the purchase reaches Meta and GA4 with the identity of the visitor who clicked the ad.
• A separate new-customer event. Purchase stays the optimization event. PurchaseNewCustomer fires once per customer, ever. New customers run at half of purchases, so real cost per new customer is about twice the cost per purchase, and a custom metric in Ads Manager now shows it directly.
• The click ID restored. A tag that runs before everything else reads the original landing address, which the browser keeps, writes the click ID cookie the pixel would have written, and hands GA4 the original URL so the UTM parameters survive.
• The old tags removed: browser purchase events, an InitiateCheckout event that no longer matched real checkouts, and the old Stape forwarding.

Verified September 3 to 9, one week after go-live:

• GA4: 338 purchases, Stripe: 338. Revenue 12,875.17 USD in both. 169 new customers in both. Every one of the seven days matched.
• Meta: 357 Purchase events, Stripe: 357 paid subscription invoices (counted in the ad account's time zone, at the moment of payment).
• New customers held at 0.50 per purchase in both Stripe and GA4.

Verified September 26 to October 2, after sign-up tracking was reworked:

• Sign-ups: 1,756 new accounts in Bubble, 1,637 sign-ups in GA4, 93 percent. Between 93 and 95 percent every day.
• Meta reports 46.9 percent more registrations with the server events than the pixel would deliver on its own.
• Every sign-up sent to Meta on October 1 and 2 carries email, browser ID, IP, and user agent. 27 percent carry the click ID, up from 4 percent.

If the dashboard and the bank disagree, believe the bank and find out what the dashboard is counting. A webhook that forwards everything is the most common cause of numbers that look good and are wrong. And check the time zone before concluding anything: the same week of invoices counted 338 in New York time and 357 in Gulf time.

By setting up server-side tracking with Stape, you can:

• Stitch browser identity to server-side purchases. Use Stape's Data Store to capture click IDs, GA4 client IDs, and session data at sign-up, then retrieve them when Stripe confirms payment, so matched purchase events can carry the attribution context of the original ad click, even when payment arrives later.
• Count only real new subscriptions. Filter Stripe webhooks at the server level to fire purchase events on first paid invoices only, keeping renewals, plan changes, and checkout duplicates out of your conversion data and off your optimization signals.
• Make new-customer acquisition cost directly visible. Fire a dedicated PurchaseNewCustomer event alongside your standard purchase event to separate first-time buyers from returning ones and read the true CAC in Ads Manager without estimating it from cost per purchase.
• Use server logs as your source of truth. Monitor outgoing event counts, field coverage, and duplicate rates in real time, independent of what any platform dashboard shows, to catch implementation issues the moment they happen rather than discovering them in delayed platform reports.