Using the Grip app for badge scanning at your event can be a powerful tool for exhibitors and visitors to collect leads efficiently. Here's a breakdown of how to make the most of badge scanning with Grip:
Getting Scan_IDs populated correctly
Grip scans badges based on the "Scan_ID" that is associated with an individual user's profile on the platform. Scan_IDs typically get added from the registration system but can also be added from the Grip Dashboard.
Below is a schematic overview of the different integrations and where data consistency is important. As you'll see the registration system is the source of the data. From there it goes to two places; the Grip system, and your badge printing provider. From there, it is important that the scan_id is printed onto the Attendee Badge.
The correct scan_id being used to print onto the Attendee Badge is what enables a user in the Grip App to scan the badge of the user and "read" the Scan_ID of the user.
Making sure the badges print the right "scan_id" as the QR/Barcode
Now that you've completed your integrations it's worth checking whether the scan_id is correctly flowing through the different systems. The easiest is to create a dummy account in your registration system, see if it's correctly picked up by both Grip and your Badge Printing Provider either by sharing a csv file or through an API integration.
From here, simply create a PDF of an example badge within the system of the Badge Printing Provider and share this with your Grip Project Manager. They'll be able to test and confirm whether the Scan_ID is indeed correctly shared between the different systems.
It is important that the "Scan_ID" is on the badge as one of the below image types that we currently support:
- 1D barcodes: EAN-13, EAN-8, UPC-A, UPC-E, Code-39, Code-93, Code-128, ITF
- 2D barcodes: QRCode, Data Matrix, PDF-417, AZTEC
Maximum character length for barcodes are following:
- 1D barcodes: 85 characters
- 2D barcodes: 128 characters
The Importance of Complex Scan IDs
Some registration systems will have sequential “Scan_IDs” that get printed onto people’s badges, this means that a participant might have Scan ID “11111” and the next participant might have “11112”.
As you can imagine, once a nefarious actor has gained an understanding of the sequential numbering they could create fake QR codes to start creating scans between themselves and other event participants without actually knowing them.
Grip recommends at least 10 characters, randomised alphanumeric Scan_IDs. Spaces are not allowed.
We’ve got rate limiting and advanced monitoring in place to catch nefarious actors but sequential scan_ids make it substantially harder to catch incorrect usage of this feature by event participants. To minimize risks associated with lead retrieval we strongly recommend only turning on lead retrieval on event days and disabling it on other days.
Scan IDs vs. Badge/Registration IDs Guidelines
For security reasons, our advice is to use separate Badge/Registration IDs compared to Scan_IDs. While this might complicate the participant experience, we believe it is important from a security perspective.
Our advice is at least a 6-character randomised alphanumeric ‘Badge/Registration ID’ never printed on the the badge.
For the “Scan_ID” we recommend it to not be printed in text but only available as a QR or Barcode on the front of the badge.
Deciding who's able to scan who
Thanks to the advanced permissions on Grip you can control which Data Types can scan each other. For example, you could only allow Exhibitor Representatives to be able to scan Visitors. Or maybe only allow Visitors to scan Exhibitor Representative and their Products.
Discuss the permissions with your Project Manager and make sure you get this set up before you go to the last and final stage.
Testing the scanning functionality
The last but probably most important step is doing a full test. Just as in step 2, create a registration record, see if it is properly picked up by the different system and using a Grip test user see if you can scan a badge either a printed one or a PDF that is open on your computer screen.
If you are able to export the scanned user correctly from the Grip web platform after this you can be sure that badge scanning has been implemented correctly!
FAQ
Are badge scan ID's, reg ID's, and email scans case sensitive, if I have two the same but one has capital letters and the other doesn't will these be separate?
Badge scan ID's, reg ID's and email scans are case insensitive meaning if two are the same and one is in capitals and the other is not, they will be the same and will not be recognised as two separate scans and/or profiles.
Can Grip be used for Access Control onsite at an Event?
The Grip Session Check-in functionality cannot, under any circumstance, be used for Access Control at an event. The reasons for this are:
- Onsite registrants would want access onsite <10 seconds after printing their badge. As Grip does not do badge printing as part of its solution it will be practically impossible for Grip to have records fast enough to be used for scanning people into the venue.
- None of the reporting in Grip for our Session check-in is suitable for access control management onsite.
- If there is poor/ no wifi onsite, Grip's badge scanning will store the ID locally and sync it when an internet connection is restored. This means it's possible for people with fake badges to gain access to the venue.