How to use Building A Monthly Seasonality Index From Last Year's GA4 Sessions And AOV
A practical walkthrough for turning last year's GA4 sessions and AOV into a defensible 12-month seasonality index — the data prep that has to happen before you annualize any test win.
Monthly Seasonality Index (GA4 Sessions + AOV)
A 12-value multiplier set built from prior-year GA4 sessions and AOV, combined into an RPV weight that lets you annualize honestly.
A monthly seasonality index is a set of twelve multipliers — one per calendar month — that describe how far each month sits above or below your average trading month. Built correctly, it uses last year's GA4 sessions to capture traffic seasonality and last year's AOV to capture basket-size seasonality, then combines the two into a single revenue-per-visitor (RPV) weight.
The index is what stops a Q3-tested lift from being multiplied by twelve and reported as an annual number. It is a data-prep artefact, not a forecast in itself — but every honest annualization downstream depends on it.
Most stores skip this step and pay for it later. A CRO team runs a checkout test in August, sees a 6% RPV lift, and multiplies the monthly revenue impact by twelve to get an annual number. The CFO signs off. Three quarters later the roll-up misses by 18% because August is a quiet month and November did most of the year's revenue at a completely different AOV.
The fix is not a smarter forecast — it is a cleaner input. A properly-built seasonality index gives you a single vector of twelve numbers you can multiply against any monthly RPV assumption to get a defensible annual figure.
Step 1: Extract clean monthly sessions and AOV from GA4
You need two prior-year series at monthly grain: total sessions and average order value. In GA4 the cleanest path is a custom Explore report with Month as the row dimension and Sessions plus Purchase revenue and Transactions as metrics — AOV is Purchase revenue divided by Transactions. A repeatable Explore setup is worth the ten minutes; you will rebuild this index every year.
Filter to the full prior calendar year. Do not use rolling 12 months here — you want January-to-December so the index aligns with how the business plans and how the CFO reads the P&L. Exclude internal traffic and any obvious bot spikes at the source.
Two data-quality traps show up immediately. First, consent-mode gaps in Europe can underreport prior-year sessions by 20-40% in months where your banner changed — you need to patch those months against modeled conversions or a server-side source before they poison the index. Second, if the store is younger than twelve months, this method does not work at all and you fall back to a category benchmark curve.
Strip BFCM and one-off promos before you weight anything
Black Friday week and Boxing week routinely represent 8-15% of an apparel store's annual revenue in five trading days. Left in the raw series, they turn November and December into 1.6x-2.0x multipliers that will never repeat cleanly. Strip promo weeks to a normal-trading baseline first, then reintroduce them as a separate promo overlay in the final forecast — not inside the underlying seasonality index.
Step 2: Weight sessions and AOV separately
The instinct is to divide monthly revenue by annual revenue and call that the index. Do not do this. Traffic seasonality and basket-size seasonality move on different clocks, and collapsing them hides which lever a future test is actually pulling.
Build two vectors instead. The sessions index is each month's sessions divided by the average monthly sessions across the twelve months. The AOV index is each month's AOV divided by the average monthly AOV. Both series should average to roughly 1.0 by construction — normalize them explicitly so the arithmetic downstream stays clean.
Sessions vs AOV seasonality — typical DTC apparel store (prior-year GA4)
Sessions index
AOV index
Notice the divergence in November: sessions spike to 1.42 on Black Friday demand, but AOV drops to 0.92 because promo pricing compresses basket value. Multiplying revenue directly would smear these two signals together. Keeping them separate lets you model, say, a checkout test whose lift is entirely on conversion rate (a sessions-driven lever) differently from a bundle test whose lift is entirely on AOV.
Step 3: Combine into an RPV-weighted multiplier
For most annualization use cases you want a single monthly multiplier that captures revenue-per-visitor seasonality. The composition rule is straightforward: monthly RPV index equals the sessions index multiplied by the AOV index, weighted by conversion rate if you have it. Since conversion rate typically moves with traffic quality (Q4 traffic converts differently to July traffic), most teams fold it into the sessions vector and use the simple product as the combined index.
Re-normalize the combined vector so the twelve values average to 1.0. That final normalization is what makes the index safe to multiply against any monthly assumption — if the mean drifts to 1.08 because of composition effects, every downstream annual forecast inherits an 8% overshoot.
Typical combined RPV seasonality multipliers by DTC vertical (prior-year, BFCM-stripped, normalized to 1.0)
| Month | Apparel | Skincare | Home goods |
|---|---|---|---|
| Jan | 0.77 | 0.88 | 0.71 |
| Feb | 0.76 | 0.92 | 0.74 |
| Mar | 0.93 | 0.98 | 0.86 |
| Apr | 0.98 | 1.01 | 0.94 |
| May | 0.99 | 1.03 | 1.02 |
| Jun | 0.91 | 0.96 | 1.08 |
| Jul | 0.84 | 0.90 | 1.05 |
| Aug | 0.90 | 0.94 | 0.98 |
| Sep | 1.09 | 1.05 | 1.03 |
| Oct | 1.25 | 1.12 | 1.14 |
| Nov | 1.31 | 1.18 | 1.24 |
| Dec | 1.27 | 1.23 | 1.21 |
The vertical differences matter. Apparel swings hardest into Q4 and hollows out in January-February. Skincare is flatter — gifting concentrates in December but the daily-routine SKUs dampen the rest of the shape. Home goods has a mid-year peak from moving season on top of the Q4 gifting curve. If your store crosses categories, weight the vertical shapes by revenue share rather than picking one.
Step 4: Validate the curve before you ship it
Before this index goes into any forecast, cross-check it against a source that is not GA4. The cleanest option is Shopify (or your commerce platform) monthly order counts — the shape of the orders curve should match the shape of your sessions × conversion curve within a few percentage points per month. Divergence usually points to a tracking gap, not real seasonality.
If a single prior year looks jagged — a supply-chain gap in March, a viral moment in July — blend two prior years with a 60/40 weight toward the most recent. That smooths idiosyncratic months without letting stale data dominate. Do not blend more than two years; the further back you go, the more attribution drift (iOS14, consent mode, GA4-vs-UA gaps) contaminates the signal.
What this index unlocks
Once you have twelve normalized multipliers, annualizing a test win becomes one multiplication per month rather than a hand-wave. You can now honestly answer questions like 'what does this Q3-tested checkout lift mean over a full year?' — and defend the answer to a CFO who has watched the last three forecasts miss by double digits.
Frequently asked questions
Because it collapses two distinct signals — traffic seasonality and basket-size seasonality — into one number, which hides which lever a future test is pulling. A checkout conversion test and a bundling test have different exposure to each vector, and combining them upfront means you can't weight the forecast correctly for either.
No. Strip promo weeks from the baseline seasonality index and reintroduce them as a separate promo overlay in the final forecast. Left in, BFCM turns November into a 1.5x-2.0x multiplier that overstates every non-promotional month's annualization.
You can't build this index from your own data. Fall back to a vertical benchmark curve (apparel, skincare, home goods each have well-known shapes) and revisit once you have a full trading year. Applying a naive index built from six months of data will bias every forecast.
Identify months where your consent banner or configuration changed — those months are almost always underreported by 20-40%. Patch them using modeled conversions from GA4, server-side event data, or Shopify order counts as a proxy before you compute the index.
The default is a straight product (sessions index × AOV index) because that's what RPV is mathematically. If your business is far more traffic-elastic than basket-elastic — or vice versa — you can weight one vector higher, but be explicit about it in the model documentation so the assumption is auditable.
Pull monthly order counts from Shopify (or your commerce platform) and compare the shape month-over-month. Sessions × conversion rate should track order count within a few percentage points per month. Sustained divergence means a tracking gap, not real seasonality.
One year is fine if it was clean. If a single year looks jagged from one-off events, blend two years with a 60/40 weight toward the most recent. Don't go further back — iOS14, consent-mode, and GA4-vs-UA drift contaminate older data enough to make it a worse input than a slightly volatile recent year.
Isolate the promo weeks in the raw data and replace them with an interpolated baseline from the surrounding non-promo weeks in the same month. Then rebuild the monthly aggregate. The goal is a seasonality curve that reflects underlying demand, not one-time marketing events.
Build a separate index per market if the shapes materially differ — European and North American Q4 curves diverge, and Southern-hemisphere apparel has an inverted seasonal profile. If markets are small or shapes are similar, one weighted-average index is acceptable.
Once a year, in January, using the just-closed prior year. Mid-year rebuilds usually introduce noise rather than accuracy — unless a structural change (new channel mix, major product launch, geographic expansion) makes the prior-year shape genuinely obsolete.
Track CAC, channels, and funnel conversion in one place
Metricuno connects ad spend, funnel events, and revenue so you can see CAC by channel, cohort, and campaign — without stitching together five tools.