Firefly Music Festival – Survey Platform

Like any product or business, getting customer feedback is critical to ensure your solving their needs.

Firefly Music Festival took that effort one step farther by announcing that their 2017 festival would be fan-curated.

Fans would get to cast votes for festival artists, submit poster designs, and even select the name of a Taco truck.

Behind the scenes, the Firefly team wanted to collect demographic information and ensure that no one tried to game the system, all while providing multiple types of surveys across 6 categories each with their own start and end dates.

Survey types included:

  • Text Submission
  • Multiple Field Submission
  • Multiple Choice
  • Image Select
  • Rank the Following Random Selection
  • Upload File
  • Combinations of the above

Some would allow unlimited votes, while others could have a limited number of votes per day.

The complexity of this system did not lend itself to any available 3rd party solution, so I had to build the platform from scratch.

The Core Build

Since this was the first year Firefly was presenting itself as fan-curated, it didn’t make sense to invest in the platform’s full capabilities. There was always a distinct possibility of scrapping the concept for the next year, so I opted to keep the platform lean.

This meant limiting administration and management functionality severely and keeping the platform as a developer solution. The Firefly brand team would plan and organize the content and direction of each survey and I would work to build each of them out as needed.

At its core, users would need to register and fill out base demographic info. In order to prevent spam voters and cheaters, users were ultimately required to confirm their accounts before proceeding through the platform.

When a user submitted a survey, each field of their entry would be added to a master answers table that listed the survey’s ID, the user’s ID, the type of question, the question’s title, the option number of the question (for multiple checkboxes and band ratings), and finally the value itself.

Additionally, a separate table kept track of the surveys a user had filled out in order to prevent users from voting too many times.

This core data structure would easily provide for managing every survey type.

The Survey Builds

Though most surveys were simple text submission or multiple choice and could be easily reproduced, some survey builds were complex and required creative planning in order to fit them into the existing system.

The following surveys broke the mode and required core changes.

Zoom Contest

In years past, Firefly had run a “hide-and-seek” contest called the Zoom Contest.

The contest began on the web page with a zoomed out map of a city. As users tweeted a certain hashtag, the map would zoom in further and further until it hovered above a local business. There, the first fans to find the Firefly representative would win VIP passes to Firefly.

So, I had to build out a system that would allow for back-to-back city contests, track and actively display Tweets, and zoom in randomly around the specific location (to prevent people pinpointing the location too early).

Though the contest did not track any user submissions, it still became a part of this fan-engagement platform.

Big Break Live

Every year, Firefly holds a contest for bands around the globe to submit themselves for selection in the Big Break contest. After internal rounds of vetting, fans can vote on a final selection of bands and one is ultimately chosen to come out to Firefly to perform. It’s an amazing chance for new artists to reach a huge audience.

In 2017, the Firefly brand team renamed Big Break to Big Break Global and created a local content called Big Break Live.

In this contest, only bands within 150 miles of Dover, De could submit their acts.

After vetting, bands would go through multiple rounds of voting – ultimately culminating in a live show for an audience and a panel of judges.

Both of these contests required submission management, multiple voting periods, different votes/day rules, and elimination rules. As the contests progressed, more and more details about the bands would be shown.

I created a separate database table for these bands and their data, opting to use json formatting for their submitted data as some bands would provide more or less detail.

I don’t like wasted database columns.

Talent Survey

Firefly relies heavily on fan feedback when it comes to booking bands and discovering new talent.

The yearly talent survey is sent to everyone and asks them to rate acts from 0-10 and a few other demographic questions.

Fans certainly wouldn’t vote on every one of the hundreds of bands out there, so the survey needed to show 40 random acts in order to ensure voting evened out for all bands.

On top of that, the team wanted to open up voting to as many people as possible so they asked for the survey to not require a login. So, depending on if you were logged in or not, demographic questions were added to the survey and a guest submission was saved. Though not originally built with the intent to save guest submissions, I outfitted the core to handle this process.

The result? Over 15,000 submissions in 2017 and a solid foundation for talent planning for 2018’s festival.

Band Name Generator

Somewhere along the way, the Firefly team had an idea for a viral marketing product that would allow fans to feel personally attached to the 2017 festival and provide wearability to their audience.

In similar fashion to the Wu Tang Clan Name Generator, I built a Firefly Band Name Generator.

In short, a user could enter their name a random band name would be provided – but not purely random. If they entered their name again, the same response would be spit out. Change a single letter and you would have a completely different name – almost like magic.

The magic uses two techniques and no database storage.

First, the team helped me compile two lists: one of adjectives and one of nouns. These would be used to create adjective-noun pairings for the final band name.

Then, the name provided would be broken down and passed through php’s srand() function – which alters the default random number generator. With the random generator altered to fit the name, we can pass through the list of adjectives and nouns and produce a pairing. Since the name always produces the same random number generator, the same pairing is always produced. Neat!

Now that we had a magic band name pairing, we could add the name to an image (not just on top of it) to produce a shareable image.

Just upload the image to Amazon S3, add the image URL to the open graph structure of the page, and Facebook will automatically pull the image when the URL is shared.

All In All

Over the 6 month period of building and launching the product, the platform added 35 different surveys, registered nearly 50,000 users, received 225,000 submitted surveys, and stored a total of 2.1 million individual answers in the database.

Now that’s big data.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.