Un QR code en publicité vidéo exige un tiers de l'écran. Il obtient un coin

Le code dans le coin échoue avant que quiconque ne prenne son téléphone

Le placement standard est le coin inférieur droit du packshot, dimensionné pour tenir poliment à côté du logo et de la mention légale - huit à douze pour cent de la hauteur d'écran, affiché pendant les trois à cinq secondes que dure le packshot. On traite cela comme une décision de mise en page, on en débat en termes d'encombrement et de hiérarchie de marque, et cela est validé par des gens qui ont tous scanné le code avec succès sur le moniteur de la salle de montage.

Ce n'est pas une décision de mise en page. C'est une décision de résolution, et l'arithmétique qui la gouverne est bouclée avant que quiconque dans la pièce n'ait un avis. Un téléphone qui photographie un téléviseur capture toute la pièce ; le téléviseur est une fraction de cette image, le code est une fraction du téléviseur, et la grille du code est ensuite divisée en 25 à 53 cases de côté. Ce qui survit au bout de la chaîne, c'est une poignée de pixels par case, et sous une certaine poignée plus rien ne se décode - ni lentement, ni parfois, ni avec une meilleure application.

Si l'on continue de passer à côté, c'est que toutes les vérifications faites en production le sont à la mauvaise distance. Le code est scanné sur le moniteur de montage à bout de bras, sur le lien de validation sur un portable à 60 cm, et sur un téléphone tenu à 30 cm d'un autre téléphone. Géométriquement, ces trois situations n'ont rien à voir avec un canapé, et toutes les trois passent. La seule condition dans laquelle la publicité sera réellement vue est celle que personne ne teste, parce que la tester suppose d'aller se planter dans un salon.

Cet article fait donc l'arithmétique, puis la mesure. La question n'est pas de savoir si les QR codes ont leur place en publicité vidéo - c'est affaire de goût, et la réponse dépend probablement de la marque. La question est la taille qu'un code doit atteindre pour que le débat sur le goût vaille seulement la peine d'être ouvert.

Ce que nous avons mesuré, et ce que cela ne peut pas vous dire

Le banc d'essai déroule toute la chaîne de façon logicielle. Un code est rendu à 12 pixels par module avec la zone de silence de quatre modules que spécifie l'ISO/IEC 18004, redimensionné dans un master 1080p à la taille qu'il occuperait dans la publicité finie, compressé, marginé, pivoté hors équerre, rééchantillonné au nombre de pixels qu'une caméra de téléphone en recueillerait à une distance de visionnage donnée, filé pour simuler le mouvement pendant l'exposition, puis remis à un décodeur. Chaque chiffre ci-dessous est la proportion de tentatives décodées.

Chaque cellule représente 216 tentatives : douze charges utiles différentes, six angles compris entre un et onze degrés hors équerre, et trois variations d'un pixel de la taille capturée. Ce décompte existe à cause d'une erreur qui mérite d'être reconnue. La première version du banc d'essai donnait au décodeur une image parfaitement d'équerre et alignée sur la grille, et il décodait allègrement un code à un pixel par module - un résultat qui relève d'une arithmétique réelle et d'un contresens complet, puisqu'il mesure une coïncidence d'échantillonnage qu'une main tenant un téléphone ne reproduira jamais. C'est la rotation qui place chaque module à une phase sous-pixel arbitraire, et elle a déplacé le plancher de plus du double.

Le décodeur est le plus faible, délibérément

Le décodeur est jsQR, le portage JavaScript du cœur de ZXing - la même famille de décodeurs dont nous avons lu le binariseur dans le code source pour les mesures de contraste. Le framework Vision d'Apple et ML Kit de Google sont ce qui lit réellement la plupart des codes, tous deux sont fermés, et un chiffre issu de l'un ou de l'autre est un chiffre qu'aucun lecteur ne peut vérifier. jsQR est en outre, presque certainement, le moins performant des trois : ni étage d'apprentissage automatique, ni accumulation multi-images, ni super-résolution.

