Fixing broken ad attribution across a disconnected Lovable and Shopify customer journey | Obsidian Digital
Juan Felipe Simonsen Bagley
AuthorKey takeaways
Sengesnedkeren is a Danish manufacturer and e-commerce retailer of beds and mattresses. Customers configure a bed in a product configurator, which prices it and creates the order. Average order values run in the thousands of kroner, so a single lost purchase is critical.
Their setup is what makes this case interesting. The storefront is built using Lovable, an AI app builder, as a React single-page app on “sengesnedkeren.dk”. The checkout runs on Shopify at shop.sengesnedkeren.dk and is connected through the Lovable extension. Two surfaces, two technologies, one customer journey.
The project was handled by Obsidian Digital, a Stape top partner agency, which worked directly with Sengesnedkeren to diagnose the tracking gaps and implement the full server-side setup described below.
Challenge: disconnected tracking across a headless storefront and Shopify checkout
The starting point had no Google Tag Manager and no dataLayer. Platform tags were hardcoded into the React bundle, so every measurement change was a code deployment, and nothing could be verified without reading the source.
The harder problems came from the architecture, and this is the part that does not happen on a native Shopify theme:
- The storefront never spoke to Shopify. A Lovable app has no `window.Shopify`. It cannot read Shopify's Customer Privacy API, and Shopify's checkout cannot read the storefront's state. The two halves of the journey were not connected.
- Ad-click identity never reached the purchase, and this was the expensive one. On the storefront, nothing persisted the click. There was no dataLayer and no deliberate capture of click IDs or campaign parameters, so a customer who arrived from a Meta or Google ad left no durable trace of which ad it was. At the checkout, purchases were reported by Shopify's native Meta and Google sales channel apps, which build their payload from Shopify's own order data. Those apps have no access to what happened on a Lovable storefront.
- Orders were landing, and the ad platforms were crediting far fewer of them than the business was actually generating.
- Product identifiers matched nothing. Item IDs arrived as Shopify GIDs (`gid://shopify/Product/...`), while their Merchant Center feed is built by a custom Supabase function in an entirely different format.
- Purchases died with the session. Orders are created as Shopify draft orders by the configurator, so `cart_token` is null and the standard Shopify tracking path does not drive them. Any customer who paid but never reached the thank-you page was simply not counted. Their traffic skews toward exactly those journeys: in-app browsers, payment gateways etc.
Solution: a server-side tracking setup with power-ups
The client needed a server container, a first-party endpoint, a way into a locked-down Shopify checkout, and a database. Stape has all four, which means one vendor instead of four.
- First-party endpoint and Custom Loader on `sst.sengesnedkeren.dk`, served from an obfuscated path rather than `/gtm.js`. Resilient to blockers, and first-party for cookie lifetime.
- Cookie Keeper, root-scoped to `.sengesnedkeren.dk`. This is what lets cookies set on the Lovable storefront be read by GTM inside the Shopify checkout, plus ITP lifetime extension beyond Safari's 7-day cap.
- Stape's Shopify app, which delivers checkout Customer Events into the container.
- Stape Store, a database inside the server container. It was used for two jobs: a purchase ledger that dedupes the browser path against the webhook path, and a payload logger for QA. No external Firestore or Supabase to provision, authenticate and pay for.
- Logs, which give receipt-level proof of what the server actually sent. Every claim in this case study was verified there or in the Store, not in a browser debugger.
- Request Delay, which solved a problem that otherwise required rebuilding both sending paths. More on this below.
Implementation: bridging consent, identity, and orders across two systems
With consent, click identity, and order data now flowing across both platforms, four pieces held the setup together.
- A consent bridge across two technologies. Cookiebot runs on the storefront. A GTM tag loads Shopify's consent-tracking API into the headless app, waits for it, then syncs the decision into Shopify's Customer Privacy API with the headless parameters. The checkout inherits the decision because both surfaces share the root domain. A cookie yes on the storefront is now a cookie yes at payment.
- Full-funnel server-side measurement to GA4, Google Ads, Meta CAPI and TikTok Events API, with enhanced conversions hashed server-side and browser-to-CAPI deduplication on a shared event ID.
- A webhook safety net. A Shopify `orders/create` webhook builds the purchase from the order itself when the browser never reported it, using identity the storefront persists into order attributes. Since the standard cart-token stitch is unavailable on a draft-order flow, identity comes from those attributes instead.
- A deduplication ledger, and Request Delay to make it sound. A webhook fires when the order is created, which is before the customer reaches the thank-you page. So the two paths race, and in this store the race is real rather than theoretical. We hold the webhook for 15 minutes with Stape's Request Delay. The browser path always lands first and writes to the ledger, and the webhook then finds it and stands down.
Results: accurate ad attribution with fully recovered purchase data
Orders now reach Meta and Google Ads with the click that produced them. This is the change that matters commercially. Ad-click identity is captured on the storefront, persisted so it survives the customer leaving and coming back, carried across the domain switch, and written onto the order itself.
The purchase is then assembled server-side from that identity rather than by an app that never saw the storefront.
Consenting customers are now reported as consenting. Checkout hits to Google moved from `gcs=G100`, consent denied, to `gcs=G111`. Before, every customer who accepted everything was reported to GA4 and Google Ads as a refusal.
Product data now matches the client's own feed. Google Ads can match at item level instead of failing on every row.
Purchases no longer depend on the customer reaching the thank-you page. The order itself is the fallback, deduplicated against the browser path so it can only ever add a missing purchase, never a second copy of one already counted.
Next steps
Now that the client is on the Business plan, the team will evaluate Monitoring with alerts to catch broken tags before they affect monthly reporting.
Why AI-built storefronts create new tracking challenges for agencies
AI app builders are producing a category of site that did not exist a few years ago. Lovable, and tools like it, make it fast to ship a storefront and easy to end up with a headless architecture nobody planned for. The tracking failure modes are specific, repeatable, and largely invisible until revenue reporting disagrees with the ad platforms.
For agencies, this changes what a discovery call needs to cover. A client showing up with an AI-built storefront can no longer be scoped like a standard Shopify theme project – the tracking work is bigger, and it's easy to underquote if the architecture isn't audited first. Asking early whether the storefront and checkout run on separate platforms, and whether they share a domain, can save an agency from finding out mid-project that half the plumbing has to be rebuilt.
Two pieces of advice for anyone doing this on a headless or AI-built storefront:
- Treat consent as an integration, not a banner. On a single Shopify theme a CMP is a script. Across a headless storefront and a locked-down checkout it is a data handoff between two systems, and it needs to be designed and tested as one.
- Verify from server-side receipts. Browser debuggers, preview modes and helper extensions do not tell the whole story.
On a fixed-scope project, that structural complexity is exactly what has to be solved through configuration rather than custom engineering – which is why Obsidian Digital points to two specific Stape features as the deciding factor:
“We would recommend Stape, and the specific reason is Request Delay and Stape Store. Both let us solve structural problems with configuration where the alternative was re-engineering both sending paths. On a fixed-scope project, that difference is the project.”
Why choose Stape
For a storefront and checkout split across two technologies and domains, Stape gave Obsidian Digital everything needed to bridge the gap:
- Bridge consent and tracking data across disconnected platforms, so a headless storefront and a separate checkout domain can share the same cookie lifetime and privacy decisions instead of losing them at the handoff.
- Recover purchases the browser never reported, using a webhook fallback paired with Request Delay and Stape Store to dedupe automatically – so no order is missed and none is double-counted.
- Route events server-side through a first-party, obfuscated endpoint with Custom Loader, making tracking more resistant to ad blockers and browser restrictions that would otherwise cut into your conversion data.
- Verify every claim with receipt-level Logs, instead of relying on browser debuggers or preview modes that don't show what the server actually sent.
Comments