Play, Collect, Redeem

This post is a follow up post to the physical endeavors we’re currently undertaking. We’re not only looking into “physical” because making is a huge trend, we also believe there are many interesting applications when it comes to in-store usage. Prototyping with electronics and other physical components gives us the required knowledge to build up prototypes around in-store ecommerce. One example is couponing. How would you use in-store couponing to drive sales to your online or offline store? How can a social profile be merged with coupons and used to gain insights or create viral coupon campaigns? What are the elements of coupons, the characteristics and how do users collect and redeem these coupons?

Our prototype explores exactly this.

The big picture – Play, Collect, Redeem


The somewhat  🙂 technical architecture below shows the key components and how the are linked together for form a couponing system. Customers can play physical games, then collect coupons that they can later redeem for products (or get discounts, etc.). Let’s take a look at each component, seperated via the swimlanes in the below graphic. For the better understanding, we begin with the physical gaming frontends.

hybris Coupons (1)

Physical Frontend

The physical frontends are easy-to-play games that customers will love to interact with and try out. These games are crossover projects between gaming, art and technology. The games include a physical keyboard (via PVC foil and capacitive sensors), a push-button game and a foosball table (kicker) which we put light barriers inside to get the scores.

We designed the system in a way, that only “authenticated” frontends can be used to obtain coupons from the backend. This authentication is done via a simple shared secret (more complex scenarios possible), but the shared secret is not in the web app or otherwise saved in resources that can be accessed from the web. The shared secret is part of the Arduino hardware and trasmitted via a set of keystrokes to the web frontend. That means, only if you are in the posession of the physcial game and the Arduino prototyping board, you can obtain the access token to the coupon backend.


Web Frontend

The web frontend is used to receive the game inputs from the physical games, receives the authentication key from time to time and is used to display the coupons. At a later stage, we will also use it to show the game rules to the users of the game (right now these frontends are very basic, ready to be skinned by an CSS guru!).

Via the web, or mobile web, users can also “sign-in” to a physical game frontend. The users can scan a QR code or scan a NFC tag to be redirected to a facebook login page. Once they’ve authorized our coupon application, their profiles and names appear on the web UI. Later on, these profiles will also be used to share the coupon activity to Facebook and to personalize the received coupon itself. We have all the stuff in place to help coupons generated go viral.
Coupon Backend

The coupon backend is the heart of the system and shared among all three frontends. With the required authentication token from the physcial game frontends, the web apps are able to create new coupons via AJAX calls after the users have played a game. Based on the score, a different coupon is created. Each coupon is unique and protected via a signed URL. This allows the coupon backend to trust incoming requests, as the secret for generating the URL signature is known to the backend only. If you get a coupon, tamper with the URL and try to view or redeem it, it won’t work.

The three main RESTful/JSON APIs that the coupon backend exposes are the APIs required to create coupons, view coupons and later redeem coupons. The viewing part has different representations – one is pure JSON, meant to be used for mobile clients or other systems accessing the coupon. The second is a web representation, e.g. a responsive web page which holds the coupon as a QR code. The third is an image-only representation, ready to be embedded into a HTML img tag. These three representation make it very easy to integrate coupons into any application.

As an example, we’ve already upgraded our hybris Wishlist Android application with the feature to collect coupons. As it is a native Android application, the QR code or NFC tag is scanned, which transmits the signed coupon URL to the app. The app then resolves the Coupon via the REST api and chooses the JSON representation to obtain access to all coupon data.
Mobile Frontend 

There are actually two mobile frontends: there are the shopping assistants, who scan the coupons and redeem the coupons for the users. They use a simple QR code scanner on any OS to view the coupon. They are the only ones who can mark  a coupon “used” – that means the coupon’s “use count” is increased by one. Once a coupon hits the max use count figure it is no longer valid.

The other frontend, used by normal users, is either a web representation of the coupon or a mobile app, such as our Android-based coupon app. The benefit of the app is that you can collect multiple coupons, store them, revisit them and later redeem them.


So far so good, what’s next…

We got a lot of essential systems in place, but there would be a lot of opportunity for further research. Think about data analysis, different coupon/product combinations, geofencing wishlist items and coupons or just coupon variations (one-off coupons, product segment coupons, single product coupons, shareable/viral coupons, etc.).

We’ll also go on a roadshow to present all this. First stop will be Derry in the UK for a technology and art festival. Next up might be a swiss conference which is not yet finally approved. All these conferences and presentations will help us to interact a lot with real users, potential customers of hybris systems and also end-users. It’s a great, playful and uncomplicated way to get real and honest feedback. It all begins with a game…



