Boop Body: repairing Shopify conversion tracking before judging the funnel

Boop Body's Shopify store was logging signup events that couldn't be tied to a named person. That meant the funnel the store reported wasn't the funnel it actually had. This was a Shopify conversion tracking repair, not a signup form problem.

Boop Body is an athleisure brand based in Pakistan that sells on Shopify. Its buyers mostly shop on their phones, which is why SMS and WhatsApp matter so much to how the brand reaches them. The store's own analytics back this up. In the measured period before the fix, 91.8% of visits came from screens under 768 pixels wide.

How did we find the tracking problem?

The founder signed up through the store's popup using his own details, then couldn't find himself in the customer data platform. A customer data platform, or CDP, is the tool that connects every event a person triggers to a single profile for that person.

That one test changed the question. The funnel looked weak, but was the store failing to capture people, or failing to report the people it had already captured?

Why does the difference matter for a small store?

For a small store, the answer decides where the next dollar goes. Replacing a signup form that already works won't fix a broken identity pipeline. An identity pipeline is the chain of systems that turns a filled in form into a named customer profile. So the first job was to follow one real signup through every system it touched.

Before we changed anything a shopper sees, we followed one real signup through every system it was supposed to reach. We compared Shopify customer records, event data and the theme that was actually live on the store. We read how the popup and the newsletter form collect contact details and pass them to the CDP. And instead of trusting that the main copy of the code matched the store, we pulled the live file itself.

What was the core tracking defect?

The core defect was the link between a signup event and a named person. A signup event could fire before anyone had been identified, so the event had no one to attach to.

There was a second problem too. The popup's reader had to reach the email field inside the shadow DOM of Shopify Forms. Shadow DOM is a browser feature that hides part of a page from ordinary scripts, which is why the email wasn't being picked up reliably. The phone fields were already handled correctly.

How was the identity pipeline fixed?

The fix made the order explicit: identify the person first, then record the signup. Email became the preferred way to identify someone, with phone as the fallback. That setup suits how this store captures people, since so many of its shoppers sign up on their phones.

Workflow: Signup capture → Identify then track → Connected profiles → Funnel measurement.

We fixed the two places where shoppers hand over their details: the signup popup and the footer form. Before making any change, we saved a copy of the theme file and wrote down how to roll it back. After the update, we pulled the live file again to confirm the new identity calls were actually there.

Next, we recovered the signups the store had already collected by replaying past Shopify captures into the CDP. Wherever possible, we matched those records to profiles the CDP already had for visitors it hadn't named yet, instead of creating loose new ones. That way, old browsing history got reconnected to the contact details the store already held.

The identity calls also survived the later theme change. That matters, because a conversion redesign should never quietly undo the tracking repair the team needs to measure whether the redesign worked.

The next phase improved the shopping experience using only what Shopify already provides: native Liquid, CSS and product metafields. Liquid is Shopify's own template language, and metafields are extra fields you can attach to a product. We didn't add a single new paid app.

The work covered product information, fit help and the cart, and all of it stayed inside the store's existing theme.

The founder asked to see an unpublished preview before anything went live, so that's where we pushed the conversion work. We then checked that the push hadn't touched the live theme at all. The merchant kept control over when to publish and picked the date themselves.

That split worked well for both sides. The work could be judged as a real, working storefront, while the business still owned the timing.

After the conversion work, we ran an independent impact review. The order sample was small and the exact publish time was unclear, so we couldn't say for certain whether conversions went up. Some product features also depend on content the merchant types in themselves, which means code alone can't prove what every shopper actually saw.

The strongest result is the repaired link between signups and named customers. Past captures were recovered, and the identity calls were still in place after the later theme work. The conversion pass is a separate deliverable that the client released on their own terms. Keeping the two apart lets the merchant act on the evidence it actually has, because a tracking repair on its own isn't proof of more sales.