TLDR: If your Halo Effect pulls all-time orders without a time fence, you're not measuring event impact — you're measuring your entire customer history. Fix it.

the setup

I've been building a webinar analytics dashboard — a full analytics dashboard for a supplement brand — to measure the real revenue impact of their live webinars.

One of the most interesting metrics in the whole thing is the Halo Effect.

The idea: not every attendee who buys uses the event discount code. Some just… buy. They were in the room, the webinar moved them, and they went to the store and purchased at full price. That's the halo — registrants who bought without an event code. Real lift. Just harder to see.

the naive version

The first implementation was simple enough.

Pull all Shopify orders where the buyer's email matched a registered attendee. Drop any order that used an event discount code (those belong in "core sales"). Everything left = halo.

Seemed right.

the wall

Except we were pulling all-time Shopify exports.

No time fence. Which meant a customer who bought nine months before the event was still showing up as a halo order. That's not halo. That's just a customer who happened to also register for a webinar months later.

The fix: scope halo to −12 hours before event start through +14 days after. If the order doesn't land in that window, it's not event-attributed. Period.

This one is largely preventative — it stops future all-time data dumps from bleeding noise into the metric. On our reference event it may not have shifted the count much. But without it, every new event we run would quietly accumulate more garbage in the window.

the second bug (found while I was in there)

Once I was auditing the query, I noticed something else.

Recharge auto-rebills were counting as halo.

The supplement brand uses Recharge (their subscription-billing tool, bolted onto Shopify) for monthly supplement subscriptions. When someone's existing subscription auto-renewed during the event window, our query flagged it as an event-influenced purchase.

It wasn't. It was a robot collecting a scheduled payment. The webinar had nothing to do with it.

Shopify exports tag these: Subscription Recurring Order = auto-rebill. Subscription First Order = a brand-new subscription (that one's real — keep it).

The fix: drop any order tagged Subscription Recurring Order from the halo loop before counting.

On our reference event, this one moved the needle.

34 halo orders → 29. Five orders that were never actually halo.

why this matters to me

On the 6/02 debrief call, a strategic advisor in the room said something I keep thinking about.

"Multi-touch attribution gets very fuzzy very quickly."

He was warning about broader noise in the numbers — Amazon spikes, D2C overlap, the usual chaos. But the principle holds everywhere.

Sloppy attribution windows don't just produce wrong numbers. They produce confidently wrong numbers. Nobody questions a clean-looking total.

The discipline isn't to measure everything. It's to measure the right slice, precisely.

Every halo order that survives the query should be defensible: this person registered for the event, this purchase happened within 14 days, and it was not an automatic renewal.

That's a number I can stand behind.

P.S. The two commits that did the work: Time-scope Halo Effect to the event window and Exclude Recharge recurring rebills from Halo Effect. Two small changes. One honest metric.