Cela vaut la peine de signaler un étalonnage. Notre plancher sur image propre est ressorti à 2,5 pixels par module, et la documentation de ML Kit sur la lecture de codes-barres demande un code dont « la plus petite unité significative » fasse « au moins 2 pixels de large et, pour les codes bidimensionnels, 2 pixels de haut ». Qu'un décodeur plus faible se place un quart de pixel au-dessus du minimum publié par le fabricant est à peu près le meilleur accord auquel ce type de montage puisse prétendre, et c'est la raison pour laquelle le tableau de tailles plus bas doit se lire comme approximativement juste plutôt que comme pessimiste d'un facteur.

Ce que le banc d'essai laisse de côté

• Les téléphones réels. Aucun iPhone ni aucun Android n'a été pointé vers un téléviseur pour cette étude. La stabilisation optique, la fusion multi-images et les deux décodeurs fermés jouent tous en faveur du lecteur, et aucun n'est modélisé.
• Le codage vidéo entre images. La compression est ici un JPEG sur une image isolée, qui tient lieu d'image intracodée. Un code immobile sur un plan immobile ne coûte presque rien à un vrai encodeur après la première image ; un code incrusté sur des images en mouvement est recodé en permanence. Comme la compression s'est révélée quasi indifférente dans les deux cas, cela pèse moins qu'il n'y paraît.
• La dalle et le capteur qui battent l'un contre l'autre. Une caméra qui photographie un écran peut produire du moiré, et un master en 24p converti sur une dalle 60 Hz puis échantillonné par un obturateur déroulant peut produire des bandes. Les deux sont réels, les deux nuisent, et aucun n'est simulé.
• Les reflets, la lumière ambiante et le visionnage désaxé. Les trois retranchent, et les trois relèvent du travail sur le contraste plutôt que de celui-ci.
• Les gens. Le temps qu'il faut à quelqu'un pour remarquer un code, trouver son téléphone et le pointer n'est pas mesurable par un banc d'essai. La section correspondante plus bas est signalée comme une estimation.

Toutes ces omissions vont dans le même sens sauf la première : le banc d'essai est plus dur avec le code qu'une photographie fixe, et plus indulgent qu'un salon. Le résumé honnête est que ces chiffres localisent la falaise, et que le protocole de dix minutes en fin d'article est le moyen de savoir de quel côté se trouve votre campagne.

Le plancher est à deux pixels et demi par module

Les pixels par module désignent le nombre de pixels de caméra qui tombent sur une case de la grille d'un QR code, et c'est la quantité sur laquelle se paie toute autre variable d'un scan. Le contraste, le flou, la compression, l'engraissement de l'encre et le bruit du capteur réduisent tous, au bout du compte, la même chose : la confiance avec laquelle un décodeur peut dire de quel côté de la frontière noir-blanc une case est tombée. Sous une certaine densité d'échantillonnage, il ne reste plus de confiance à dépenser.

Deux choses dans ce tableau valent plus que le plancher lui-même. La première est l'étroitesse de la transition. Il n'y a pas de longue traîne de codes limites que des utilisateurs patients finiraient par scanner : entre 2,0 et 2,5 pixels par module, le taux de lecture passe de 8 % à 99 %, ce qui signifie qu'un code a la densité d'échantillonnage ou ne l'a pas, et qu'un quart de pixel par module sépare ces deux états.

La seconde est la deuxième colonne. Compresser le master en JPEG qualité 40 - visiblement dégradé, bien en dessous de ce que livrerait un diffuseur ou une plateforme - a fait bouger le résultat d'un ou deux points dans un sens ou dans l'autre sans jamais déplacer la falaise. Cela mérite d'être dit clairement, car « la compression vidéo mange les QR codes » est l'explication standard de leur échec à la télévision, et dans cette mesure elle est tout simplement fausse. Ce n'est pas la compression qui tue ces codes. C'est l'échantillonnage.

