QR менюта: менюто се променя, кодът остава

QR кодовете за менюта станаха повсеместни през 2020 г. и останаха такива. За повечето ресторанти кодът е бил създаден веднъж от човека, който е поддържал уебсайта, и оттогава не е проверяван — важно обстоятелство, защото именно в ресторантьорството този модел се среща най-често: много кодове, голям обем сканирания, дълготрайни печатни материали и малки маржове.

Защо ресторантите плащат за всяка маса?

Защото таксуването за код се сблъсква с бизнес, който се нуждае от много кодове. Ресторант с дванадесет поставки за маси, стикер на витрината и стикер върху торби за храна има четиринадесет кода. При динамичен план с такса за всеки код това са четиринадесет позиции всеки месец за меню, което преди е струвало колкото хартията.

Абонаментът тук също е необичайно труден за прекратяване. Поставките за маси са ламинирани, стикерите са залепени, а менютата се препечатват най-много сезонно. Препечатването е реален проект, затова месечната такса остава удобно под неговата цена — точно така е избрана и самата цена. Истинската цена на „безплатния“ QR код обяснява тази сметка.

Какво научава доставчикът за вашите клиенти?

Всяко сканиране е HTTP заявка към доставчика, преди да се зареди менюто. Без бисквитки или съгласие той получава IP адреса на клиента, часа, устройството и операционната система, както и предпочитания език — а тъй като всяка поставка за маса има собствена кратка връзка, и информацията на коя маса е.

Събрани заедно, тези данни дават подробна картина на обслужването ви: броя клиенти по часове, времето за освобождаване на масите, кои маси са най-натоварени, моделите през делниците и уикендите и езиковия профил на клиентите. Това наистина са полезни оперативни данни за вашия ресторант, но се генерират от обзавеждането ви и се събират от някой друг.

В рамките на цялата клиентска база на доставчика това означава още повече. Един и същ повтарящ се отпечатък на устройство в ресторанти, магазини и заведения в даден град описва движенията на човек. Съдът на Европейския съюз постанови в *Breyer* (C-582/14), че динамичен IP адрес, регистриран от оператор на сайт, може да е лични данни. Затова въпросът е свързан със съответствието, а не просто с любопитство — и съгласно GDPR отговорността обикновено пада върху бизнеса, внедрил кода. Какво регистрира QR прокси сървърът разглежда подробностите.

Какво се обърква на практика?

Първите три са един и същ проблем в различни форми: менюто зависи от компания, която не е ваша. Четвъртият не е свързан с таксуването, но се влошава от него, защото клиент, свикнал да вижда непознат кратък домейн, няма как да забележи злонамерен.

Оценката на NCSC е, че QR кодовете в пъбове и ресторанти обикновено са безопасни, като много повече внимание е необходимо при кодове, получени по имейл. Оставащият физически риск е надлепеният стикер, а противодействието е прозаично: проверявайте поставките.

Как изглежда вариантът с фиксиран адрес?

А какво да правим с кодовете за поръчки и плащания?

Те трябва да се разглеждат отделно от кодовете за менюта, защото рисковият профил е действително различен и съветът не е същият.

Кодът за поръчка и плащане отвежда клиента към страница, в която той ще въведе данни за карта. Това повишава залога при всеки проблем в тази статия: надлепен стикер върху код за плащане е пряк път към измама с карта, а човек, който не може да разпознае вашия домейн във визуализацията, няма как да отличи страницата ви за плащане от убедително копие. Предупреждението на FTC за стикери, поставени върху легитимни кодове, е насочено точно към този модел в други среди, като паркоматите са класическият пример.

Оттук следват две правила. Първо, кодът за плащане винаги трябва да съдържа вашия домейн или истинския домейн на платформата ви за поръчки — никога общ съкратител на връзки, защото така премахвате единствения сигнал за проверка, с който разполага клиентът. Второ, отпечатайте домейна с четлив текст до кода и проверявайте физическите поставки по график; и двете мерки са евтини и са единствените защити, които работят на масата.

Ако платформата ви за поръчки издава кодовете, декодирайте един и вижте чий домейн е в съдържанието. Някои платформи вграждат директно собствения си домейн, което е приемливо. Други пренасочват първо през съкратител на връзки от трета страна, което поставя допълнителен, неуговорен участник между клиента и формуляра за карта.

Как да преминете към новия вариант?

1. Декодирайте текуща поставка за маса с нашия четец и вижте чий домейн е в съдържанието. Ако не е вашият, използвате наето пренасочване.
2. Изберете стабилен URL адрес — yourrestaurant.com/menu — и се уверете, че няма да се променя. Ако искате възможност да го преместите по-късно, насочете кода към yourrestaurant.com/m и пренасочвайте оттам.
3. Генерирайте статичен [QR код за URL адрес](Url), който кодира този адрес.
4. Добавете проследяване за всяко място, ако желаете: ?src=table, ?src=window, ?src=takeaway. Така собствените ви анализи ще ви дадат същия брой сканирания по места, който ви е продавало таблото.
5. Отпечатайте URL адреса с четлив текст до кода, за да могат гостите да стигнат до менюто без сканиране и да видят, че кодът е ваш.
6. Препечатайте при следващия естествен цикъл, след което прекратете абонамента, когато старите поставки вече не се използват.

Ако кодовете вече са неработещи и клиентите днес попадат на страница за надграждане, ръководството за възстановяване на отвлечен код описва спешната последователност преди препечатването.

Направете замяната сега, за да е готова за следващото отпечатване: QR код за URL адрес. Контекст: истината за измамите с QR кодове.