export Hotspot data
When deploying an hotspot solution, your company may consider to export the data generated to your internal application. In this article I will describe some example of technical manner to implement data export.
The hotspot service will basically generate two types of data:
- Visitors identity: this table store the list of people that did connect on the Hotspot service with the associated data collected: either the data explicitly shared (name, email…) or the data automatically collected (browser language for example)
- Event logs: this is the list of event on the Hotspot with the timestamps, locations, some technical informations (type of device, browser, language) and a link to the user identity
Main consideration when exporting data
Remember that, even if is legally acceptable to collect data, it may not be possible to process this data. However you are exporting the data, you should always check the purpose have been approved by legal department. Moreover, your legal department have to check the providers in charge of managing the target applications/databases apply also regulatory rules according to this processing (integrity, confidentiality, anonymization…).
API call directly from the Hotspot portal
The simplest way to export user data is to add inside the Hotspot portal a http call to some of your applications. Off course, these applications should implement an API reachable from Internet directly but that maybe already the case. This method is the one usually implemented on your company’s website.
Usually the API call is added inside the success page of the Hotspot portal (the last page of the process) for two main reasons:
- User may not have access to full Internet before this step
- You cannot export user data before gathering explicit consent from the user
A few implementation examples:
- Register the user to the company’s newsletter via your service provider (mailchimp or 1000merci for example)
- Send data to your web analytics services to integrate the Hotspot portal traffic into your standards analytics
- Automatically register the user into the e-commerce service
Another variant of the implementation is to add widgets directly in the page (newsletter registration form, facebook like button, last tweets…) for the user to interact directly with the company via the available channels.
API call from internal applications
The data can be also retrieved via a pull method from the Internal applications to the Hotspot solution. Unlike the previous method, this one is asynchronous and the applications should implement a routine to get some data on a regular basis.
This method implementation will highly depend on the applications possibilities in term of scripting and API calls. You may consider using a generic processor (like runmyprocess) to collect once the data from the Hotspot service and dispatch into multiple applications/databases.
A few implementation examples:
- Your CRM can automatically collect new user’s identity in order to fill the CRM database
- If your marketing tools are not reachable from API, you can gather the newsletter registration list via an API call to the Hotspot service
- When using business intelligence tools for advanced reporting, you can consider importing some hotspot data into the tool to create specific cross-channel reports
This method is usually the last resort as it may sound like a very legacy way to import/export data between systems. The idea is to have a script run on the Hotspot system that will compile some data on a regular basis and send it via FTP, Mail or carrier pigeon. Then, the export have to be processed manually or automatically by the target application/team.
The main advantage of this method is the absence of technical dependency between the different stakeholders.
- The Hotspot service can send a csv files with the list of identity for manual report
- The list of identity can be send to each store manager in order to fill manually the CRM
Bonus: host your data directly in your apps
I talked a lot about exporting the Hotspot data into your internal applications but why not having the data directly in your application.
You can, for example, use your website as an identity management for the Hotspot service. Each time a user when to connect the Hotspot he will create an account on your website (via a widget, an API call on the portal or SAML) and then the identity data is directly hosted in your database. This is the ideal scenario that have multiple advantages:
- Your visitor will have the same user experience between Hotspot and your website
- Their is no need to normalize the Hotspot data
- You can extend any website services/tools to the Hotspot (marketing, analytics…)
- Most of the legal assessment done on the website can be re-used for the Hotspot
Processing the data generated by your visitors is the most valuable outcome of the Hotspot service. This is how you can create “augmented data”! But be careful to always comply with the rules dictated by your legal department.