Oscar Fong

Who could see the numbers before?

It started as a canvas file on one machine. It now sits inside the planner app the team already works in and reads Meta live, so anyone on the team can open it. A range switch covers the last 7, 14, 30, 60 or 90 days, a refresh button pulls the latest numbers, results are cached for ten minutes, and the Meta access key never reaches the browser.

How can one purchase count twice?

Meta returns purchases under several aliased action types that carry the same value: purchase and omni_purchase are the same event. Add them together, which is the obvious thing to do, and purchases land twice.

How does it count each purchase once?

Take the first alias that exists and never add them up. It is a few lines of logic and a comment explaining why they have to stay that way, because the next person to touch that file will want to sum them.

Why does counting twice cost money?

Ad budgets get judged against a return target. Sum the aliases and the reported value climbs with the count, so ads that are losing money can look like they are paying for themselves, and the budget keeps flowing to them.

What does the team see?

It labels its figures as Meta-reported and not Shopify-verified. Under the headline numbers sit the daily trend, the return from each campaign, and every ad on its own row.

The first version also flagged ads to scale, fix or watch by rule. The same day, I replaced those flags with a dated written review that sorts the ads into what to scale, hold, fix or cut, and what is too early to judge, with a playbook for the next ad. The numbers above it stay live.

Before and after

The filter that got the count wrong

Shoppers filtering by colour were told there were 9 pink products. There were 128. The colour and flower filters ran after the catalogue had already been split into pages, so a page showed a handful of matches, or none, and the count was wrong everywhere.

They now use Shopify’s native tag URLs, so filtering happens first, on the server, and counts, pages and price sorting all agree. Along the way, four flower filters turned out to be pointing at tag names that didn’t exist.

The performance pass

A 68 MB hero video was sitting in the theme, referenced nowhere a shopper would ever load it. Predictive search never fired, because its key handler built the debounced search and then never called it. Product recommendations fetched 30 items to show at most 10; fetching only what is shown cut that payload by 50–70% on scroll.

Checkout, 14 weeks before and after launch

Checkout itself runs on Shopify’s own pages, so this is what happened after launch rather than a result the visual shell can claim on its own.

Scope, honestly

The rebuild was a team effort. My phase was the visual shell for the home, collection and product pages, and the team built the SEO and structured data, the cart form and the launch on top of it. I would rather you heard that here than in an interview.

What the audit found

Tracking switched off on live emails that were earning revenue. Two flows still named “Draft” were sending. An A/B test was split 100/0, with identical subject lines on both arms, so it could not tell the team anything.

And one that mattered more: the old recovery flow carried two identical “no email in the last 14 days” conditions. It was quietly keeping the most engaged buyers, the ones hearing from the brand most, out of the highest-intent flow. I removed it and moved frequency control to Smart Sending.

The rebuild

Four flows, from scratch. Abandoned cart reconnects after an hour with no discount, offers 10% a day later, then sends a last call two days after that, and stops the moment someone orders. Abandoned checkout moves faster: 30 minutes, then 12% the next day. The welcome series runs three emails. A returning customer gets an email the moment they order again, and a second ten days later unless they have already come back.

What changed

The bigger finding

A year-on-year analysis showed new-customer orders down 19.6% while repeat orders grew 3.5%. Revenue wasn’t falling because loyal customers were leaving. Fewer new ones were arriving. That reframed the decline as an acquisition problem and set the plan for the second half of the year.

How it works

Open the file and the email renders the way it will send. Click any copy to edit it in place. When the edits are done, one button exports them for me to action. Reviewers never need access to Klaviyo.

From studio to Klaviyo

I used it to build the new abandoned cart and abandoned checkout flows. Once an email is signed off, the studio’s build step turns it into Klaviyo templates and creates the flow through Klaviyo’s API, with every email set to draft. A later copy change takes the same route: the template is updated and swapped into the flow, so nothing is rebuilt by hand. Nothing goes live until it has been approved and switched on manually.

Why it exists

Reviewing inside Klaviyo happens after the build, which is the most expensive moment to change your mind. With the studio, copy and layout are signed off first, and the email arrives in Klaviyo finished.