動画広告のQRコードには画面の3分の1が要る。実際に与えられるのは隅だけ

KoloQRチーム調査

リビングの壁掛けテレビにスポーツ広告が映っている。右側にはスタジアムの照明の下で肩を組むサッカー選手たちの写真、左側には「Join a Team. Be Part of Something Greater.」という見出しと、その下に「Scan to find teams」の一行と黄色と黒の丸いQRコード。

テレビのQRコードを読もうとするスマホが見ているのは、あなたのアートワークではありません。カメラ1フレームのうちの数十ピクセルであり、その数を決めるのはただ一つ、ソファから見たときにコードが張る角度です。チェーン全体を通す試験装置を組みました。1080pのマスター、圧縮、実際の視聴距離で少し傾いた手持ちカメラ、動きによる尾引き。そして読み取り率が崩れる地点を測りました。ふつうのリビングの距離では、画面高の5分の1を占めるコードのデコード成功率は6%。4分の1なら95%。どの動画広告も使っている隅の配置はゼロでした。表示秒数も誤り訂正もクリエイティブもこれを覆せません。失敗は最初の1フレームが読まれるより前に起きているからです。

要点

  • 静止・圧縮済み・わずかに傾いた画像で、読み取りの下限はモジュールあたり2.5ピクセルと実測しました。最初の散発的な成功は2.0、過半数に届くのは2.25です。GoogleのML Kitのドキュメント自身がモジュールあたり2ピクセル以上を求めているので、試験装置とベンダーは4分の1ピクセルの差で一致しています。
  • 画面サイズは打ち消し合います。大きいテレビほど人は遠くに座るので、答えはセンチメートルの寸法ではなく画面高に対する比率になり、その比率は43インチでも77インチでもノートパソコンでも同じです。
  • ふつうのリビングの距離、つまり55インチを約2.7m離れて見る条件では、画面高20%のコードは6%、25%は95%、30%は毎回読めました。15%を切ると、試したどの距離でも何も読めませんでした。
  • 圧縮はほとんど効かず、動きは決定的に効きます。マスターをJPEG品質40まで潰しても読み取り率は1、2ポイント動くだけでしたが、1回の露光中にカメラ側で0.5ピクセル尾を引いただけで、99%読めていたコードがゼロになりました。
  • 広告が自分のコードに無自覚にやってしまうことは二つ、UTMパラメータの追加と誤り訂正レベルの引き上げです。どちらも物理サイズはそのままにモジュールを増やします。完全なトラッキング文字列はコードを100%から48%へ、誤り訂正Hは同じコードを99%から74%へ落としました。

隅のコードは、誰かがスマホに手を伸ばす前に失敗している

定番の配置はエンドカードの右下、ロゴと注記の横に行儀よく収まる大きさ、つまり画面高の8〜12%で、エンドカードが続く3〜5秒だけ映ります。これはレイアウトの判断として扱われ、情報量の多さやブランドの優先順位の話として議論され、編集室のモニターで全員がそのコードを問題なく読めた上で承認されます。

これはレイアウトの判断ではありません。解像度の判断であり、その背後の計算は室内の誰かが意見を持つより前に決着しています。テレビを撮るスマホは部屋全体を写します。テレビはそのフレームの一部、コードはテレビの一部、そしてコードの格子はさらに一辺25〜53マスに分割されます。最後まで残るのは1マスあたり数ピクセルで、その数がある水準を下回ると何もデコードされません。ゆっくりでもなく、たまにでもなく、良いアプリを使ってもです。

これが見落とされ続ける理由は、制作中に行われる確認がすべて間違った距離で行われるからです。コードは編集モニターで腕1本分の距離から、確認用リンクではノートパソコンで60cmから、そしてスマホを別のスマホから30cm離してスキャンされます。幾何学的にはこの三つはソファとは似ても似つかず、三つとも合格します。広告が実際に見られる唯一の条件だけが誰にもテストされません。テストするにはリビングに立たなければならないからです。

そこでこの記事は、計算をしてから実測します。問うているのは、動画広告にQRコードがふさわしいかどうかではありません。それは好みの問題で、答えはたぶんブランドによります。問うているのは、好みの議論を始める価値が出るまでにコードがどれだけ大きくなければならないか、です。

何を測ったのか、そしてそれが答えられないこと

