Links for events: badges, lanyards and the schedule that moves

Everything printed for an event is printed before the event knows what it is. The schedule shifts, a speaker cancels, a room floods, the Wi-Fi password changes at 9am on day one. The badges went to print three weeks ago.

The only way that ends well is if nothing printed contains an answer. It contains a pointer, and the answers live somewhere you can rewrite from a phone in a corridor.

What goes on the lanyard

One code, one destination that you own, and a link you can edit.

gc.mw/sched on 400 lanyard backs, pointing at the schedule page. When the schedule page fell over on the morning of a conference we worked on, the destination was re-pointed to a static PDF on a different host in about ten seconds. The redirect cache invalidates on save, so the change was live before the next scan. Nobody in the hall knew.

That is the whole argument, and it happens at roughly one event in four.

Print the URL under the code as well. Some attendees will not scan, a phone in one hand and a coffee in the other makes scanning awkward, and gc.mw/sched is short enough to type. Our alphabet drops 0, O, I and l, so nothing on the lanyard can be misread across a crowded room.

The vCard, which beats every badge scanner

A vCard is a plain text contact file defined by RFC 6350. A QR containing one drops your name, title, company, phone, email and website into a phone's contacts with a single scan and no typing.

gc.mw/@you.vcf is the file, gc.mw/@you.qr is the code for the page that holds it. Print the code on the back of your card and on your badge.

The comparison worth making is against the app-based badge scanners most events sell. Those work only inside the event, only for people who installed the app, and the data lands in an export you get four days later. A vCard QR works for anyone with a camera, immediately, and the contact stays in the phone long after the app is deleted.

A worked example: five codes, one destination

A trade-show exhibitor pointed everything at the same product page and gave each placement its own code.

gc.mw/ev1 on the stand backdrop. gc.mw/ev2 on the table cards. gc.mw/ev3 on the slide deck shown in the theatre. gc.mw/ev4 on the printed one-pager handed out. gc.mw/ev5 in the follow-up email sent that evening.

Day-one results, read at breakfast on day two: the table cards outperformed the backdrop by a factor of four. The stand was rearranged before the doors opened to put more cards at standing height. Day two beat day one by a comfortable margin on the same footfall.

The follow-up email code told them something else. It collected clicks for eleven days after the event, long past the point everyone had stopped thinking about it, which changed how the next event's follow-up sequence was scheduled.

None of that needs a badge scanner, an app, or a data export. It needs five codes and someone reading them over coffee.

Scans and clicks are different questions

Every QR encodes the short link with a ?qr marker, so a scan from a table card and a click from the follow-up email are separate events. That split is what lets you compare print against digital honestly instead of adding two numbers and calling it engagement.

It also survives the thing that ruins most event measurement: the same link being shared onward. When an attendee forwards your one-pager PDF to a colleague, the resulting clicks arrive without the QR marker, and you can see that the print piece is still working weeks later through a channel you never paid for.

Make the contact file first

Name, title, company, phone, email, website, out comes a .vcf file and a QR that installs it. Nothing is uploaded; it renders in your browser.

For everything else at the event, create the links a week early, print the SVGs from gc.mw/code.svg, and check every code on a paper proof at the distance people will really stand. The QR code product page has the sizing detail, and link-in-bio covers the page your badge code should probably point at.