Le corollaire est que tout le problème se réduit à une question : combien de pixels de caméra le code reçoit-il ? Ce n'est une propriété ni de la création, ni du format de fichier, ni de l'encodeur. C'est une propriété de l'angle que le code occupe dans l'œil du spectateur, c'est-à-dire de la géométrie, et la géométrie a la délicatesse d'être prévisible.

La taille de l'écran s'annule et seul l'angle subsiste

La caméra d'un téléphone est une projection rectilinéaire : une distance transversale à une portée connue se convertit en pixels par une constante unique. Pour un champ de vision horizontal de 70 degrés - un équivalent 26 mm fait 69,4 degrés, et les caméras principales des téléphones sortent depuis des années à moins d'un degré de là - cette constante vaut 1 371 pixels par radian sur une image de 1920 pixels de large. Toute la chaîne se ramène donc à une ligne d'arithmétique :

pixels par module = 1371 × f ÷ (k × N), où f est la hauteur du code exprimée en fraction de la hauteur d'écran, k la distance de visionnage exprimée en hauteurs d'écran, et N le nombre de modules sur la largeur du code, zone de silence de quatre modules comprise.

Ce qui est intéressant dans cette expression, c'est ce qui n'y figure pas. Aucune taille d'écran, aucune distance en mètres : seulement leur rapport. Ce n'est pas une simplification, c'est la physique réelle : un téléviseur de 77 pouces occupe le même angle depuis le fond d'une grande pièce qu'un 43 pouces depuis une petite, et la caméra ne sait pas et ne se soucie pas duquel elle regarde. La réponse à « quelle taille doit faire le code » est donc un pourcentage de l'écran, et le même pourcentage vaut partout.

Cela signifie aussi que k peut se déduire de recommandations publiées d'angle de vision plutôt que se deviner. THX recommande un angle de vision horizontal d'environ 40 degrés, ce qui donne pour un écran 16:9 une distance de 2,4 hauteurs d'écran. La recommandation SMPTE de 30 degrés donne 3,3 hauteurs d'écran. Ce sont deux recommandations pour des gens attachés à la qualité d'image ; les salons ordinaires sont plus reculés que l'une et l'autre, et c'est pourquoi les tableaux ci-dessous vont jusqu'à quatre hauteurs d'écran - un 55 pouces à environ 2,7 m.

Le 1920 de cette constante mérite sa propre réserve, car c'est l'hypothèse favorable. Le flux d'analyse est la mémoire tampon vidéo en résolution réduite sur laquelle travaille réellement le détecteur de codes d'un téléphone, et ce n'est pas la photographie en pleine résolution que l'appareil serait capable de prendre. La documentation ML Kit de Google recommande de l'alimenter en « 1280x720 ou 1920x1080 », et note que descendre plus bas n'est viable qu'« en exigeant que le code-barres occupe la majeure partie de l'image d'entrée ». Tout ce qui suit retient la meilleure des deux. En 1280 x 720, chaque chiffre du tableau suivant se dégrade d'un tiers.

Quelle taille le code doit réellement faire

L'arithmétique posée, place à la mesure. Chaque ligne est une hauteur de code exprimée en pourcentage de la hauteur d'écran ; chaque paire de colonnes est une distance de visionnage en hauteurs d'écran, avec la densité d'échantillonnage obtenue et le taux de lecture sorti du banc d'essai. La charge utile est une URL de 25 caractères en correction d'erreurs M, soit la version 3 - 29 modules, ou 37 sur la largeur avec la zone de silence. Tout est immobile, compressé et à un à onze degrés hors équerre.

Lisez la colonne k = 4, car c'est là que la plupart des gens sont assis. Un code au cinquième de la hauteur d'écran a été lu six fois sur cent. Un code au quart de la hauteur d'écran a été lu quatre-vingt-quinze fois sur cent. Toute la plage utile de cette décision de conception se situe entre 20 % et 30 % de la hauteur d'écran, et le placement classique dans un coin n'est pas simplement au bas de cette plage : il sort du tableau d'un facteur de deux à trois.

