Analytics for Event-Driven Ecommerce: What Breaks When Every Conversion Lands in One Hour

Most ecommerce analytics assumes conversions arrive as a reasonably continuous stream. Daily volume fluctuates, there's weekly seasonality, promotions create bumps, but underneath it all you have a process you can sample from and reason about statistically.

Some businesses don't work that way. Their revenue arrives in short, scheduled bursts, and between bursts almost nothing happens. Ticketed events. Product drops. Crowdfunding campaigns. And UK prize competition operators, where a two-week competition can generate a large share of its total revenue in the final hour before the draw closes.

That traffic shape breaks several standard analytical approaches in ways that aren't immediately obvious, and produces some genuinely interesting measurement problems.

The shape of the data

Start with what the distribution actually looks like, because it's unusual.

Plot entries against time for a typical competition and you get a small spike at launch, a long shallow trough, and then a violent exponential ramp in the closing hours. Depending on the operator and the prize, something like ten times normal traffic in the final period is routine.

Two consequences follow. First, any daily-granularity metric is close to meaningless. Averaging across a competition cycle hides the only part of the cycle that matters. Second, most of your data points cluster into a tiny fraction of the total time window, which affects everything downstream from load testing to significance testing.

If you're building reporting for a business like this, hourly granularity is the minimum and minute-level matters for the closing window.

Why attribution windows mislead

Here's where it gets genuinely tricky.

A customer sees a Meta ad for a competition on day two. They click, browse, don't buy. They see two more ads, get three emails and an SMS over the following twelve days. They buy in the final hour, on mobile, having arrived from a direct visit prompted by the SMS.

Standard last-click attribution credits the SMS. Standard 7-day click attribution in the ad platform may credit nothing, because the original click falls outside the window. The Meta interface will report its own version, which typically credits the platform generously. None of these is wrong exactly, but all of them describe a different business than the one that exists.

The structural issue is that the purchase decision and the purchase event are separated by an unusually long and consistent gap, and the gap is imposed by the business model rather than by customer behaviour. People aren't deliberating for twelve days. They're waiting for the deadline, which is a different thing and needs modelling differently.

Practical implications: extend your attribution windows well beyond platform defaults, look at incrementality testing rather than platform-reported ROAS if you have the volume for it, and treat first-touch as more informative than usual in this category, because the first touch is genuinely what introduced the competition.

Measure the entrant, not the transaction

The single most useful reframe for this category is to stop analysing competitions and start analysing entrants.

Transaction-level analysis tells you a competition sold well. Entrant-level analysis tells you whether the business is compounding, which is the thing that actually determines whether it survives.

The metrics worth building:

Cohort retention by acquisition month, measured in competitions entered rather than calendar time. An entrant acquired in March who has entered eleven draws since is a fundamentally different asset from one who entered once.

Value per entrant over a rolling window, segmented by acquisition channel. Channels that look expensive on cost per first purchase often look very different on twelve-month value, and in a repeat-purchase category the difference is usually decisive.

Entry frequency distribution. This is almost always heavily skewed, with a small proportion of entrants generating a disproportionate share of revenue. Knowing the shape of that curve, and whether it's steepening, tells you more about business health than revenue does. It also has responsible-play implications worth taking seriously, given UK operators now work under voluntary code expectations around spend limits.

Funnel analysis under load

There's a measurement trap in the closing hour that's specific to this pattern.

Conversion rate typically degrades during peak traffic, and there are two very different possible explanations. Either the marginal visitor arriving in the final hour is lower intent, which is a marketing observation, or the site is struggling and losing people mechanically, which is an engineering emergency. These look identical in a conversion rate chart.

Separating them requires instrumenting the funnel with performance data alongside behavioural data. Time to interactive and server response time bucketed by minute, joined to drop-off by funnel step. If checkout abandonment correlates with response time rather than with traffic volume per se, you have your answer.

This is worth building before you need it. Diagnosing it retrospectively from aggregate data is much harder.

The A/B testing problem

Testing in a bursty business is legitimately difficult and often done badly.

Your sample arrives in concentrated bursts under conditions that differ substantially from the rest of the cycle, and each competition has a different prize, a different audience mix and a different level of promotional support. Running variant A on one competition and variant B on the next is not a controlled experiment, it's a comparison of two different populations under two different sets of conditions.

Concurrent randomised assignment within a single competition is the only clean approach, and even then you need to think about whether effects observed during the calm period generalise to the peak. A checkout change that helps at low traffic may behave differently when the server is under pressure.

If volume doesn't support proper testing, be honest that you're making judgement calls informed by data rather than running experiments. That's a legitimate position and better than false precision.

Communicating probability honestly

A small but interesting adjacent problem. UK operators are expected to display transparent odds, which means presenting probability to a general audience that reliably misreads it.

"1 in 4,500" is accurate and means very little to most people. Live odds that update as tickets sell are more honest but introduce a comprehension issue, because odds worsening as a competition fills is counterintuitive to someone who assumed buying early was equivalent to buying late.

There's genuine work here in presenting probability accurately without either overstating chances or making the display so discouraging that it's functionally hidden. It's a data communication problem more than a design one, and it deserves more attention than it gets.

Letting measurement drive the build

The reason to invest in this analytical layer is that it changes design decisions with money attached.

If your data shows that entries cluster in the final ninety minutes, then checkout performance under concurrency is your highest-value engineering priority, not your homepage load time. If it shows that repeat entrants convert at several times the rate of first-timers, then account features and saved payment methods matter more than acquisition polish. Effective UK raffle website design follows from that evidence rather than from best-practice checklists, which is why specialist builders like Nera Marketing provision infrastructure and mobile checkout around the peak event rather than around average load.

Start with the questions

Three worth being able to answer before you build any reporting.

What proportion of a competition's revenue arrives in the final two hours, and is that proportion changing? What is an entrant worth over twelve months, by acquisition channel? And when conversion rate drops during the peak, is that intent or infrastructure?

If your current analytics can't answer those, that's the gap. It's usually more valuable than another dashboard.