試験装置はチェーン全体をソフトウェアで通します。ISO/IEC 18004が定める4モジュールのクワイエットゾーンを付けてモジュールあたり12ピクセルで描画し、完成した広告で占めるはずの大きさへ1080pマスターの中で縮小し、圧縮し、周囲に余白を足し、直角からずらして回転させ、指定した視聴距離でスマホのカメラが集めるであろうピクセル数へ再サンプリングし、露光中の動きを模した尾引きをかけ、デコーダーに渡します。以下の数値はすべて、デコードに成功した試行の割合です。

1セルは216試行です。12種類のペイロード、直角から1〜11度の6通りの角度、取り込みサイズの1ピクセル単位のずれ3通り。この数がある理由は、認めておく価値のある失敗にあります。試験装置の最初の版はデコーダーに完全に直角で格子にぴったり合った画像を渡しており、モジュールあたり1ピクセルのコードを平然と読んでしまいました。計算としては本物で、同時に完全な無意味です。スマホを持つ手が絶対に再現しないサンプリングの偶然を測っているからです。各モジュールを任意のサブピクセル位相へ置くのが回転であり、それだけで下限は2倍以上動きました。

デコーダーはあえて弱いものを選んでいる

デコーダーはjsQR、ZXingのコアをJavaScriptへ移植したものです。コントラストの測定のときにソースコードで二値化処理を読んだのと同じ系統のデコーダーです。実際に大半のコードを読んでいるのはAppleのVisionフレームワークとGoogleのML Kitですが、どちらも非公開で、そこから出した数値は読者の誰にも検証できません。またjsQRはほぼ確実に三つの中で最も非力です。機械学習の段も、複数フレームの蓄積も、超解像もありません。

だからこそ、ひとつの較正が意味を持ちます。クリーンな画像での下限はモジュールあたり2.5ピクセルと出ましたが、ML Kitのバーコード読み取りのドキュメントは、コードの「意味を持つ最小単位」が「幅2ピクセル以上、二次元コードなら高さも2ピクセル以上」であることを求めています。より弱いデコーダーがベンダー公表の最小値の4分の1ピクセル上に着地したのは、この種の構成が望みうるほぼ最良の一致であり、後述のサイズ表を「係数単位で悲観的」ではなく「おおむね正しい」ものとして読んでよい理由でもあります。

試験装置が扱っていないもの

  • 実機のスマホ。 この測定でiPhoneもAndroidもテレビに向けていません。光学式手ブレ補正、複数フレーム合成、そして二つの非公開デコーダーはいずれも読み手に有利に働きますが、どれもモデル化していません。
  • フレーム間の映像符号化。 ここでの圧縮は単一フレームのJPEGで、イントラ符号化フレームの代役です。静止したカットの上の静止したコードは、最初のフレーム以降は実際のエンコーダーにほとんど負担をかけません。動く映像に合成されたコードは常に符号化し直されます。どちらにせよ圧縮はほぼ無関係と分かったので、見た目ほど重くはありません。
  • パネルとセンサーの干渉。 ディスプレイを撮るカメラはモアレを出しますし、24pのマスターを60Hzのパネルに載せてローリングシャッターで走査すれば縞が出ます。どちらも実在し、どちらも不利に働き、どちらも再現していません。
  • 映り込み、室内光、斜めからの視聴。 三つとも差し引き方向に働き、三つともコントラストの記事の担当であってこの記事の担当ではありません。
  • 人間。 コードに気づき、スマホを探し、向けるまでにどれだけかかるかは試験装置には測れません。それを扱う節は推定であると明記してあります。

最初の一つを除けば、これらの欠落はすべて同じ方向を向いています。試験装置は静止写真よりコードに厳しく、リビングよりは甘いということです。正直にまとめるなら、これらの数値は崖の位置を示すもので、記事末尾の10分間の手順は、自分のキャンペーンがその崖のどちら側にあるかを確かめる方法です。

下限はモジュールあたり2.5ピクセル

モジュールあたりピクセル数とは、QRコードの格子の1マスに乗るカメラ側のピクセル数のことで、スキャンに関わる他のすべての変数はこの量から支払われます。コントラスト、ボケ、圧縮、ドットゲイン、カメラノイズは、最終的にはどれも同じものを削ります。1マスが白黒の境界のどちら側に落ちたのかをデコーダーが言い切れる確信の度合いです。あるサンプリング密度を下回ると、支払える確信が残っていません。

