A playable QA holiday code freeze checklist to run early
A playable QA holiday code freeze checklist run two weeks early catches the defects that a rushed submission window has no time left to fix.
Most networks lock creative review earlier than usual in the run-up to the holidays, and most playable production teams find this out from a network's account manager rather than their own calendar. A playable QA holiday code freeze checklist run two weeks before that lockdown, rather than in the days before it, is the difference between fixing a defect and shipping it live for six weeks because there was no window left to resubmit.
Why the holiday freeze is different from a normal review cycle
Network review teams slow down over the holiday period the same as everyone else, and most networks compress their own review calendar into fewer working days before year-end while demand for review slots goes up, not down, as every advertiser tries to get creative live before the freeze. A playable that fails review during a normal week gets resubmitted within days. A playable that fails review during the week before a network's holiday freeze can sit rejected until the freeze lifts in January, which turns a minor QA gap into a six-week gap in live creative during the highest-spend period of the year.
The checklist to run before the freeze, not during it
- Device and OS matrix, run fresh, not reused from launch QA: playables that passed testing at launch can fail months later against OS updates that shipped since, and holiday traffic skews toward whatever devices are on sale that quarter, which may not match your original test matrix.
- Load time under network conditions, not just on office wifi: holiday traffic includes a heavier share of mobile-data users in gift-buying sessions away from home wifi, and a playable that loads acceptably on a fast connection can time out and fail to render on a slower one.
- End card and click-through paths, tested on every network build separately: a broken end card link is invisible in a QA pass that only checks the playable's interactive core, and it is the single most common holiday-season defect this desk hears about from production teams.
- Localisation strings, checked against the actual holiday markets in the media plan: a playable built for an English-only Q3 test that gets extended into German, French or Japanese markets for holiday spend needs a fresh linguistic QA pass, not a reused sign-off from an earlier quarter.
- File size and asset weight, rechecked against each network's current specs: network specs change more often than production calendars assume, and a playable that met a network's file-size limit in September may exceed a revised limit by November.
- Fallback and offline behaviour, tested deliberately, not assumed: a playable that fails silently rather than falling back to a static or video end card can cost an entire campaign's delivery on a network that does not retry a failed render.
A hypothetical case for what a missed window costs
Take a hypothetical mid-core strategy title running a playable across four networks with staggered freeze dates between late November and early December. If a QA pass for one network's build is left until three working days before that network's freeze, and the build fails on a device-and-OS combination the team had not retested since launch, the resubmission cycle alone can eat the remaining runway before the freeze locks. The practical cost is not the QA fix itself, which might take a single working day, but the five to six weeks that network's playable then sits in the rejected or default state until the freeze lifts, during exactly the highest-value spend window of the year. A team running the same checklist ten working days out catches the same defect with enough runway left to fix and resubmit calmly, at effectively the same production cost.
Building the calendar backwards from the freeze date
The practical fix is calendar discipline, not more QA headcount. Confirm each network's actual holiday freeze date now, since they vary by two to three weeks across networks and are rarely announced with much notice. Build the QA pass to complete ten working days before the earliest freeze date on that list, leaving room for at least one resubmission cycle if something fails. Treat any playable still in QA five working days before a freeze date as already late, and escalate it rather than hoping the review queue moves faster than usual during the network's own busiest period. Where a title runs across several networks with different freeze dates, build the calendar around the earliest date on the list rather than an average, since treating a later network's deadline as representative of the whole slate is how the earliest-freezing network ends up the one that gets missed.
What this protects
A playable QA holiday code freeze checklist run early is not a defensive exercise against a hypothetical failure. As we discussed in The Playable Ad QA Checklist to Run Before Submission, the cost of a caught defect is measured in hours; the cost of one caught after a freeze is measured in weeks of live spend running against a playable a team already knows is broken. Production teams who treat the freeze date as the deadline, rather than the buffer before it, are the ones who end up submitting emergency fixes into a queue that has already stopped moving.
Playable QA holiday code freeze: what to watch next
Two things are worth tracking as more networks publish freeze calendars earlier in the year. Watch whether networks converge on a more standard freeze window, which would make the ten-working-day buffer recommended here easier to plan around a single date rather than several staggered ones. And watch whether any network offers an expedited review lane for a small resubmission fix during the freeze itself, since even a limited exception for minor defect fixes would meaningfully reduce the cost of a QA gap caught too late.