Remarquez aussi ce que fait la colonne du master, c'est-à-dire rien. Un code à 20 % de la hauteur d'écran fait 216 pixels de côté dans le fichier 1080p, confortablement au-dessus du plancher ; le code n'est détruit ni au montage, ni à l'étalonnage, ni à l'encodage. Il est détruit par la distance entre un canapé et un téléviseur, quantité qu'aucun processus de postproduction ne peut améliorer. C'est le même argument que celui que dimensionner un code imprimé pour sa distance de lecture tient à propos du papier, et il est plus strict ici parce que le spectateur ne peut pas s'approcher de l'écran.

Le corollaire de la colonne k = 2 vaut aussi la peine, car il explique précisément l'illusion de la salle de montage. À deux hauteurs d'écran - un 55 pouces à 1,4 m, ce qui occupe à peu près l'angle d'un moniteur de bureau à bout de bras - un code à 12,5 % de la hauteur d'écran se lit 82 % du temps. C'est la vérification que tout le monde fait, et elle passe. La densité d'échantillonnage décroît en proportion directe de la distance, et le canapé se trouve un à deux mètres au-delà de l'endroit où le test a été fait.

Le mouvement l'achève plus vite que la taille

La compression s'est révélée sans importance et la taille d'une importance énorme. Le mouvement est pire que les deux. Le banc d'essai applique un filé linéaire au capteur - une convolution en boîte dans la direction du déplacement, ce que le mouvement pendant une exposition fait réellement à une image, plutôt que le flou gaussien symétrique qu'appliquerait une fonction de flou - et mesure la distance que le code peut parcourir sur le capteur pendant une exposition avant que le taux de lecture ne s'effondre.

La tolérance est d'environ un huitième de module, soit en pixels de caméra entre un quart de pixel et un pixel selon la taille du code. Il vaut la peine de traduire cela en quelque chose qu'une réalisation puisse appliquer. Un pixel de caméra vaut 0,042 degré d'arc. À une exposition de 1/60 s - un téléphone dans une pièce peu éclairée, exposant pour un écran lumineux - un quart de pixel correspond à une vitesse angulaire d'environ 0,6 degré par seconde. C'est une main tenue raisonnablement immobile, et ce n'est pas une main qui s'étire depuis un canapé.

Appliquée au déplacement du code lui-même à l'écran, la même arithmétique est brutale. À trois hauteurs d'écran, une hauteur d'écran correspond à 457 pixels de caméra : un code qui dérive à l'écran avec une exposition de 1/60 s dispose donc d'un budget d'environ un trentième de hauteur d'écran par seconde. Un code qui entre en glissant élégamment en deux secondes, un léger travelling avant sur le packshot, une caméra à l'épaule derrière un code incrusté, un rebond, une rotation, un agrandissement : tous se situent un à deux ordres de grandeur hors de ce budget pendant toute la durée du mouvement. Le code est décoratif tant qu'il ne s'arrête pas.

Pourquoi les taux de lecture sont des probabilités et le tableau des tailles non

Il y a dans ces deux tableaux une distinction qui compte davantage que l'un ou l'autre. Un code trop petit échoue de façon déterministe : chaque image est la même image, trente fois par seconde, et aucune ne se décode. Un code assez grand mais en mouvement échoue de façon aléatoire : la plupart des images sont filées, quelques-unes ne le sont pas, et le scan réussit à l'instant où une image propre arrive.

Le temps à l'antenne n'est donc pas un remède universel, c'est le remède d'exactement un mode de défaillance. Trois secondes de plus achètent quatre-vingt-dix tentatives supplémentaires contre un problème de mouvement et n'achètent strictement rien contre un problème d'échantillonnage. C'est l'élément le plus utile de cet article pour qui rédige un brief de production : si le code est assez grand et immobile, il se lira presque instantanément ; s'il est trop petit, il ne se lira pas même en le laissant à l'antenne toute la coupure publicitaire.

Deux façons dont une publicité rétrécit son propre code sans le voir