モジュールあたりピクセル数クリーン圧縮あり(JPEG q40)
1.500%0%
1.750%0%
2.008%7%
2.2569%68%
2.5099%100%
2.75100%100%
3.00100%100%
1セルあたり216試行、直角から1〜11度での読み取り率。崖の幅は0.5ピクセル未満です。モジュールあたり2.0ピクセルは失敗、2.5は確実。

この表で下限そのものより価値があるものが二つあります。一つは遷移の狭さです。辛抱強いユーザーなら読めるという境界コードの長い裾は存在しません。モジュールあたり2.0から2.5の間で読み取り率は8%から99%へ跳ね、つまりコードはサンプリング密度を持っているか持っていないかのどちらかで、その二つの状態を隔てるのはモジュールあたり4分の1ピクセルです。

もう一つは2列目です。マスターをJPEG品質40まで圧縮しても、放送局やプラットフォームが配信するどんな品質よりはるかに低く、目に見えて劣化しているにもかかわらず、結果はどちらの方向にも1、2ポイント動くだけで、崖は一度も動きませんでした。これははっきり言っておく価値があります。「映像圧縮がQRコードを潰す」はテレビでコードが失敗する理由の定番の説明ですが、この測定では単純に事実ではありません。これらのコードを殺しているのは圧縮ではありません。サンプリングです。

したがって問題全体は一つの問いに縮みます。コードは何ピクセル分のカメラを受け取るのか。それはアートワークの性質でもファイル形式の性質でもエンコーダーの性質でもありません。視聴者の目に対してコードが張る角度の性質、つまり幾何学であり、幾何学には予測可能であるという美点があります。

画面サイズは打ち消し合い、残るのは角度だけ

スマホのカメラは中心投影です。つまり既知の距離にある横方向の長さは、たった一つの定数でピクセルに変換されます。水平画角70度、つまり26mm相当のレンズなら69.4度で、スマホのメインカメラは何年も前からその1度以内に収まっていますが、この画角に対する定数は幅1920ピクセルのフレーム上で1ラジアンあたり1,371ピクセルです。こうしてチェーン全体が1行の計算に畳まれます。

モジュールあたりピクセル数 = 1371 × f ÷ (k × N)。fは画面高に対するコードの高さの比、kは画面高を単位とした視聴距離、Nは4モジュールのクワイエットゾーンを含めたコードの一辺のモジュール数です。

この式で興味深いのは、そこに無いものです。画面サイズもメートル単位の距離も入っておらず、あるのは両者の比だけ。これは単純化ではなく実際の物理です。77インチのテレビが広い部屋の奥から張る角度は、43インチが狭い部屋から張る角度と同じであり、カメラはどちらを見ているかを知りもしなければ気にもしません。だから「コードはどれだけ大きくすべきか」への答えは画面に対する百分率になり、同じ百分率がどこでも通用します。

つまりkも当て推量ではなく、公表された視野角の推奨値から決められます。THXは水平視野角およそ40度を推奨しており、16:9の画面ではこれが画面高2.4倍の距離になります。SMPTEの30度の推奨は画面高3.3倍です。どちらも画質を気にする人向けの推奨で、ふつうのリビングはそのどちらよりも後ろに座ります。だから以下の表は画面高4倍まで、つまり55インチを約2.7m離れて見る条件まで伸ばしてあります。

この定数の1920には、それ自体に断り書きが要ります。これは有利な側の仮定だからです。解析ストリームとは、スマホのコード検出が実際に走っている解像度を落とした映像バッファのことで、カメラが撮れるはずのフル解像度の写真ではありません。GoogleのML Kitのドキュメントは「1280x720または1920x1080」を渡すよう推奨し、それより下げるのは「バーコードが入力画像の大部分を占めることを要求する」場合に限って現実的だと注意しています。以下はすべて、この二つのうち良いほうを前提にしています。1280 x 720なら、次の表の数値はどれも3分の1ほど悪化します。

コードは実際どれだけ大きくなければならないか

計算が片付いたので、実測です。各行は画面高に対するコードの高さの百分率、各列ペアは画面高を単位とした視聴距離で、そこから決まるサンプリング密度と試験装置が出した読み取り率を並べてあります。ペイロードは誤り訂正Mの25文字のURL、つまりバージョン3で29モジュール、クワイエットゾーン込みで一辺37モジュールです。すべて静止・圧縮あり・直角から1〜11度ずれた状態です。

