Many big brands recognise that consumers increasingly value experiences over products and are starting to extend their own value proposition by adding new opportunities to engage. Access to ticketed events is an obvious choice for many, well within stretching distance of their own brand, but historically that has meant a lot of heavy lifting for internal teams.
Tickitto’s mission is to provide fast, easy access to the world’s best events, so it’s our job to reduce that strain. With the help of Tickitto's technical guru Elie Hamouche, Our CEO Dana Lattouf provides an overview of how we do that, focusing on the technology we use. It’s designed to provide data needed by technical team members, but we hope we’ve written it in a way that engages a non-technical audience too. Feel free to comment at the end or ask for more information if needed.
Certain brands have naturally aligned to extensions into experiences for some years: so-called ‘Super Apps’ such as WeChat in China, act as a portal to a vast range of virtual services and online purchasing options. Similarly, airlines have been offering customers the options to book their hotel room at the same time as a low-cost flight for years.
We admit that we may be biased, but it’s a no-brainer that if a brand has invested heavily in building a relationship of trust with their customers, then they’d want to extend it by offering relevant services that align with their brand values. It’s a matter of making intelligent choices for brand extensions that fit. It’s easy to see how a mobile phone provider’s proposition fits neatly with live events; we book the tickets on the phone, and the in-built camera has become an integral part of any human experience.
In years to come, it’s likely that the main buying channels for tickets will not be through specialist providers, but from the brands with which we already have a trusted relationship. However, we know there are many barriers to making this a reality.
This paper considers those challenges and explains how Tickitto’s technology can help overcome them. First, we consider the nature of setting up and managing the data integrations needed to deliver a holistic ticket-buying experience to consumers. Second, we consider the nature of the API technology we use for clients to consider its efficacy.
For many years, purchasing a ticket to an event was an off-putting, difficult task requiring physically showing up to an event counter and queuing for hours. With the growing number of ticket buyers, event organisers had to overcome numerous challenges to make the process for both the organiser and event goer fast, convenient and operationally easy.
Ticketing reservation software was introduced to event organisers and venues so that the operational challenges could be overcome. However, the process was still very manual, requiring agents to deal with paper cards and check availability by hand. While previously unimaginable, today’s eventgoers enjoy a hassle-free and quick experience paying for tickets using smartphones.
From the ticket buyer’s standpoint, things look relatively smooth. But for event organisers and businesses trying to bring event ticketing into their value proposition, the way the online event ticket market works is burdensome:
This fragmentation creates problems for each participant in the value chain and effectively makes the integration of ticketed experiences impossible to deliver in a way that enhances consumers’ experiences.
In reality our diagram actually masks the complexity, as it ignores the commercial and contractual issues that precede this integration work.
A company wanting to deliver a holistic events and experiences service to its customers would feasibly need to deliver integrations with 50 separate systems. Following the integration, there is incredible effort needed to standardise 325+ different data models of those reservation systems.
This puts the project beyond the reach of all but the biggest, resource-rich companies.
Compare that with the column on the right, and the task becomes much more viable. Tickitto provides a single source of supply for the world’s best experiences with just 3 required data models. There aren’t many project alternatives that can credibly state that the integration work is less than 1% of the other option.
The second part of this paper considers the technical nature of the Tickitto API. It aims to answer any questions on whether we have chosen the most efficacious approach to providing the supply of event tickets and related data to our clients.
REST [Representational State Transfer] is a fairly modern architectural style for providing standards between computers. When an API conforms to the REST architectural style, we say it is "RESTful". There are several key characteristics why REST APIs make sense when considering the efficiencies of parsing data.
RESTful APIs place significant emphasis on uniform interfaces between components, which simplify implementations and lower the learning curve.
The uniformity of REST has driven open-source communities to develop extensive tooling in all programming languages - significantly improving developers' productivity and experience when implementing integrations. Examples of such tooling are ready off the shelf libraries that a developer can use to make working with REST APIs much easier. These libraries are generic and are designed to work with any REST API.
They implement general functionality like caching, security, retry logic which developers can reuse when integrating with REST APIs.
Compared to SOAP, RESTful APIs can return much smaller payloads due to their support for JSON which is much less verbose than XML. Let’s take an example: the following image is a sample XML response for an Event Schema. We cut it off at 42 lines of data (it’ll be clear why shortly). At that point, a few attributes of the entire event meta-data are returned (event ID, description, event images).
Only after 362 lines does the recipient have the entire meta-data.
Compare that with the Event Schema in the Tickitto API. The entire meta-data related to an event is retrieved with just 42 lines of data.
This efficiency level is crucial for serving mobile customers or parts of the world with limited bandwidth networks. ‘RESTful web services using JSON as payload format are widely considered as the best architectural choice for integration between mobile apps and back-end systems.’
The following statistics are sourced from the same published paper, comparing SOAP vs REST-XML vs REST-JSON in the context of mobile devices.
Similar conclusions were drawn in a study that was published in the International Journal of Computer Science and Network: “In terms of both memory footprint as well as the parsing runtime, JSON delivers better performance at the cost of readability and flexibility”.
JSON Payloads returned by a RESTful API can be parsed quickly and efficiently compared to XML payloads or other formats that use up large amounts of device memory due to their verbosity, needing additional processing by the client. The delays cost heavily in terms of both resource allocation and revenue leakage.
The key question is: how do these advantages play out in relation to the services that Tickitto offers its client?
Standardised interfaces - Tickitto's RESTful offers a standardised, intuitive payload that abstracts away the complexities of searching, reserving and booking tickets to events across many suppliers. The endpoints are simple, predictable and return ‘need to know’ information only.
Fast - Tickitto's endpoints are all designed to return JSON payloads which are structured, simple to parse and intuitive. This allows Tickitto to serve mobile and bandwidth limited customers a great experience while minimising the performance requirements from partner services at scale.
Secure - Tickitto's REST endpoints are secured with HTTPS and follow authentication best practices, to protect vendor and customer data at transit.
Put simply, the point we’re trying to make is that a trusted brand’s ability to extend their share of customer wallets by offering access to ticketed events and experiences has become significantly more viable. Tickitto works in partnership with its clients to provide the best experiences to their customers.
This paper was researched and collated by the team at Tickitto as part of a series which we want to share with clients, partners and anyone interested in the travel and events sector.
If you would like us to share future research with you directly.
We’d be especially interested in hearing from you if you would like to collaborate on future research or even if there’s a question you’d like us to look into. Please let us know by emailing firstname.lastname@example.org.
An API [Application Programming Interface] is a way to programmatically interact with a separate software component or resource.
REST [Representational State Transfer] is a fairly modern architectural style for providing standards between computers. When an API conforms to the REST architectural style, we say it is "RESTful".
SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks.
Access a world of ticketing platforms with a simple API - Give your customers a world of event experiences.