Tout ce qui précède supposait une URL de 25 caractères en correction d'erreurs M. Ces deux hypothèses sont couramment rompues, et rompues par des gens qui essaient d'aider, et elles le sont de la même manière : elles ajoutent des modules, le code garde la même taille physique à l'écran, et chaque module rétrécit.

La chaîne de tracking

L'URL de campagne arrive de l'agence média avec ses paramètres de mesure accrochés, parce que c'est ainsi que la campagne est attribuée. Personne ne regarde ce que cela fait à la grille.

Une chaîne de tracking complète divise par deux le taux de lecture d'un code par ailleurs correctement dimensionné. Elle le fait au moment précis où l'équipe marketing s'efforce le plus de mesurer la campagne, ce qui en fait un bon candidat au schéma le plus contre-productif de tout le sujet. Le remède n'est pas de renoncer à l'attribution : c'est de placer un chemin court sur un domaine que vous possédez devant les paramètres et de les accrocher à la redirection, où ils ne coûtent rien. Ce que coûte réellement une redirection louée sur la durée de vie d'une campagne est un autre argument, et il aboutit à la même recommandation.

Monter la correction d'erreurs

L'autre réflexe consiste à relever le niveau de correction d'erreurs, sur la théorie qu'une situation plus difficile à lire appelle davantage de redondance. C'est le mauvais levier, et il est même nuisible, pour la même raison qu'il l'est en cas de faible contraste : il crée de la redondance en ajoutant des modules, et ce sont les modules qui manquent.

H existe pour les codes qui se salissent, se déchirent, se font imprimer dessus ou se retrouvent partiellement couverts par un logo. Un code sur un téléviseur n'est rien de tout cela : il est livré au pixel près puis sous-échantillonné, et le sous-échantillonnage n'est pas un dommage que les blocs de correction d'erreurs peuvent réparer, puisqu'il empêche les modules d'être lus tout court. Utilisez L ou M à l'écran et dépensez les modules économisés à agrandir chacun d'eux. L'arbitrage complet entre capacité de récupération et taille de module s'applique ici sans changement ; les écrans se trouvent simplement à l'extrémité où la redondance vaut le moins.

Le temps est le budget que personne n'écrit

Cette section est une estimation et non une mesure, et il vaut mieux le dire avant les chiffres qu'après. Rien dans le banc d'essai ne peut mesurer le temps qu'une personne met à réagir devant un téléviseur, et nous n'avons pas mené cette étude.

La séquence qu'un spectateur doit accomplir n'est pas courte. Remarquer le code et décider que cela vaut la peine d'agir prend une à deux secondes. Récupérer et déverrouiller un téléphone, deux à quatre. Arriver à l'appareil photo, une à trois de plus, davantage si le téléphone rouvre sur ce qu'il affichait en dernier. Cadrer le téléviseur, laisser l'autofocus se stabiliser et rester immobile, deux à quatre encore. Cela fait six à treize secondes en partant de zéro, contre un packshot qui dure généralement trois à cinq.

Il existe une vraie circonstance atténuante, et elle mérite d'être créditée : une large part de la télévision est regardée par des gens qui tiennent déjà un téléphone, ce qui supprime l'étape de récupération et l'essentiel du déverrouillage. C'est sans doute toute la raison pour laquelle quelqu'un a pensé que les QR codes fonctionneraient à la télévision. C'est un argument solide en faveur de l'existence du format, et ce n'est pas un argument en faveur de trois secondes, car les deux dernières étapes - arriver à l'appareil photo, puis viser et tenir immobile - ne sont pas raccourcies par un téléphone déjà en main.

Notre recommandation, énoncée pour l'opinion qu'elle est : huit secondes d'un code immobile et correctement dimensionné constituent le minimum qui vaille la peine d'être briefé, et si la création ne peut pas céder huit secondes, alors la création a décidé que le code était décoratif. C'est une décision légitime. Elle ne devrait simplement pas être prise par accident, puis mesurée ensuite comme un taux de scan.

La publicité dont tout le monde se souvient a obéi à l'arithmétique

