Overall Landscape: While SeatGeek’s “Open” API offers immense promise for primary ticketing, the company’s landmark product is still it’s aggregate secondary marketplace. Even though this product is different than StubHub’s (direct marketplace vs. aggregation), the average consumer looking to buy secondary tickets will essentially use the two for the same purpose. Seatgeek’s pricing algorithm/deal ratings system are great and often allows consumers to get a better deal, but in the case that Stubhub happens to have a similar or lower price on a ticket, there is little differentiation between the two (in terms of ease of use, UI, etc.)
Possible Ways to Differentiate: As a college student who goes to (and has many friends) that go to concerts all the time and after doing some informal market research, I’ve noticed two primary problems when buying from the secondary ticketing market
Payment Problems: One person buys the tickets for the others in the group. Then it takes friends or your girlfriend take 2 months to pay back through Venmo. By the time Venmo cashes out to your bank, you haven’t gotten your money (much needed as a college student or someone in their twenties) for a long time.
I Can’t Find Someone to Go to X: This is primarily for music, as opposed to sports. If there is a Weeknd or Kendrick Lamar concert, 99.9% of the time you can convince one of your friends to go. But if you see a concert for a (relatively) smaller artist you really like, but can’t convince someone to go, you probably end up not buying a ticket. Since I go to school in Nashville, a music city that gets almost every concert imaginable, I did a little walk around my school’s dining hall and found that almost 67% of people had encountered this dilemma in the last 3 months (n = 54). Finding a solution for this problem could be a big driver of revenues for whoever figures it out.
Solutions:
There primary problem with committing to a payment split feature is the time window for the seller. If a seller has to wait for both parties to commit, they could lose valuable time for selling the ticket if the transaction falls through. The imperfect, but better solution, is similar to the Uber fare split system. If I buy a ticket and request a fare split, I enter a phone number to split the fare with. If the user has the SeatGeek app, a push notification is sent to them. If they don’t a text message with the link to a payment is sent to the user. There is a finite time the other person has to accept the request or the entire amount is billed to the user who requested the split.
Ticketmaster recognized this problem and back in 2011 they tried to do this integration system where the map of their platform showed your Facebook friends who had bought a ticket to an event. There was a couple of flaws in this solution. First, if one of your direct friends is definitely going to an event, you already more than likely to know if they are going. Second, for a friend to show up on the Ticketmaster map, the person had to have already bought a ticket, which if they have the same problem of finding someone to go with, is highly unlikely. The solution I think it would be best would be using a variation of the existing ‘track event’ button to show both first-degree Facebook friends who might be interested in going, but also second-degree friends (those who have mutual Facebook connections) that are interested in going. It could be called something like the “looking for” button (see mockups below for a more detailed description). At face value, it might seem that such an idea might just be a slight modification of a Facebook event page, but there are a couple huge differences. First, the conversion rate of people who claim they are “going or interested” to a Facebook event is barely 10%, because people see an event in their news feed and don’t think twice about. If the idea of going to an event is thought of as a funnel, thinking you might be interested in going is a step above actually going onto a ticketing site and checking whether you can actually afford tickets. Facebook events also don’t make the distinction of who is interested in the event and might be looking for someone to go with and someone who already is going with friends, etc.
Flaws in Solutions;
As highlighted above, the biggest challenge with this solution is the timeline of buying the tickets. SeatGeek doesn’t actually hold the tickets that it’s selling, so if the transaction is contingent on a split going through, a lot of the times the ticket might be sold by the time a split is completed. As I mentioned in the solution aspect, if SeatGeek sets a timeline for how long the other user has to complete a split before it’s entirely billed to the original purchaser’s credit card, it still has no control over whether the ticket is being sold in the time a split is going through. In an ideal world, SG could buy the tickets from the third-party at a discount (to reflect the sale profit) and hold it until a split was completed, but this is highly impractical. So the best solution is probably to test around arbitrary time windows which effectively balance the time it takes for a split to be completed and the ticket not being taken in the meanwhile. And also alert the primary user that there is a chance the ticket might not be still there if a split is completed before the request a split. This is imperfect because sometimes there will be outliers where a ticket will be taken by another party during the time window or the user will be billed completely, but it seems better than the existing solution.
From a technical perspective, this seems a little brutal. You have to cross compare each users FB ID with every other user going to the events FB ID (the Facebook API says this a purely implementation server side, which means a slow down that could affect overall page load times). The saving grace is you only need to gather this information from people who are specifically registered and looking at an event on SeatGeek (so the lists of friends you have to cross compare are shorter). Also, as I mentioned before, there likely aren’t enough stand alone first degree connections to make this feature useful as Ticketmaster eventually eliminated it, but is there enough second degree connections and would people be interested in approaching a friend of a friend? In a city as big as New York City, maybe not because of how many different events might be going on at one, but I would guess it’s worth testing out in mid-size markets (i.e. college towns, Dallas, Nashville). Also entirely possible that if such a feature got traction, Facebook could modify their event pages to make this feature native to their site. Given the partnership SeatGeek already has created with Facebook through their primary ticketing experimentation, this seems unlikely.
Technical Implementation:
Has to be a mobile-only option. Use Twilio API to send a text upon payment split after the button is pressed if the number for split is not attached to a user in database, either redirecting them to the mobile SeatGeek site or to the AppStore to download the App. If the user already has the app downloaded, use Apple Push Notification service to alert the requested user about the split. I’m not exactly positive how SeatGeek interacts with payment processors, especially when it’s selling tickets from other sites, but there would have to be some logic which would allocate one ticket to each person and if that expires, then go follow through the payment with the initial requester (without the code executing on the push of the button, but rather automatically). It’s a little tricky for me to do anything except speculate because if a third party processing system such as Stripe is being used, it’s hard to figure out how to modify the logic in the best way possible.
The actual implementation of the Facebook feature I’m guessing will be simpler than the payment split because it requires adding features as opposed to modifying existing infrastructure. From a UI perspective, hopefully it only requires adding a couple of small buttons on the info section of an event. The next time users login, it’s necessary to request their permissions to access their friends list as part of the Facebook API. The tricky part is optimizing when you compare the friends list of a person to the others who are interested. One possibility is using the Facebook API to send a GET Request which takes the two IDs and gives the common connection between the users. If the app is written in Obj-C or React Native another possibility is creating a massive hashtable. If I press the looking for button, every one of my friend’s Facebook ids is saved as a key (if it does not already exist) and then mapped to a value with my unique FB id. Thus, if the next user has a friend with a key that already exists in the hash table, I can access the FB IDS of our mutual friends. I have no idea how the app is currently built so these are just out there suggestions. From what I know, it seems smart to limit this feature to events with <5000 people because comparing the friends list for 75,000 people seems like it’s bound to create a delay in load times, no matter what the solution is.
UI Creation:
