Eventbrite Reporting

When I picked up reporting, the ask was for more features. More charts, more breakdowns, more to add to the page. What organizers needed first was the opposite of that. The experience had drifted into something inconsistent over the years, where the same action behaved a little differently depending on where you ran into it, and stacking new features on top would only make it harder to use. So I argued for fixing the foundation before extending it, which is rarely the popular call. It took some convincing, but the team came around to doing the unglamorous work first.

With that agreement, we rebuilt the reporting experience around consistency instead of novelty. We pulled sales, attendance, and revenue into one structure, made exports fast and dependable, and added flexible date ranges so organizers could compare any stretch of time without leaving the page. The rule we kept coming back to was that the same thing should look and behave the same way wherever someone found it.

The event selector looked like a small thing, just a dropdown for picking an event, and became one of the hardest parts of the project. Events on Eventbrite don't all fit a simple list. Some repeat on a schedule, a weekly class or a tour with dozens of dates, where choosing the event also means picking the right occurrence. Others sell timed entry, where one event is a stack of admission windows. We needed it powerful enough for all of that while staying obvious, whether someone ran a single event or a hundred sessions.

That same task showed up far beyond reporting. Across the product, twelve different event selectors were in production, twelve answers to one question. Unifying them was less about adding power than taking it away, paring the pattern back for the surfaces that never needed the heavy version. I designed how it should behave in each place it touched and went team by team to get it onto roadmaps.