Il existe un contre-exemple célèbre à tout ceci, et il est célèbre précisément parce qu'il a fait absolument tout ce que cet article recommande. En février 2022, Coinbase a diffusé un spot de soixante secondes au Super Bowl qui n'était rien d'autre qu'un QR code changeant de couleur, dérivant sur un écran par ailleurs noir. Variety et CNN l'ont couvert à l'époque, et le second a rapporté la partie dont tout le monde se souvient : la page de destination a reçu tant de trafic que l'application est tombée.

Mettez cela en regard des tableaux ci-dessus. Le code était grand, puisqu'il avait toute l'image. Il était seul, donc rien ne disputait ni l'attention du spectateur ni les bits de l'encodeur. Il est resté soixante secondes à l'écran au lieu de quatre, soit environ 1 800 images de caméra dans lesquelles un décodeur pouvait en trouver une propre. Et il dérivait lentement au lieu de couper ou de changer d'échelle, ce qui maintient un code en mouvement dans le budget de filé par exposition, là où un mouvement rapide n'entre pas.

La seule chose qu'il a faite et que cet article déconseillerait est le changement de couleur, et même celui-ci est moins téméraire qu'il n'y paraît : la palette est restée du sombre sur clair ou du clair sur sombre d'un bout à l'autre, plutôt que d'apparier deux tons moyens, et c'est cette distinction qui décide vraiment si un code en couleur survit à une caméra. Ce qu'il n'a pas fait, c'est mettre un petit code dans un coin pendant quatre secondes.

La conclusion n'est pas que toutes les marques devraient acheter soixante secondes de Super Bowl. C'est que la publicité invariablement citée comme preuve que les QR codes fonctionnent à la télévision est une publicité qui a dépensé tout son budget créatif à satisfaire la physique. Citée comme précédent pour un code en coin sur un packshot, elle prouve le contraire de ce qu'on lui fait dire d'habitude.

Mettez-le sur votre propre téléviseur en dix minutes

Tous les chiffres ci-dessus valent pour une caméra simulée et un décodeur plus faible que ceux qui dorment dans les poches. Le chiffre qui compte pour une campagne précise est celui que produit son fichier final, sur un vrai écran et depuis un vrai canapé, et il s'obtient en dix minutes.

1. Lisez le fichier livré, pas le master. Mettez le livrable réel sur le téléviseur réel : diffusez-le, chargez-le depuis une clé, ou publiez-le en vidéo non répertoriée sur la plateforme visée. Visionner un master ProRes sur un moniteur calibré est le test qui est déjà passé et qui ne vous a rien appris.
2. Asseyez-vous là où les gens s'assoient, et notez le rapport. Mesurez la distance de l'écran au canapé, mesurez la hauteur de l'écran, et divisez. Ce rapport est le k de tous les tableaux ci-dessus, et c'est le nombre qui vous permet de comparer votre résultat aux leurs. Tout ce qui va de trois à quatre et demi est une pièce ordinaire.
3. Scannez avec deux applications appareil photo natives. Une iOS, une Android, avec l'appareil photo intégré plutôt qu'une application de scan. Les applications de scan sont plus tolérantes que les natives et valideront des codes que votre public ne peut pas lire. Donnez cinq secondes à chaque téléphone, c'est ce que donne le packshot.
4. Faites-le à la va-vite. D'une main, avachi, sans caler le coude nulle part. Le résultat soigneux n'est pas le résultat : un quart de pixel de caméra de mouvement pendant une exposition, c'est tout le budget de mouvement, et se caler vaut davantage que cela.
5. Faites le témoin avant de conclure quoi que ce soit. Approchez-vous et scannez cette même image figée à un mètre. Si cela échoue, le problème est le contraste, la zone de silence ou la charge utile plutôt que la taille, et agrandir le code n'y changera rien.
6. Montez par paliers de 5 % jusqu'à deux réussites d'affilée, puis ajoutez un palier. Réexportez avec le code agrandi de cinq pour cent de la hauteur d'écran et recommencez jusqu'à ce que les deux téléphones le scannent deux fois de suite depuis le canapé. Ajoutez ensuite un palier de plus. Ce dernier palier est la marge pour les téléphones, les pièces et les yeux que le test n'a pas inclus.

