2017 Q1 Updates
The Dashboard has received several feature additions, that increase usability, and numerous performance optimizations, that enhance user experience, during the past three months.
ProximityMX now allows customers to configure time zones for each location separately on the Location Hierarchy. If the time zone for any location is not explicitly configured, a default time zone (UTC) is applied to that location.
Say Trestin Group has defined a Location Hierarchy with Hotel One located in Burbank, California and Hotel Two located in Dallas, Texas. The time zone feature on the Location Hierarchy allows the default time zones for access points in Burbank and Dallas to be set to PST and CST, respectively.
Suppose an LOB manager for the Trestin Group wants to engage customers at 8am everyday with “Complimentary Breakfast” offers. The time zone feature allows a SINGLE Engagement Rule, configured to trigger at 8am local time, to be created for BOTH locations.
Furthermore, if any access point at loses time zone sync with the network for some reason, it will fall back to the default time zone allotted to it. Thus the “Complimentary Breakfast” Engagement Rule would trigger only at 8am local time always, and not at (say) 11pm because of a desyncing error.
Detailed network sync status, for every level in the network hierarchy, is now displayed on the Locations Details page.
This enhancement enables a Network Admin for Trestin Hotel One to individually track the synchronization status for each level to narrow down on any problem nodes in the hierarchy.
For Meraki setups, ProximityMX now enables customers to import security appliances – in addition to access points – to the Dashboard.
Captive Portal Rules
ProximityMX now allows customers to create or modify tags – a feature previously available for Profile Rules only – using Captive Portal Rules. While Profile Rule tags allow visitor segmentation AFTER internet has been provisioned, Captive Portal Rules tags allow visitors to be dynamically segmented, based on multiple custom factors, DURING onboarding.
Thus, a visitor who logs on to the guest WiFi service at a customer location (say Trestin Hotel One) for the first time can be assigned “First Time Visitor” and “Trestin Hotel One” tags using Captive Portal Rules. Engagement Rules could then be configured to redirect visitors with these tags to webpages detailing the services on offer at that location that a new visitor might not be aware of. When the same visitor visits Trestin Hotel One a second time, another Captive Portal Rule could be set up to remove the “First Time Visitor” tag, add a “Repeat Visitor” tag and Seamlessly Provision Internet.
Captive Portal Rules have also received the Trigger API feature addition which was only available with Engagement Rules till now. This allows both Captive Portal Rules and Engagement Rules to call customer APIs with visitor and location context.
Visitor and location context data captured during onboarding like First Name, Last Name, Gender, Email, Mobile No, Location, Device MAC ID, etc can then be passed on to Trestin Hotel One’s CRM systems, enabling the sales team to engage these visitors with hyperlocal content.
Captive Portal Rules can be used by customers to Seamlessly Provision Internet to visitors without having them pass through the Captive Portal at all; or, on the other hand, Deny Internet to visitors outright.
For example, Trestin Hotel One can allow any visitor to seamlessly connect to their free Guest WiFI service at speeds throttled to 250kbps for limited durations (say 300secs). Trestin Hotel One could then offer priced internet packs to those online visitors who wanted faster bandwidths or longer sessions. Any visitor who tried to connect to the free service after session expiry could be automatically denied internet using the Deny Internet feature.
Live Engagement Rules now get their own Engagement Rule Reports. These reports allow customers to measure the effectiveness of their Engagement Rules by tracking the number of notifications sent for the rule filtered by location, time or type. These reports also display the total visitors notified segregated by gender, dwell time, number of visits and so on.
Suppose, Trestin Hotel One has a live Engagement Rule sending out Lunch Discount Coupons through SMSs and emails to all visitors to the location, once every hour, throughout the day. By analyzing the Engagement Rule Report for that rule and comparing the data with the coupons redeemed, an LOB manager for the hotel could infer that only coupons sent out by SMS to visitors, near the hotel restaurants, between 12noon and 2pm every day, were being redeemed. Thus, the LOB manager could tweak the Engagement Rule to engage visitors only between 12noon and 2pm, using only SMSs (and not emails or BLE notifications), thereby significantly increasing the engagement rate for the campaign.
ProximityMX now allows for the creation of location-specific Captive Portals.
Associating a portal to a specific location or a group of locations makes sense for a customer like the Trestin Group of hotels. Having two different Captive Portals, specific to each of Trestin Hotel One and Trestin Hotel Two, allows the two hotels to maintain their location-specific individuality while retaining the broad branding overtones of the Trestin Group.
Welcome Message module now allows addition of Location and Location Metadata variables to the Welcome Message on the Captive Portal, for any authentication type selected. The Repeat Visitor Welcome Message can be enhanced further with First Name and Last Name variables, provided these details have been collected previously via the Data Capture module.
Thus, the LOB Manager at Trestin Hotel One could configure the Captive Portal to greet a particular visitor (say John Smith) with, “Welcome to the Trestin Hotel One, John Smith!” where “Trestin Hotel One”, “John” and “Smith” have been displayed on the Repeat Visitor Welcome Message using Location, First Name and Last Name variables.
ProximityMX now derives country names of visitors from country codes of mobile numbers entered during Authentication or on the Data Capture form. The derived country names are then added as tags to the user in the backend.
Inline validation for email addresses entered during Authentication or on the Data Capture form now happens as soon as the email address is entered.
Finally, Custom Modules have received strict validation checks as well. Custom Modules can now be added and saved on the Captive Portal Menu only if the URL field is populated. Furthermore, the URL itself is validated to see if it has been formatted properly and whether the linked site itself is a valid one.
Reports now have their visibility limited by access rights. Dashboard users will be able to view reports for only those locations they have access rights to.
So, LOB managers for Trestin Hotel One will only be able to view reports for the locations they are associated with; the reports for other hotels in the Trestin Group will not be available to them (unless they are specifically granted access rights to other locations).
Access Code Manager
Enterprise customers using the Access Code Manager authentication system can now reuse access code values of expired access codes. Customers can also exert added control over their access codes by limiting the number of times a specific access code can be used.
V3 Module Group
Customers can now use the V3 Module Group in the Studio to enhance their Captive Portals beyond what is possible through the Dashboard Portal Editor. The V3 Module Group adds support for the following features (on top of the features supported by the V1 and V2 Modules):
- Hard SMS/email authentication with Data Capture Form
- Language support for any language
- Portals configured for Captive Portal Rules
- Portals with location/visitor context variables in new/repeat visitor welcome messages
Customers can now provision internet directly to visitors who have the customer’s app installed on their devices.
Say, Trestin Group has an Trestin App that is already in use by a large section of their visitors. Authentication for these visitors would already have been performed by the app itself. In that case, Guest WiFi authentication through a captive portal would become redundant.
By integrating the Trestin App to the ProximityMX SDK, the Trestin Group could then enable app onboarding for its Guest WiFi services. When a visitor tries to connect to an SSID on this app-enabled network, an app-specific button will be displayed. Clicking on this button would immediately provision internet to that visitor.
The App Launcher custom module, which has been added to the V3 module group in the Studio, can provide the app-specific button on the Captive Portal.
Other assorted enhancements, like
event logging for country name, dial code and browser language,
a custom 404 page,
support for increased number of SMS gateways
and many more, round up the enhancements made to ProximityMX in Q1 2017.