コードの高さ(画面比)1080pマスター上k = 2 px/モジュールk = 2 成功率k = 3 px/モジュールk = 3 成功率k = 4 px/モジュールk = 4 成功率
8%86 px1.490%1.000%0.730%
10%108 px1.862%1.240%0.920%
12.5%135 px2.3282%1.540%1.160%
15%162 px2.78100%1.864%1.380%
17.5%189 px3.24100%2.1670%1.620%
20%216 px3.70100%2.4691%1.866%
25%270 px4.62100%3.0899%2.3295%
30%324 px5.57100%3.70100%2.78100%
35%378 px6.49100%4.32100%3.24100%
1セルあたり216回のデコード試行。kは画面高を単位とした視聴距離で、k = 2.4がTHXの推奨、k = 3.3がSMPTEの推奨、k = 4がふつうのリビング、つまり55インチを2.7m離れて見る条件です。中央の列は1080pマスター上でのコードの大きさで、ここが制約になることは一度もありません。

k = 4の列を読んでください。大半の人はそこに座っています。画面高5分の1のコードは100回中6回読めました。4分の1のコードは100回中95回読めました。この設計判断の有効範囲はまるごと画面高の20%から30%の間にあり、慣例の隅の配置はその範囲の下端にあるどころか、2倍から3倍ぶん表の外です。

マスターの列が何をしているかにも注目してください。何もしていません。画面高20%のコードは1080pファイル上で一辺216ピクセルあり、下限をゆうに超えています。コードは編集でもカラーグレーディングでもエンコードでも壊されていません。壊しているのはソファとテレビの間の距離で、これはどんなポストプロダクション工程でも改善できない量です。これは印刷したコードを読み取り距離に合わせて設計する話が紙について述べているのと同じ論であり、視聴者が画面に近づけないぶんここではより厳しくなります。

k = 2の列から出る結論も持っておく価値があります。編集室の錯覚を正確に説明してくれるからです。画面高2倍、つまり55インチを1.4mから見る条件、これは腕1本分の距離のデスクモニターとおおよそ同じ張り角ですが、ここでは画面高12.5%のコードが82%読めます。それが誰もがやっている確認であり、そして合格します。サンプリング密度は距離に正比例して落ち、ソファはテストが行われた場所より1、2m後ろにあります。

サイズより先に、動きがとどめを刺す

圧縮は効かず、サイズは決定的に効くと分かりました。動きはそのどちらよりも悪質です。試験装置はセンサー上で線形の尾引きをかけます。ぼかし関数が使う対称なガウスぼかしではなく、進行方向へのボックス畳み込み、つまり露光中の動きがフレームに実際に及ぼす作用です。そのうえで、読み取り率が崩れるまでにコードがセンサー上をどれだけ動けるかを測ります。

コードの高さ(画面比)モジュールあたりピクセル数静止0.25 px0.5 px0.75 px1.0 px1.5 px
25%3.0899%86%0%0%0%0%
30%3.70100%97%0%0%0%0%
40%4.95100%100%100%0%0%0%
60%7.41100%100%100%100%1%0%
k = 3、圧縮あり。列見出しは1回の露光中にコードがカメラのセンサー上を滑る距離です。4行すべてで、崩壊はコード自身の単位で見ると同じ場所、つまりおよそ8分の1モジュールに来ます。だから大きいコードは見せかけではなく本物の余裕を買えるのです。

許容量はおよそ8分の1モジュールで、カメラのピクセルに直すとコードの大きさ次第で0.25ピクセルから1ピクセルの間です。これは演出が判断できる形に換算しておく価値があります。カメラ1ピクセルは0.042度です。露光1/60秒、つまり明るい画面に露出を合わせた薄暗い部屋のスマホなら、0.25ピクセルは毎秒およそ0.6度の角速度に当たります。それはそれなりに静かに構えた手であって、ソファから身を乗り出す手ではありません。

同じ計算をコード自身の画面上の動きに当てはめると、結果は容赦ありません。画面高3倍の距離では画面高1つがカメラ457ピクセルに対応するので、露光1/60秒で画面上を漂うコードの予算はおよそ毎秒30分の1画面高です。2秒かけて優雅に滑り込むコード、エンドカードへのゆっくりした寄り、合成されたコードの背後で動く手持ちカメラ、跳ね返り、回転、拡大。どれも動いている間ずっと、この予算の1桁から2桁外側にあります。コードは止まるまでただの飾りです。

読み取り率が確率で、サイズ表がそうでない理由

