Firefly Festival – Website Redesign

Firefly Music Festival is the East Coast’s premier music festival. It brings together over 60k fans and millions in dollars of revenue.

I worked with multiple departments within Red Frog Events to plan, design, build, launch, and actively manage the Firefly website to maximize Ecommerce revenue and deliver the best fan experience possible online.

The WordPress site I built has over 50 custom pages, is viewed by over 1m unique visitors, and includes a custom built user survey platform with over 50k active users.

I personally developed the data structure and page hierarchy for the site to ensure the best possible user experience and navigation flow.

More importantly, I imposed and enforces a strict ban on homepage slider heros – forcing the team to come up with unique and purposeful static hero content.

Firefly has seen happier customers, an easier content management flow, and better user data than ever before.


Warrior Dash – US Map Event Navigation

If you’re not familiar with Warrior Dash, it’s a 5k obstacle course mud run and festival with event locations across the country.

Typically starting in February (in Florida), Warrior Dash moves across the country for one or two-day events until the end of the year.

Ideally, a customer would go on the site and easily see the closest event location to them (which we would later implement).

At the time, the site only showed locations by date and by alphabetical order – there was no easy was to quickly see that there was an event in Maryland or New York without scanning the page for words.

It was not ideal and the page’s bounce rate reflected that.

The Build

The quickest solution was to add a clickable map of the US that highlighted upcoming events.

A visitor could clearly and instantly see that their state was highlighted and click to the event page to learn more and checkout.

Building the map to work with the existing event data was tricky.

The events themselves were handled by a WordPress Custom Post Type that had been extended over the years using the Advanced Custom Fields plugin. Each had a text description of the address, a latitude & longitude, and a state input.

In order to turn around the project in a timely manner, I opted to use a jQuery map library and highlight states instead of pinpointing the exact event location on the map. This had the added benefit of increasing click-thru rates for curious residents and gave the location page a chance to convert users who may have felt far away from the event location.

This left both the address and coordinate fields moot and the state input had been used poorly as a location nickname. In short, I had to add a new field for the coordinator to use for state abbreviation.

Now that events had proper state abbreviations, I appended the information to the pre-existing location HTML elements on the page and used jQuery to fill out the map data. No need to duplicate Database queries!

The map was now at a point where the active states were highlighted in red and the past states in blue – each clickable.

It’s not just pretty, but massively effective as well.

Average time on this page toppled from a whopping 6:25 to merely 25s over 5 months – a reflection that people no longer needed to figure out the page in order to move forward.

Bonus Points: Email List Growth

But what about the other states?

The Warrior Dash team is always looking for supporting data to help them decide to host in a new state.

Using a data structure I had already built for the site’s email marketing platform, Emarsys, I added the inactive state abbreviations to their map links. Then, I created a landing page for these clicks that automatically pre-selected the state in an email signup form.

Users could now easily click their state, land on a signup page with their state selected, and just fill in their email to become part of this “state waitlist”.

The result: a steady uptick of new email signups for inactive states.

Warrior Dash – Analytics

Like any site, Warrior Dash had Google Analytics installed and running in the background.

Once in a while, various members of the team would poke around in GA in order to gleam high level details like gender or mobile usage.

But these single metrics don’t really give the whole picture – especially when half the funnel is not being tracked at all.

Questions remained:

  • How many people clicked to the checkout?
  • Where did people drop off along the checkout process?
  • How far do people really scroll on these pages?
  • Which demographics tended to purchase which products?
  • Did any channels in particular tend to lead to more sales?

Answering these questions could lead to specific actionable steps the team could take to improve sales and maximize advertising costs; a much bigger impact than perusing total sessions and site bounce rate.

Adding Proper Views

First things first, I split the single All Web Site Data view into three different views.

Since the All Web Site Data view already had IP filters on it, I renamed it to Master View. This would be the primary view the team would use to view their data.

Second, I created a true All Web Site Data view with all filters removed. This acts as a backup of site data in case we need to view raw results.

Lastly, I added a Test View that would be used to try out new dashboards, segments, filters, goals, or funnels. It’s important to have a test view so you don’t impact your Master View unless you’re sure you’ve done things right.

Ecommerce Funnel Tracking

Next up, we needed to start tracking what happened when we sent people to checkout. Warrior Dash checkout was on a different platform than the website itself, so not only did we need to add our code to it, but we needed to make sure Google Analytics would be able to track a visitor across both domains.

This is called cross-domain tracking and unfortunately, Google doesn’t handle it out of the box. You would assume that since the same tracking code appears on two sites, it would naturally link the two, but instead GA will treat them both as referral traffic and throw your data and assumptions in a big way.

