+1 347 223 5128

+44 20 3744 5675

Our professional consultants are ready to guide you

What to Look For in a Mobile Event App

Back to blog

2014-10-15

Marvin McTaw, the CEO of Event Commercial.com and a connoisseur of the event industry is back this week to share more information about event apps. This time we asked Marvin to identify some of the critical elements organizers should be aware of when selecting their event apps. You can see the first part of our article series here!

 

What should organizers be aware of when looking for event apps?

There are lots of things to consider but the one thing I would encourage all organizers to keep in mind is that your attendee facing app has an incredibly short shelf life. For example, the average “life” of an app for a three (3) day conference is probably four (4) days. The vast majority of attendees won’t download your app until they are actually at the event and they will probably never open your app again after your event is over…especially if you don’t give them a reason to.

Keeping this in mind, the biggest things I think about for event apps are the following:

  • Native App Need – does your event even need a native app? Many of the same outcomes can be accomplished via mobile web apps (i.e. through the browser) at much lower cost than native apps and with greater accessibility to more devices. Consider investing time and money in a fantastic mobile website before considering native mobile apps. Generally speaking, the smaller your event the less likely you are to actually need a native mobile app for your attendees.
  • Cost – event apps can be obtained for free or can cost you tens of thousands of dollars if built from the ground up.
  • Time To Manage – just because an app is free doesn’t mean it’s worth doing. Consider the amount of time required for you to manage and update your app. Most apps are not connected to existing content management systems and will require additional work from you and your staff to update the content within the app. While vendors generally try to minimize this, consider all your additional responsibilities before you actually decide to implement an app.
  • Sponsorship Inventory – most apps are not cheap so consider how you can incorporate new or existing sponsors into the app? Can a sponsorship be sold to help defray the app cost? What additional advertising opportunities are available within the mobile app?
  • Content Updates – your event’s content (e.g. schedule of events, speaker lineup, etc)  will likely change. Will those changes be updated and reflected in your app? Is it possible to integrate content updates with your existing system to make things seamless? Will these updates be real-time updates or only synchronized once or twice a day? Does this work for your event?
  • Speed – most native apps have local device storage, your attendees will want updated information. Most events have horrible data connectivity (both wifi and standard cell phone data networks) which tends to make apps go slower than normal when updating. Ask your mobile app vendor what they do to minimize the size of your updates and how they optimize their apps’ speed because you don’t want your attendees waiting 10 minutes for a minor update.
  • Bandwidth – if there is enough time, you can improve the performance of the vast majority of apps by increasing the amount of bandwidth available for app usage at your event’s venue.
  • Tracking & Analytics – what kind of reporting is available? How will you determine whether your app is successful or not? What are your metrics for success?
  • App Distribution Method – some event apps are distributed through an existing app already deployed in app stores while other apps are distributed on an individual event basis through the various app stores. This can have an impact on the number of people who install your app as well as how you market your app to potential attendees.
  • Customization – some apps have little to no event specific branding while others allow complete and total customization. Generally speaking, the more available customization, the higher the price tag.
  • Build Time – some event apps can be created and distributed in a day while building from the ground up can take several months.
  • App Store Approval – apps must be approved by app stores. The iOS app store (iPhones, iPads) is generally the most stringent. While approval normally happens within two weeks, if significant changes are required within your app, the approval can drag on for months. Due to this, I recommend building in at least a month for app revisions & app store approval if building an app from the ground up or if you have questionable content.
  • App Marketing – creating an app is only the first step. Your app must be highly marketed to attendees in order to get them to download it. Even though most attendees won’t download your app until the start of your event, you should build awareness leading up to your event. While at the event, make sure you encourage installation of your app, preferably right at registration and encourage attendees to spend a few minutes becoming familiar with your app to improve it’s usefulness to them.
  • App Installation Considerations – while there are more Android phones out there, the users most likely to install your apps are iPhone users. Android phone users may download your app but are less likely to actually use it. Blackberry, Windows Phone and other platforms probably aren’t worth investing your funds in to create specific apps for if they aren’t already included in the price.
  • Supported Devices – most iPhone apps are generally supported across recent devices (i.e. iPhone 4, 4S and 5) and operating systems versions (i.e. iOS6 and soon, iOS7). Android apps are almost never tested on all devices or all operating systems but they are generally supported on the most popular devices and operating systems. The same generally applies for other devices.
Need help finding a speaker for the perfect event?

Send a simple request. You’ll get a quick reply with fees and availability

  • This field is for validation purposes and should be left unchanged.