Video: Shopping gets Sexy

During the development and filming of the Guerrilla Shopping and Everybody’s Happy videos we realised that customer engagement with services (and it follows conversion and loyalty) is much higher when the technology disappears. Think about it, if you’re having a conversation with a friend and they’re constantly distracted it’s unfulfilling and blah, something. But that’s exactly what happens when a customer interacts with a website, they have to constantly break off their communication to type or move a mouse pointer. It’s one of the main reasons why iPad b2c conversions are higher, the customer feels as if they’re interacting directly with the brand, there’s simply less distraction.

So to extend this concept and our NFC-based prototypes we added a gesture based product navigator using the Microsoft Kinect platform and we added Geo-Fenced alerts to provide highly contextual, post-discovery, content.

Here’s the teaser we filmed in the studio (which also includes gender detection – watch carefully) and the full version we filmed in Augsburg before Christmas last year.


Video: Everybody’s Happy

We’re proud of our brand at hybris. The logo, the blue and we thought it would be cool to put our technology outside on a sunny day. Blue sky, hybris, this seems like a good fit we thought. It follows that once you start thinking of sunny days and blue skies you start thinking of drinking a cold beer outside. So one lunchtime we set to work imagining ways in which we could take our technology to a beer garden and solve a business problem.

It didn’t take us long but to be clear, we’re not moving into the hospitality software business but it was surprising how many similarities we found.

Combining hybris commerce basics with NFC and Facebook we created a prototype order-taking and fulfilment application with the goal of showing how hybris can empower the offline customer just as if he were online.

Dynamically changing the URL on a NFC tag via a local webserver

When you use your Android / Windows Smartphone to write to a NFC tag, you end up with a static, non-dynamic content on the tag. Let’s assume you have written a URL to the tag – that URL is on a passive tag and will not change until you overwrite the tag. If you use an active NFC Reader/Writer, you can change the content typically via some low-level APDU-based protocol, which is horrible to program against. Until recently, there was really no easy way to dynamically change the content.

One workaround that I have used in the past is to use the NFC tag with static content simply as a trigger to look up the dynamic value from a HTTP server. In this case the NFC tag loads a URL that then redirects to the dynamically set URL. This is a pretty good solution, the only problem can be that the information is out of sync. You now have a roundtrip to the server, receive a redirect and then fianlly load the redirect content.

Since late last year, a new product is available, that I already used a bit and finally blog about it. It’s the DTAG100 – a little USB device that appears as a file system and allows you to change the content of the NFC tag via a simple text file that you overwrite. Right now it can be used to write simple URLs (SmartPosters to be exact, but on my Android phone it never shows the SmartPoster’s Text content, just opens the URL) and also RAW content. RAW could be any NDEF mesage, but you have to come up with the HEX representation of the content.

Here’s a little Groovy class that I used to wrap the updateSmartPoster functionality:

As you can see, I just implemented the setting of the current time by overwriting the timeset.txt file on the USB storage of the device and the updating of the URL stored on the device via the updateSmartPoster Method. Both features can easily be implemented by simply deleting the old file, then writing the new content out to the file via a FileWriter:

As I often use a web browser to build full-screen demos, I then went a bit further and added this logic to a tiny local webserver. This allows me to call a URL like http://localhost:8000/update/ to update the URL to For this, I used the built-in Java HttpServer. A call to /kill will kill the running server so you can make changes to the script and run the server again.

For this local server, that communicates via the DTAG100, I could now write a simple HTML page which communicates with the local server via AJAX. This is very simple and versatile. For example, it could be easily used to write a dynamic product display, that changes the URL based on the currently seen product on the screen. Think of an in-store display or an in-store info terminal.



Video: Guerrilla Shopping

After we demonstrated a prototype NFC powered shopping wall (think Tesco in South Korea on steroids) at the 2012 hybris customer and partner events we wondered what the reaction of normal, off-the-street, consumers would be to the technology.

So we built a portable, roll-up version and ventured out to our nearest beer garden and set up camp. One by one we asked passers by if they’d like to try out a new way of shopping and recorded their reactions to four use cases.

Touch to Install

The NFC tags are encoded with a link to the Android Play store to mitigate the search-for-app/installation process.

Touch to View

Tapping an NFC tag on a product retrieves the product details

Touch to Share

Tapping two phones together users can share products via Android beam.

Touch to Pay

We mocked up a contact-less payment process with a NFC enabled ID tag.

The reaction of our customers, as you can see in the video, was very positive and led us to pursue other NFC use cases.