On top of this, the Ecommerce platform used on-page popups to guide users through the checkout flow instead of simple pages. Since Google Analytics only tracks new page views by default, we needed to add event tracking to the cart process so we could see where people dropped off as well as advanced ecommerce tracking to the products themselves to gleam insight into purchases made.

So, I worked with the Ecommerce development team to implement cross-domain tracking, advanced ecommerce tracking, and event tracking throughout their cart funnel.

Scroll Tracking

On top of that, I added scroll tracking to key pages to gain better insight into which sections of these pages visitors actually saw.

This way, the team could better understand which information was being consumed before users either exited the page or continued to the cart and ultimately decide on how to best proceed with organizing these sections.

Better Reporting

Now, it’s nice that all of this data is being properly collected in Google Analytics, but what does that mean for non-techies?

Wouldn’t it be great if key insights were pre-analyzed and available on a convenient dashboard?

Well, the Warrior Dash team is in luck! Google Analytics offers custom dashboards to view key metrics in an easily-digestible way.

They can now see total sales volume per channel, view revenue by demographic, and check mobile cart abandons all in one convenient location – now that’s better reporting.

EventSprout – Mass Import

EventSprout is an event management and Ecommerce solutions that event organizers use to sell tickets.

In a typical sale, a single user goes to buy a single ticket and the checkout is very simple.

But what if a group wants to buy tickets? Or an organization comprising of dozens or even hundreds of participants? A single checkout process would take hours and with so much information added to one server request, it could break the process altogether.

The solution? Adding mass import functionality for customer support to use at their discretion for these large sales.

In short, the organization would send over an excel file filled out with member information. Everything from name and age to shirt size and address could be filled out before hand and uploaded to EventSprout for mass order creation.

First, I needed to validate that the file was a CSV. Excel files, PDFs, and other images types don’t produce clean data for use in segmenting multiple users and their data.

After validating a proper file had been uploaded, the user would select the event these customers were attending and select whether or not the system should email users after successfully adding them. Easy enough.

Status: It’s Complicated

Though fields like first name, last name, and email are required for every single event on the platform, each event can have unlimited additional questions for participants to fill out such as age, address, gender, shirt size, etc – each requiring their own custom validation rules.

I needed a way to preview a few of the uploaded columns and allow the user to select which column was for each event question. This included the ability to ignore an unnecessary column and ensuring no duplicate columns were selected by accident.

Additionally, there was no simple way to choose which ticket these customers wanted. EventSprout doesn’t know that GA stands for General Admission, so I had to build out a “ticket translator” for the user. For any event, it would generate the proper value of the ticket name, including the groups it was nested under. If this proper name was not added to the ticket column, it would throw an error.

Speaking of Errors

Now, what if a row had an error? Should we invalidate the entire import?

I decided to allow successful orders through and create a new CSV of failed rows – including their error message – so that the user could correct the data and re-upload with ease.

If that all sounds easy enough, let’s remember that this had to work within the existing platform and a ton of core code needed to be modified in order to pass through orders in this way. Code that was in use on an existing Ecommerce platform that handles hundreds of thousands of dollars of transactions for their clients, not in a pre-launch development bubble.

So, in that light, I created unit tests to run against every new commit that tested both the success and failure of mass imported CSVs.

In the end, the packaged product solved the problem nicely to the delight of customer service reps who had to enter all these customers manually before.

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.

Firefly Music Festival – Discover Artists

Year after year one of the big concerns the Firefly team sees mentioned by their audience is that they don’t recognize a lot of the smaller acts appearing at the festival.

It’s impossible to expect fans to know every artist, so I proposed a section of the site be created to showcase all the artists from the lineup.

A visitor would be able to easily click any artist name and a popup would show a YouTube clip of their biggest hit (or a SoundCloud playlist if available) and links to their social profiles.

At first, every popup would load content by default – after all, they had to retrieve each of these social links and embeds from their respective artist’s custom post. This, as you can imagine, caused significant and untenable load delays for the page.

So, using the WordPress API and AJAX, I crafted the artist popup to only request the artist data when a user had clicked on the artist name. This immediately resolved page load speed issues and the popup did not suffer for it.

Getting to know Firefly’s lineup got that much easier.

But then I took things one step further.

It’s tedious to click through over 100 bands to find ones you’d like.

What if you were able to select an existing band you loved on the lineup and related artists would be highlighted for you?

That way, you’d be able to listen to similar bands to the one you already liked – increasing your chance to enjoy new music at Firefly and the likelihood that you’d attend.

I pitched the talent team and built out Firefly’s Discover Artists page on the website. The Firefly team could easily select which artists were related to each other in the WP backend while visitors could view those similar artists as they were instantly highlighted on the lineup.

Coupled with the artist popup and a full page of curated playlists, exploring new music at Firefly is easier than ever.