この二つの表には、どちらの表よりも重要な区別が隠れています。小さすぎるコードは決定的に失敗します。どのフレームも毎秒30回同じフレームで、一つもデコードされません。十分大きいが動いているコードは確率的に失敗します。大半のフレームは尾を引き、いくつかは引かず、きれいな1フレームが届いた瞬間にスキャンは成功します。

つまり表示秒数は万能薬ではなく、たった一つの故障モードに効く薬です。3秒の追加は動きの問題に対して90回の追加試行を買いますが、サンプリングの問題に対しては何一つ買いません。制作のブリーフを書く人にとって、この記事で最も役に立つのはここです。コードが十分大きく静止していればほぼ即座に読まれますし、小さすぎればコマーシャル枠いっぱい出しておいても読まれません。

広告が自分のコードを無自覚に縮める二つの方法

ここまではすべて、誤り訂正Mの25文字のURLを前提にしてきました。この二つの前提はどちらも日常的に破られ、しかも手助けしようとしている人の手で破られます。破れ方も同じです。モジュールが増え、画面上の物理サイズは変わらず、各モジュールが小さくなります。

トラッキング文字列

キャンペーンのURLはメディアエージェンシーから計測パラメータ付きで届きます。そうしないとキャンペーンの効果が帰属できないからです。それが格子に何をするかを見る人はいません。

URL文字数バージョンモジュール数モジュールあたりピクセル数読み取り率
自社ドメイン上の短いリダイレクト122254.15100%
スキームまで書いた短いURL273293.70100%
読みやすいキャンペーンURL464333.3493%
同じURLにUTMパラメータ付き936412.8077%
同じURLに完全なトラッキング文字列付き1579532.2548%
5件とも画面高30%、k = 3、静止・圧縮あり。この記事のどの閾値も余裕で超える、たっぷりした大きさのコードです。変わっているのはペイロードだけ。1行あたり60試行。

完全なトラッキング文字列は、他の点では正しく設計されたコードの読み取り率を半分にします。しかもそれをやるのは、マーケティングチームがキャンペーンを測ろうと最も努力している、まさにその瞬間です。この題材全体で最も自滅的なパターンの有力候補でしょう。解決策は効果測定を諦めることではありません。自社ドメイン上の短いパスをパラメータの前に置き、パラメータはコストがかからないリダイレクト側で付ける。それだけです。借り物のリダイレクトがキャンペーンの寿命を通じて実際にいくらかかるかは別の議論ですが、行き着く推奨は同じです。

誤り訂正を上げること

もう一つの反射的な対応は、読みにくい状況なら冗長性を増やすべきだという理屈で誤り訂正レベルを上げることです。これは間違ったレバーであり、しかも有害です。コントラストが低いときに間違いなのと同じ理由で、冗長性をモジュールを増やすことで作り出すからです。そして不足しているのはモジュールのほうです。

誤り訂正バージョンモジュール数画面高25%での成功率画面高30%での成功率
L225100%100%
M32999%100%
Q32999%100%
H43374%92%
同じペイロードを各レベルで、k = 3、静止・圧縮あり。LとMはコストゼロ、Hは大半の広告が使うであろう大きさで25ポイントのコストです。画面が必要とすることのなかった冗長性に、まるごと1バージョンを使ってしまうからです。

Hは、汚れる、破れる、上から印刷される、ロゴで一部隠れるコードのためにあります。テレビ上のコードはそのどれでもありません。ピクセル単位で完璧に配信され、そのあと過少サンプリングされるだけです。過少サンプリングは誤り訂正ブロックが直せる損傷ではありません。そもそもモジュールが読まれるのを妨げてしまうからです。画面ではLかMを使い、浮いたモジュールを1マスを大きくすることに使ってください。復元能力とモジュールサイズのトレードオフはここでもそのまま成り立ちます。画面は単に、冗長性の価値が最も低い側の端にいるというだけです。

時間は、誰も書き出さない予算

この節は実測ではなく推定です。数字の後ではなく前にそう断っておきます。人がテレビに反応するまでにどれだけかかるかは試験装置には測れませんし、その調査は行っていません。

視聴者がこなさなければならない手順は短くありません。コードに気づき、行動する価値があると判断するのに1〜2秒。スマホを取り、ロックを解除するのに2〜4秒。カメラまでたどり着くのにさらに1〜3秒、直前に開いていた画面から始まればもっとかかります。テレビを画角に収め、オートフォーカスが落ち着くのを待ち、静止するのにさらに2〜4秒。ゼロからだと合計6〜13秒で、相手は通常3〜5秒しか出ていないエンドカードです。

