Yes we can! On creating the language of proximity

Building a tagging taxonomy for the proximity industry

January 11, 2016

Share this article

Recent figures from Proxbook shows that we are as an industry on track to 400 million deployed beacons by 2020, as forecasted by ABI Research mid 2015When we founded Unacast in late 2014 that number was 60 million.

After Google entered the space with their Eddystone standard in 2015 to compete with Apple’s iBeacon, coupled with the proximity industry moving into maturity, we have seen an enormous growth in proximity solution providers (PSPs), products, use cases and verticals. With such rapid growth, fragmentation can become an issue. As the backend of proximity, this is something we in Unacast think about every day.

In this blog post I wanted to share high level how we work to minimize fragmentation by creating a shared language. But first, let’s go on a journey together.

First there was Proxbook

This fragmentation was obviously an issue from the perspective of the potential clients of PSPs, as retailers, brands and other physical location wanting to engage with sensors and proximity had a hard time making sense of the industry. Confusing technological terminology, lack of visibility and the sheer amount of players were all barriers to entry for potential buyers of proximity solutions.

So, we created Proxbook, the world’s largest proximity directory, and started the massive undertaking of aggregating the whole industry in one platform. Currently over 240 companies have created an account and we are just days away from launching version 2.0 together with the third iteration of the Proxbook Report, this time for Q4 and also summarizing 2015. And here is an early reveal for you: Eddystone is seeing continued rapid growth.

In Q1 we are furthering reshaping Proxbook to function as the number one destination for retailers and brands that wants to engage with proximity and proximity marketing. Stay tuned.

Download: Proxbook Report for Q3 and be the first to get the Q4 report

Then there was Location Control

With a vast amount of PSPs handling vast amounts of end user interactions, we quickly concluded that privacy and transparency would be a driver in the growth and success of the industry. We also concluded that no single PSP would probably be able to provide sufficient tools for managing that at scale, and that we needed to create something for the entire industry. Location Control is that tool, and will offer a cross-company privacy tool so that end users can see and delete data (if desired) at one destination.

Location Control is currently in beta and scheduled for release in 2016.

Check out: Location Control and sign up for the beta

Now we’re ready to do something about the language barrier

With language we of course mean tagging and tagging taxonomies, and here in Unacast we believe the true potential and future product development to be hinging on the ability to understand data across physical locations and PSP’s. This way we make ourselves as an industry attractive to bigger global brands as well as apps or other ecosystems wanting to tap into the power of precise proximity data sets.

How do we go about solving this? Well, it all starts with building a network of proximity companies so that more players can adopt the same structures, and luckily we already operate PROX, the world’s largest proximity network with 31 companies (edit: the number is 35 companies as of 17.01.16) and over 1 million sensors. So you could argue we had an unfair advantage there.

From here it gets more complicated, so I’ll divide it into four steps.

Move proximity data integration from interaction to sensor

The typical point of data collection is today the interaction itself. Where the end user through an app, and in the future through the OS itself as with Eddystone, interacts with a sensor, triggering the phone to send and receive the information set to be triggered in the PSPs CMS system. Our PSP partners then connect those data streams to our backend, to link to relevant digital channels to provide true omni-channel services including both physical and digital.

This has some limitations. First of all, the full tagging structure and taxonomy has to be fully distributed at each interaction, upping the amount of data sent, but perhaps more worrying also creating potential confusion in comparing one interaction to the other (If everything is new every time, how do they compare to each other and to the previous interactions?).

The first tasks we had to solve was therefore to build a new (code name) Sensor API that connects directly to all the sensors in the PROX network (and also later on beyond the network) so that each sensor is properly tagged according to a hierarchy that takes into account everything from the zoomed out lat/long to the zoomed in product itself. This sensor API brings all sensors online, tagged and comparable. With the added bonus of minimizing the interaction API to only sending newly added info provided by the interaction itself, e.g. the GAID (Google Advertiser ID) or IDFA (IDentifier For Advertisers on iOS) or other phone and/or user specific data sets.

Expand and add value to incoming data

A PSP at the end of the day has one primary mission, and that is to find and sign new retail and brand partners that want to pay for proximity products. You know that, and we know that.

When we build our taxonomy products we therefore have to build around the fact that there will be times with poorly tagged sensor and interaction data, and there will be times when the data is not tagged at all. Because getting this aspect perfect is not always the main focus of the PSP.

We have therefore invested in building our own (code name) Data Expander, that based on spelling and synonym recognition populates the data sets with the natural missing tags, also to compare similar words across geographies and companies (trousers = pants). In addition, it will fill in gaps where the data sets allow for automatic population of other fields (like lat/long will give you everything you need on the geography even if e.g. the city is not specifically mentioned). This last point is more of a hygiene factor, but still important to keep data sets enriched and usable.

Lastly we have built a (code name) Relation Expander, where we through smart algorithms (secret sauce warning) can both go upstream and downstream in the tagging hierarchy to automatically understand that those “NIKE” shoes should be part of the top category “shoes”, and “sports wear”.

And best of all, through our (code name) Tag Feedback Tool we will at agreed intervals ping our partners to have them confirm that our suggestions are the optimal ones, so that we over time become smarter as an industry. These improved data sets are of course provided back to our partners through our APIs so that they can improve their own CMS and analytics products. That way they get happier customers, win more deals and get more and better data.

Translate incoming data to a shared language and to languages used by other platforms

With the proximity industry connected to the same tagging taxonomy and language, we need to make sure that this language is understood by others. And just as we can’t expect PSPs to manually change their system and processes over night, we can’t expect the same from data and media platforms. We therefore built the (code name) Tag Translator, that takes the slices and diced data sets described in point one and two, and understand the connection between these and the taxonomies used by our partners. For this we have built our own taxonomy, based on the most well functioning digital data taxonomies out there and added the bits and pieces that are uniquely important for our industry.

This Tag Translator can both ingest our taxonomy directly into other platforms (as some allow for direct pass-through) or connect and correlate to relevant tag or tag categories in the case specific platform of choice.

And best of all, this enables full backward compatibility, a partner agnostic approach and future proofing. Our partners should not worry about how well their data sets are tagged for future use, as we have built systems that safe guards that perspective. And as we mentioned in point 2, all of these improved data sets can be ingested right back into the PSP’s platform.

Media platform integration

Lastly we take care of connecting all of these neatly packaged data sets to the relevant data and media platforms that fits the specific use cases. We won’t go into further details on that topic in this blog post, as we have covered it previously.

That said, stay tuned for some big reveals in Q1 regarding the power and size of our distribution network.

Yes We Can

If you want to contribute in our quest to create the language of proximity, please get in touch or comment below. We are eager to work with the smartest people out there, as we view this effort as an industry need and vital for our shared future success.

Say it after me. Yes (together) We Can.