Festival reporting, from one view.
Front Gate Tickets runs ticketing, RFID wristbands and layaway plans for music festivals across the country. Nine in ten of its festival clients wanted the same reports, but changing even one thing on a report was difficult. Its next generation BI platform needed one master view that every team could filter for itself.
The same reports, hard to change.
Front Gate Tickets is the Austin festival ticketing company behind events such as Austin City Limits and Lollapalooza, and part of Live Nation Entertainment through Ticketmaster. Each festival runs as its own label in Front Gate's Backstage platform, and its ticketing, fee, gate scan and shipping data fed reports that were difficult to adjust.
How might we bring Front Gate's four core reports into one view that every team and festival client can filter for themselves?
Nine in ten festival clients want the same reports.
One report, many clientsChanging one thing on a report is difficult.
Reports that resisted changeA client running the waitlist report for one weekend wanted each fan's zip code, to give local fans priority access. Zip code was nested inside Fan ID, so it could not be filtered on.
Data that could not be filteredProduct, engineering, finance, client services, operations and marketing each relied on the same data for different decisions.
Many teams, one data setFrom stakeholder interviews and a Backstage product demo in November 2022.
The goal was to put Front Gate's ticketing data behind one set of filters, so every team could find new insights, forecast revenue and make data-driven decisions with its festival clients.
Defining the metrics before designing the dashboard
Before any screens were designed, 13 stakeholders across Front Gate and Live Nation were interviewed and the Backstage platform was walked through in a product demo. That work produced the four report types the dashboard was organized around, the metrics inside each one, four business insights and the 20 variables the master view had to support. Every screen in the final design was built against those definitions.
01Discover
Interviewing stakeholders across Front Gate and Live Nation.
Discovery for the next generation BI platform began with interviews across Front Gate Tickets and Live Nation. Six business leaders were interviewed from product, engineering, finance, client services, operational services and marketing, along with four members of Front Gate's technical staff and three members of Live Nation's product and data teams.
Each interview gathered feedback, pain points and recommendations about Front Gate's data, to understand how that data affected decisions in each part of the organization. Interview notes and personas were documented in Confluence for four groups: business leaders, technical staff, Live Nation staff and festival clients.
- Product
- Engineering
- Finance
- Client services
- Operational services
- Marketing
- Software engineers2
- QA manager
- Engineering manager
- Product managers2
- Data engineer
01Discover
Walking through Backstage in a product demo.
A product demo of Backstage, the platform Front Gate's festival clients license, showed how event data is structured. Data columns are set at the highest level and apply to every client nested beneath it, and a label is one unique instance of a festival.
The demo also showed how reporting was used. Nine in ten clients wanted the same reports, and changing one thing on a report was difficult. One client running the waitlist report for a single weekend wanted each fan's zip code, so fans near the festival could get priority access, but zip code was nested inside Fan ID and could not be filtered on. Waitlist reporting was moved to a later release.
How Backstage nests data
- LicenseeData columns set at this level apply to every client below it.
- ClientNested under the licensee.
- LabelOne unique instance of a festival.
Waitlist report, one weekend
01Discover
Reviewing prior BI work and confirming Tableau.
Prior BI discovery collateral and documentation were reviewed before any new work began. Dashboard samples relevant to the project were sourced and compared on how well each could visualize the report types Front Gate needed, DOMO was reviewed alongside them, and Tableau was confirmed as the future state reporting platform. A Tableau sandbox license was set up for prototyping.
Front Gate's product one-sheets were reviewed alongside the interview notes, because each product writes its own data into the reports. The layaway plan is the source of the layaway ticket and layaway fee data, and RFID wristbands are the source of the media type split and the RFID fees. The plan's own comparison of gross per order against an outright purchase was later carried into the layaway report as a callout.
02Define
Defining four report types and their metrics.
Stakeholder input was consolidated into four report types: event tracking, gross transactional volume (GTV), field operations and fulfillment tracking. Each report type was broken down into the metrics it had to show, and every metric was defined against the denominator it is measured by.
Event tracking covers ticket volume, layaway tickets and media type. GTV covers eight fee types, each reported in dollars and as a percentage of total revenue. Field operations counts the people scanned in, live by event, gate, day and time. Fulfillment tracking follows each order from creation to a generated label to a fulfilled package, by event and by carrier service class.
- Tickets purchased
- Tickets not purchased
- Total layaway
- Pending payment
- Defaulted
- Paid in full
- RFID
- Electronic
- Per ticket
- Processing
- Layaway
- Shipping
- Fulfillment
- Waitlist
- Ticket insurance
- RFID
- Received
- Pending
- Default
- People scanned in
- Event
- Gate
- Day
- Time
- Orders created
- Labels generated
- Packages fulfilled
- Event
- Service class, USPS and UPS
02Define
Writing the business insights each report supports.
Four business insights were written from the interviews to set what the reporting had to make possible. Each one is answered by a specific report type.
Stakeholders want historical events trended by event, genre and client.
Event trackingStakeholders want GTV performance predicted by fee type.
Gross transactional volumeStakeholders want gate-level scans tracked to predict event needs and reduce costs.
Field operationsStakeholders want the fulfillment process tracked end to end, from order to delivered package.
Fulfillment trackingThe dashboard was scoped to the four report types, and the full data set stayed available in Tableau for analysis beyond them.
02Define
Defining twenty variables for one report builder.
Because nine in ten clients wanted the same reports, one master report builder view was defined in place of a separate report per client. 20 variables were identified for it in five groups, event, fan, ticket, revenue and operations, so any report could be narrowed by filters instead of rebuilt. Zip code was split out of Fan ID and defined as a variable of its own, so the waitlist request from the product demo could be filtered directly.
Applied filters were specified as removable chips shown above every report, so the scope of the numbers on screen stays visible. In Baymard Institute's ecommerce testing, users who overlooked even one applied filter were likely to misread the results in front of them.1
- Event
- Label
- Weekend
- Genre
- Venue
- Fan ID
- Zip code
- Region
- Order date
- Ticket type
- Media type
- Layaway status
- Price tier
- Fee type
- GTV
- Refunds
- Gate
- Scan time
- Carrier
- Service class
Zip code, split out of Fan ID after the product demo.
03Develop
Iterating the layaway report through three versions.
Low fidelity wireframe sketches were drawn first, with the KPI dashboard samples gathered in Discover as reference. The layaway report was then taken through three iterations, with the same four metrics in each, because every metric had been defined as a count and a percentage of its total.
The first iteration placed each count beside a solid color icon tile, which left the percentage to be worked out from the two numbers. The second wrapped each icon in a ring that fills to the metric's share of the total, and renamed the cards to match the metric definitions. The final iteration kept the rings, printed the percentage under every count and added the charts the business insights called for.
Rings with the percentage under every count, installments collected by month, plan status, and a Tickets and Fees toggle.
03Develop
Organizing the navigation around the report types.
The left rail lists the report types in the order they were defined: event tracking with its three sub-reports, revenue (GTV), field operations and fulfillment, followed by the report builder. An overview sits at the top for the figures every team checks first.
The festival label sits at the foot of the rail, because Backstage treats each festival instance as its own label and every figure on screen belongs to one. The applied filters moved out of the rail and into the header of each report, as removable chips beside Add filter.
03Develop
Pairing every status color with a label.
Paid carries green, pending payment carries orange and defaulted carries red in every report. Each ring also carries its title, its own icon and its percentage, and shipment statuses in fulfillment are written out inside their pills, so no status depends on color alone. Red-green color deficiency affects around 8% of men of European descent,2 and WCAG 2.2 requires that color is never the only visual means of conveying information.3
04Deliver
Delivering high fidelity prototypes for every report.
High fidelity prototypes were delivered for all six reports and the report builder, on desktop and on mobile. Each was animated as a walkthrough of its core interactions, from the toggles and hover states to the live field operations view, and high level tasks for the build were handed to the project management office.
Designing the master report view.
Each report was designed against the metrics it defines and the business insight it answers. The walkthroughs below follow the final design report by report, and close on the report builder that answers the product demo.
Reading ticket volume as a count or a share.
Paid tickets and tickets pending payment are shown against total tickets, and a Count and % of total toggle switches every figure on the page, which covers both measures in the metric definitions. Ticket sales over time plots the current year against the previous one, answering the trend reporting insight, with the split by ticket type beside it.
Following every layaway plan through to payment.
Layaway opens on four rings: total plans, paid in full, pending payment and defaulted. Installments collected compares scheduled and collected payments by month, and a Tickets and Fees toggle swaps the same cards to layaway fees received, pending and defaulted, the same figures that report under GTV.
Splitting tickets between RFID and electronic.
Media type splits total tickets between RFID wristbands and electronic tickets, tracks the wristbands activated before gate day and breaks the split down by ticket type. A note under the split ties it to revenue, since RFID fees are billed on every wristband and feed GTV directly.
Forecasting revenue by fee type.
GTV leads with total volume, fee revenue, average order and refund rate, then breaks fee revenue into its eight fee types. A Dollars and % of revenue toggle covers both measures in the definitions, and the revenue forecast projects the year from actuals to date, answering the revenue forecasting insight.
Tracking scans gate by gate, live.
Field operations runs live during the festival. People scanned in, scans per minute and the busiest gate update as fans enter, entries are charted every 15 minutes and scans are broken out by gate, with a tab for each festival day. This answers the gate-level tracking insight.
Following each order from creation to delivery.
Fulfillment tracking shows orders created, labels generated and packages fulfilled as a funnel, splits packages by USPS and UPS service class and lists recent shipments with their carrier status. Statuses update as carriers scan each package, answering the end-to-end fulfillment insight.
Building the waitlist report from the product demo.
Any report can be narrowed with Add filter, and every figure recalculates for the filter applied. The report builder holds the 20 variables, so the waitlist request from the product demo becomes a saved view: zip code is added as a column, then as a filter for fans within a set distance of the festival.
Carrying the reports to mobile.
On a phone the rail becomes an accordion of the same report types, and each sub-report lists its total beside its name. A report pushes in as its own screen with the same rings and charts as desktop.
Four reports, one view.
Every need answered on a screen.
The four report types, the four business insights and the zip code request from the product demo each have a screen that answers them, inside one navigation and one set of filters.
One builder for every client report.
Twenty variables and saved views let a client report be changed with a filter, covering the reports nine in ten clients had in common.
Status that does not rely on color.
Every status color is paired with a title, an icon and a percentage, and the pairing holds across every report.
Sources
- Baymard Institute. How to Design Applied Filters. Large-scale desktop and mobile ecommerce usability testing. baymard.com
- Birch, J. (2012). Worldwide prevalence of red-green color deficiency. Journal of the Optical Society of America A, 29(3), 313 to 320.
- W3C (2024). Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.4.1, Use of Color. w3.org