これには本物の緩和要因が一つあり、それは正当に評価されるべきです。テレビのかなりの部分は、すでにスマホを手にしている人に見られています。取り出す手順が消え、ロック解除もほぼ消えます。おそらくこれこそが、テレビでQRコードが機能すると誰かが考えた理由のすべてです。この形式が存在してよい強い論拠ではありますが、3秒でよい論拠ではありません。最後の二手順、つまりカメラまでたどり着くことと、狙って静止することは、すでに手にあるスマホでは短くならないからです。

私たち自身の推奨を、あくまで意見として述べます。静止した正しい大きさのコードで8秒。それがブリーフに書く価値のある最低ラインで、クリエイティブが8秒を譲れないなら、そのクリエイティブはコードを飾りだと決めたということです。それは正当な判断です。ただ、偶然そう決まってしまい、あとからスキャン率として測られるべきではありません。

誰もが覚えているあの広告は、計算に従っていた

これら全部に対する有名な反例が一つあります。そしてそれが有名なのは、まさにこの記事が推奨することを一つ残らずやったからです。2022年2月、Coinbaseはスーパーボウルで60秒のCMを流しました。中身は、色を変えながら真っ黒な画面を漂うQRコードだけです。当時VarietyとCNNが報じ、後者は誰もが覚えているくだり、つまりランディングページへの流入が多すぎてアプリが落ちたことを伝えました。

これを上の表と並べてみてください。コードは大きかった。フレーム全体が与えられていたからです。コードは単独だった。だから視聴者の注意にもエンコーダーのビットにも競合がありませんでした。4秒ではなく60秒出ていた。デコーダーがきれいな1枚を見つけるのにおよそ1,800フレームあった計算です。そしてカットや拡大ではなくゆっくり漂っていた。これは動くコードを、速い動きなら収まらない露光あたりの尾引き予算の内側に留めます。

この広告がやったことで、この記事が止めるであろう唯一の点は色替えです。しかしそれさえ見た目ほど無謀ではありません。パレットは終始、明るい地に暗い、または暗い地に明るいを保っており、中間トーン同士を組み合わせてはいませんでした。それこそが色付きのコードがカメラを生き延びるかどうかを実際に決める分かれ目です。この広告がやらなかったことは、小さなコードを隅に4秒置くことでした。

結論は、どのブランドもスーパーボウルの60秒を買うべきだということではありません。テレビでQRコードが機能する証拠として必ず引かれるあの広告は、物理法則を満たすことにクリエイティブ予算を全部つぎ込んだ広告だった、ということです。エンドカードの隅のコードの前例として引くなら、それは通常この広告に語らせたい内容の逆を証明しています。

自宅のテレビで10分で試す

上の数字はすべて、シミュレートしたカメラと、人々がポケットに入れているものより弱いデコーダーのための数字です。特定のキャンペーンにとって意味を持つ数字は、そのキャンペーンの完成ファイルを本物の画面で本物のソファから読ませて出る数字であり、それは10分で手に入ります。

  1. マスターではなく、納品ファイルを再生する. 本物の納品物を本物のテレビに出します。キャストするか、USBメモリーから読ませるか、配信先のプラットフォームに限定公開でアップロードしてください。キャリブレーション済みモニターでProResマスターを確認するのは、すでに合格していて何も教えてくれないテストです。
  2. 人が座る場所に座り、比を書き留める. 画面からソファまでの距離を測り、画面の高さを測り、割ります。その比が上のすべての表のkであり、自分の結果を表と比べられるようにする数値です。3から4.5の間ならふつうの部屋です。
  3. 純正のカメラアプリ2台でスキャンする. iOSを1台、Androidを1台、スキャンアプリではなく内蔵カメラで。スキャンアプリは純正より寛容で、観客が読めないコードを通してしまいます。各端末に5秒だけ与えてください。エンドカードが与えるのもそれだけです。
  4. 雑なやり方でやる. 片手で、だらしなく座って、肘をどこにも支えずに。丁寧にやった結果は結果ではありません。1回の露光中のカメラ0.25ピクセル分の動きが動きの予算のすべてで、肘を支えるだけでそれ以上の価値があります。
  5. 何かを結論づける前に対照試験をする. 近づいて、同じ静止フレームを1mからスキャンします。それが失敗するなら、問題はサイズではなくコントラスト、クワイエットゾーン、ペイロードのどれかで、コードを大きくしても直りません。
  6. 2回連続で通るまで5%刻みで拡大し、そこからもう1段上げる. コードを画面高で5%大きくして書き出し直し、2台ともソファから2回連続で読めるまで繰り返します。そのあと、もう1段上げてください。その最後の1段が、試験に含まれなかった端末、部屋、視力のための余裕です。