Si la réponse qui remonte est que le code doit occuper un tiers de l'écran, c'est la vraie réponse, et il vaut mieux l'avoir avant le tournage qu'après le bilan de campagne.

Que mettre dans la publicité à la place

La recommandation sur laquelle se referme cet article est plus étroite que son titre. Les QR codes en publicité vidéo ne sont pas inutiles : ils sont chers, en surface d'écran et en secondes, et presque toutes les publicités qui en utilisent un refusent de payer l'un ou l'autre prix, puis s'en prennent au format.

• Si vous utilisez un code, donnez-lui un quart à un tiers de la hauteur d'écran et huit secondes immobiles. En pratique, cela signifie que le code est le packshot et non un ornement posé dessus. C'est toute la recommandation ; tout le reste ici en découle.
• Gardez la charge utile sous environ 25 caractères. Un chemin court sur un domaine que vous possédez, avec les paramètres de tracking accrochés à la redirection plutôt que placés dans le code. Cela vaut plus que n'importe quel autre changement isolé, car cela rachète des modules sans rien coûter par ailleurs.
• Utilisez la correction d'erreurs L ou M, pas H. À l'écran, le code est livré intact puis sous-échantillonné, et la redondance n'aide en rien contre le sous-échantillonnage.
• Ne le déplacez pas, ne l'agrandissez pas, ne le faites pas tourner ni glisser à l'entrée. Le mouvement dispose d'un budget nettement inférieur à un pixel de caméra par exposition, et toute animation en sort de plusieurs ordres de grandeur. Animez tout le reste du packshot.
• Si la publicité sera surtout regardée sur téléphone, n'utilisez pas de code du tout. L'écran qui diffuse la publicité est celui qui devrait la lire, et il n'y a pas de second appareil. Utilisez le format cliquable proposé par la plateforme.
• Envisagez plutôt une URL courte, dite et écrite. Un domaine mémorable lu à voix haute et affiché en texte n'a pas de taille angulaire minimale, survit au mouvement, fonctionne sur un écran de téléphone et n'oblige personne à tenir quoi que ce soit immobile. Il convertit moins bien par impression et échoue moins absolument, et pour un packshot de quatre secondes cet échange est en général dans le bon sens.
• Le cinéma est l'exception qu'il faut connaître. La même arithmétique qui disqualifie le coin d'un téléviseur est généreuse en salle, où l'écran occupe un angle bien plus grand depuis tous les fauteuils. Un code sans espoir à la maison peut être modeste sur un écran de cinéma.

Une note honnête sur notre propre outil, puisque cet article vient de recommander quelque chose qu'il ne fait pas. KoloQR, un générateur de QR codes gratuit avec des QR codes ronds et de formes personnalisées, fixe la correction d'erreurs au niveau H, parce qu'il dégage un espace au milieu de la grille pour un logo et que H est ce qui paie cet espace. C'est la bonne valeur par défaut pour un code imprimé avec une marque au centre et la mauvaise pour un écran : un code exporté depuis le générateur pour une publicité vidéo porte donc une version de plus qu'il ne lui en faut. À un tiers de la hauteur d'écran, cela ne coûte rien de mesurable ; à un cinquième, cela fait partie des raisons pour lesquelles un cinquième ne marche pas.

La limite de tout ce qui précède est celle énoncée en tête : nous avons mesuré une chaîne logicielle, pas un salon. Aucun téléphone n'a été pointé vers un téléviseur pour cela, et le décodeur que nous avons employé est plus faible que ceux qui liront réellement votre publicité, ce qui veut dire que la vraie falaise se situe plutôt en dessous des chiffres de ces tableaux qu'au-dessus. Ce à quoi les tableaux servent, c'est à vous dire de quel côté se trouve un code dans un coin, et ce n'est pas serré.