Physical & Digital Personalisation: The Devil is in the Data Model

At MOO, we have a lot of experience in personalising physical objects. Our core product is business cards that our customers design themselves (sometimes with a little help from us). NFC cards, on the other hand, are personalised in two different ways: physically via the customer’s design, but also digitally via the embedded chip.

Each NFC card has a unique MOO url programmed onto it. When a card is tapped, the phone’s browser opens the url and MOO’s platform performs the action the card’s owner has associated with the card — for example, redirecting to another site or rendering a digital business card. Because of this indirection, the card owner can change the card’s action at will on MOO’s platform.* At present you can specify one action for each design, but we anticipate offering a way to customise each individual card.

A 20 pack of NFC cards can contain up to five different back designs, meaning up to five groups of cards that all look the same. But because of the unique URL on each card, NFC cards that look the same are in fact not the same. This presented a few challenges for us.

You may be surprised to learn that MOO’s data model doesn’t represent cards. More specifically, MOO’s data model doesn’t represent the individual card objects you end up holding in your hand. The finest granularity available is a group of cards with the same design. How could we then track the uniqueness of individual NFC cards? Retro-fitting MOO’s data model wasn’t an option. Given the size and complexity of our existing code base, this approach would have been prohibitively time-consuming.

In the end we took a service-based approach, storing the per-card information for NFC cards in a group of brand new, self-contained micro-services. This gave us complete flexibility to design our project’s internals in the way we needed, retaining 100% control over our own code while providing minimal disruption to the existing codebase and workflow. We hope we can gradually migrate all of MOO’s code to services, but this will be a large undertaking. In the meantime the NFC services will be able to carry on as they are, more or less unaffected by the architecture of the larger code base.

We may have solved the software challenge of tracking individual cards, but we also faced a challenge in the physical production and shipping process. Like any business that makes products for customers, we sometimes experience accidents during order fulfilment. Our quality control process turns up a printing fault, an NFC chip or three throws a write error, a package gets lost in the post. Whatever the reason behind the problem, we need to be able to correct it by reprinting the affected cards.

Reprinting a non-NFC pack is straightforward — we simply generate a new print job for the item and queue it up. If the customer ultimately ends up with two copies of the same pack, e.g. because an item was lost in the post but later found and delivered, this is not a problem.

For NFC cards, however, the relationship between MOO and the physical product doesn’t end when the cards are delivered. Through the Manage Paper+ page on our web site, users can re-customise their cards and track tap counts online after the cards are delivered — but only if we can distinguish each card individually. We don’t ever want to get into a position where the same MOO url is programmed onto two different cards. Both cards could end up with the customer, so when reprinting a pack of NFC cards, we can’t reuse the MOO urls from the original pack. We always generate an entirely new set of MOO urls, and the original MOO urls also remain active. This lets us distinguish between the original pack and the reprinted pack so our card management page can do its job.

One of the most important features of any software architecture is ease of maintenance. Does it perform appropriately in production, does it require frequent intervention when things go wrong, and how easily are problems fixed when they do occur? So far, we’ve been pleased with our NFC solution. We’ve experienced relatively few operational hiccups, and when we have found ourselves having to debug a few particularly complicated issues caused by human error in the production process, we’ve found that we have the data to do so.

With hindsight, one aspect of this project particularly stood out for us: data models that are tightly tied to physical objects are hard to change. Micro-services can help by allowing local flexibility without having to retro-fit globally. Overall, we’re happy with our architecture and now we’re tuning and extending our platform to improve speed and add new features.

* But we ship the tags unlocked, so if you really don’t want to use MOO’s platform to manage your cards, you don’t have to.