返ってきた答えが「コードには画面の3分の1が要る」だったなら、それが本当の答えです。そしてそれは、キャンペーンの報告書の後より撮影の前に持っているほうが価値があります。

代わりに広告へ入れるべきもの

この記事が最後に置く推奨は、タイトルより狭いものです。動画広告のQRコードは無用ではありません。画面の面積と秒数という意味で高価なだけで、そしてQRコードを使う広告のほとんどはそのどちらの代金も払うことを拒み、あとで形式のせいにします。

  • コードを使うなら、画面高の4分の1から3分の1と、静止した8秒を与えること。 実際にはそれは、コードがエンドカードの上の飾りではなくエンドカードそのものになるという意味です。推奨はこれで全部で、ここにある他はすべてその帰結です。
  • ペイロードは25文字程度までに抑えること。 自社ドメイン上の短いパスにし、トラッキングパラメータはコードの中ではなくリダイレクト側で付けます。これは他のどの単独の変更よりも価値があります。何も犠牲にせずモジュールを買い戻せるからです。
  • 誤り訂正はHではなくLかMを使うこと。 画面ではコードは無傷で配信され、そのあと過少サンプリングされます。過少サンプリングに冗長性は効きません。
  • 動かさない、拡大縮小しない、回さない、滑り込ませない。 動きの予算はカメラ1ピクセルをかなり下回り、どんなアニメーションもそこから桁違いに外れます。アニメーションはカードの他の要素に付けてください。
  • 主にスマホで見られる広告なら、コードは使わないこと。 広告を再生している画面が、それを読まなければならない画面です。2台目の端末は存在しません。プラットフォームが用意しているタップできる形式を使ってください。
  • 代わりに、読み上げて表示もする短いURLを検討すること。 覚えやすいドメインを声で読み上げ、文字でも出すなら、最小の角度サイズは存在せず、動きにも耐え、スマホの画面でも機能し、視聴者に何かを静止させることを求めません。接触あたりの転換率は劣り、失敗の仕方は絶対的ではありません。4秒のエンドカードなら、その取引はたいてい正しい向きです。
  • 映画館は知っておく価値のある例外です。 テレビの隅を却下するのと同じ計算が、劇場では気前よく働きます。スクリーンはどの席から見ても格段に大きな角度を張るからです。家では望みのないコードでも、映画館のスクリーンなら控えめな大きさで足ります。

自分たちの道具について正直な注記を一つ。この記事はいま、自分の道具ができないことを推奨したからです。円形やカスタム形状のQRコードが作れる無料のQRコードジェネレーター、KoloQRは、誤り訂正をレベルHに固定しています。格子の中央にロゴのための領域を空けており、その領域の代金を払っているのがHだからです。中央にマークの入った印刷用コードにとっては正しい既定値で、画面にとっては誤った既定値です。したがって動画広告のためにジェネレーターから書き出したコードは、必要より1バージョン多く背負っています。画面高3分の1なら測れるほどのコストにはなりません。5分の1なら、5分の1が機能しない理由の一部になります。

以上すべての限界は冒頭で述べたとおりです。私たちが測ったのはソフトウェアのチェーンであって、リビングではありません。このためにテレビへ向けたスマホは1台もありませんし、使ったデコーダーはあなたの広告を実際に読むものより弱い。つまり本当の崖はこれらの表の数値より上ではなく下にあります。これらの表の役目は、隅のコードがその崖のどちら側にあるかを伝えることであり、そしてそれは際どい判定ではありません。

QRコードを作る

無料、アカウント不要、透かしなし。形を選び、ロゴを重ね、コントラストを確かめて、SVG・PDF・EPS・PNGで書き出せます。サブスクリプションの要らない静的コードです。

QRコードを作成

Questions? Answered

画面高のおよそ4分の1から3分の1です。私たちの測定では、ふつうのリビングの距離で画面高25%のコードは95%読め、30%のコードは毎回読めた一方、20%は6%しか読めず、それより小さいものは読めませんでした。答えがセンチメートルの寸法ではなく比率になるのは、大きいテレビほど人が遠くに座るからで、同じ百分率がどの画面でも通用します。

