A code appears in the last four seconds of a thirty-second spot, sized to sit neatly in the corner of the frame, over a shot that is still moving. Nobody in the room scans it. The people who wanted to reached for the remote, missed the rewind, and gave up. The one person who really wanted it took a photograph of the television and dealt with it later.
Television is the hardest surface a QR code gets put on, and it is not a surface at all. Three things work against it: the viewer is far away, the code is on screen briefly, and the image has been through a compressor.
Start with the distance, because it sets everything else
The working rule for sizing a code is the ten-to-one ratio: the code's width should be about a tenth of the distance it is read from. Sizing against viewing distance is the same arithmetic used for posters and billboards, and a living room gets no exemption from it.
People sit two to three metres from a television. At three metres the rule asks for a code around thirty centimetres wide. A 55-inch screen is roughly 122 centimetres wide and 69 centimetres tall, so thirty centimetres is a quarter of the screen's width and nearly half its height.
That number offends everybody who has ever laid out a broadcast frame, and it is why most on-screen codes fail. A code sized to look tasteful in the corner of a 55-inch panel is a code sized for somebody standing an arm's length from the glass, and nobody is standing there.
Two things buy the figure back down a little. A phone camera with a decent sensor and a pinch of zoom does better than the ratio assumes, because the ratio is written for a fixed field of view. And a viewer who cannot read it from the sofa will get up, zoom in, or photograph it. So thirty centimetres is the honest number, a fifth of the screen width is the practical floor, and anything smaller means you are relying entirely on the second screen. The general placement and size rules are worth a look if the code will also appear on print alongside the spot.
The clock is shorter than you think
A viewer has to notice the code, decide to act, find the phone, wake it, open the camera, aim, and hold still. Three seconds does not cover finding the phone.
Budget in stages rather than as one number. Something has to announce the code before the code appears, so the phone is already in hand: a spoken line, a caption, a pre-roll graphic. Then the code itself needs long enough for a camera to acquire and decode it, which is a second or two on a clean frame and longer on a noisy one. Then it needs to stay up while the second and third person in the room try.
Which means the code should be on screen for the longest stretch the format allows, announced in advance, and it should not be the last thing in the spot. A code that arrives on the final beat and leaves with the fade has given the viewer the reaction time of a game show buzzer.
Sponsored segments, standings graphics, scoreboard bugs and long-form programming are where on-screen codes actually work, because the code can sit there for a minute or more. A thirty-second ad is the worst case, and it is where most of them go.
Compression is quietly deleting your modules
A broadcast or streamed frame is not the frame you exported. It has been scaled, chroma-subsampled and quantised, and every one of those steps is bad for a grid of small hard-edged squares.
Quantisation is the main offender. The encoder divides the picture into blocks and discards high-frequency detail inside each one, and a QR code is nothing but high-frequency detail. At a low bitrate, module edges soften, adjacent modules bleed into one another, and ringing appears along the boundaries. The result looks exactly like a blurry code, and the cause is the same: the transition from one module to the next has been smeared across several pixels.
Interlaced formats add a problem of their own. An interlaced frame carries alternate lines from two moments in time, so a detail one or two pixels tall can land in one field and not the other. Small modules in an interlaced signal shimmer, and a scanner sampling a single field sees half a code.
The fixes all point the same way: make each module span many pixels. A module one or two pixels wide will not survive the pipeline, while a module spanning six or eight pixels survives most of it. That means fewer modules, which means a shorter payload, which means a short path on a domain you control rather than a long tracked URL with parameters trailing off the end. Keep the code pure black on pure white, never place it over anything textured, and never scale it with a smoothing filter.
Motion behind the code kills it twice
A video encoder allocates bits where the picture is changing. Put a static code over a moving shot and the encoder spends its budget on the motion, leaving the code region coarsely quantised in exactly the frames a viewer is trying to scan.
Then there is the camera's side of it. A phone pointed at a dim living-room scene lowers its shutter speed and averages whatever moved during the exposure. If the code itself moves, even slowly, the modules blur along the direction of travel and the read is gone.
So the code sits still, on a flat plate of solid colour, over a shot that is either static or completely hidden behind the plate. A white card carrying the code and one short line of type is not a failure of art direction. It is the version that works.
The margin matters here too. A code composited over video needs its four modules of clear light field, and that field has to belong to the plate rather than to whatever the footage happens to be showing in that frame. What eats a quiet zone applies with more force on screen than in print, because the background changes thirty times a second.
Most of your scans happen later, from a photograph
This is the part broadcast planning usually misses. A meaningful share of people will not scan the television at all. They will photograph it, or screenshot the stream, and open the picture afterwards.
That is a supported path on both major phone platforms, and it changes what you should optimise for. A photograph of a screen is worse than a live scan in one respect, the photographer's shake, and better in another: it is a still, so interlacing and motion are frozen and the viewer can crop and zoom into the code at leisure. Decoding a code from a picture is an ordinary thing for people to do, and a code that survives being photographed off a panel has cleared a harder bar than one that only works live.
What that argues for is generous modules, high contrast, a clean margin, and enough time on screen to be photographed rather than enough time to be scanned. Those are not the same duration. A photograph takes one second of pointing; a scan takes several seconds of holding still.
It also argues for a destination that still makes sense hours later. A page reading "this offer ran during the match" was built by somebody who assumed the scan was instant. Scanning a code off any screen covers the reflections, brightness and moire that make the live attempt harder than it looks from the edit suite.
Before the spot ships
Play the finished file through the delivery path rather than the master. Stream it, or watch it off air, or play it from the platform it will run on, and scan it from a sofa.
- Sit at the real distance, in the real light, with the room lamps on.
- Use the oldest phone in the building, with the stock camera app and nothing installed.
- Try it twice from a still photograph of the screen as well as live.
- Have somebody who has not seen the spot try it cold, without being told when the code appears.
If the cold attempt fails, the problem is usually not the code. It is that nobody told the viewer it was coming. Fix that first, then the size, then the duration. And keep the destination editable on the paid plan, because a broadcast code tends to outlive the campaign behind it.