カメラがコードの格子の1マスあたり十分なピクセルを得られていないからです。デコーダーはモジュールあたりカメラ約2.5ピクセルを必要としますが、3mから見たテレビの隅サイズのコードが届けるのは約1ピクセルです。この失敗は段階的ではなく、機能するかまったく無理かの遷移はモジュールあたり0.25ピクセルほどの幅しかありません。だからコードは即座に読めるか、まったく読めないかのどちらかで、どれだけ長くスマホを向けても変わりません。

思われているよりはるかに壊しません。マスターをJPEG品質40まで、放送局や配信プラットフォームが届けるどんな品質よりずっと低く圧縮しても、読み取り率は1、2ポイント動いただけで、失敗の閾値はまったく動きませんでした。テレビでQRコードを壊しているのはエンコーダーではなく、画面と視聴者の間の距離です。それはビットレートでは直りません。

最低8秒。これは実測ではなく意見です。視聴者はコードに気づき、スマホを見つけ、ロックを解除し、カメラまでたどり着き、テレビを画角に収め、静止しなければなりません。ゼロからだと6〜13秒で、通常3〜5秒のエンドカードが相手です。時間の追加が効くのはコードがすでに十分大きい場合だけです。表示秒数は動きの問題への試行回数を買いますが、サイズの問題には何も買いません。

ごくゆっくりならば。動きの予算は1回の露光中でおよそ8分の1モジュールの尾引きで、典型的な大きさのコードならカメラ0.25ピクセルから1ピクセルの間、画面上の漂いに直すとおよそ毎秒30分の1画面高です。スライド、寄り、拡大、回転はそこから1桁から2桁外れるので、コードはアニメーションの間ずっと飾りであり、止まってはじめてスキャンできるようになります。

いいえ、下げてください。誤り訂正はモジュールを増やすことで冗長性を足すので、画面上の大きさが固定なら、モジュールが増えるほど1マスあたりのカメラのピクセルは減ります。私たちの測定では、同じペイロードでもレベルLとMが100%読めたのに対し、レベルHは74%でした。Hが画面では決して起きない損傷の修復にまるごと1バージョンを使ったからです。過少サンプリングは誤り訂正が直せる損傷ではありません。そもそもモジュールが読まれるのを妨げるからです。

動画広告が使う大きさでは、かなりします。46文字のキャンペーンURLは33モジュールのコードですが、同じURLに完全なトラッキング文字列を付けると157文字・53モジュールになり、画面上の大きさを固定したまま私たちのテストでは読み取り率が93%から48%へ落ちました。コードには自社ドメイン上の短いパスを入れ、パラメータは無料で付けられるリダイレクト側に回してください。

めったに機能しません。しかも理由はサイズとは関係ありません。SNSの動画の大半はスマホで見られており、広告を再生している画面が、そのコードを読まなければならない画面そのものです。向ける先の2台目の端末が存在しません。プラットフォームがタップできるリンクを用意しているなら、そちらが明確に優れています。コードが意味を持つのは、実際にテレビやデスクトップの画面で見られているSNS動画だけです。

映画館は好条件です。計算は視聴者から見てスクリーンが張る角度だけで決まり、映画館のスクリーンはどの席からでも、ソファから見たテレビよりはるかに大きな角度を張ります。だから控えめな大きさのコードでも十分機能します。看板は条件の幅が非常に大きく、一つずつ計算する必要があります。歩道から50m離れた大型スクリーン上のコードは、腕を伸ばして持ったスマホ大のコードより小さな角度しか張らないこともあります。

納品ファイルを本物のテレビで再生し、観客が座る場所に座り、iOSとAndroidを1台ずつ、片手で雑に持った内蔵カメラアプリでスキャンしてください。各端末には、エンドカードが視聴者に与えるのと同じ数秒だけを与えます。編集モニターやノートパソコンで行うテストはすべて合格します。それらの距離はソファより2〜3倍近いからで、まさにそれがこの問題が制作を生き延びる理由です。

KoloQRを選ぶ理由

  • ウェブサイト、メニュー、Wi-Fi、PDF、名刺用のQRコードを作成
  • 色・ロゴ・オリジナルの形をカスタマイズ
  • 高品質なPNG・SVGファイルをダウンロード
  • 印刷にもデジタルにも対応
QRコードを作成
シンプルな黒いQRコードと、同じコードをブランドカラーの円形にデザインし直したもの