Aggregating and redistributing startup events data globally

​This blog post describes an ecosystemOS data pipe development that has been validated with different startup ecosystems coming from Europe, North America and Asia. Written by the Startup Commons Team.

What are we improving and why?

​Startup events are at the heart of any ecosystem but often times the view of an ecosystem event schedule looks like as follows:

​This picture is quite usual in many ecosystems due to lack of visible startup events data to be shared that helps bring more coordination and collaboration among ecosystem actors. It really doesn’t help to schedule multiple events at the same time and  target a similar audience. 

It would bring more efficiency if we could put all of the tech & business events data out there into a single platform so that events data can be accessed globally by different users and along with that it can also be transferred to other websites, blogs, online communities on user demand.

How are we going to achieve our goal?

​Startup Commons Team is working towards Aggregating and Redistributing Startup Events Data globally and automatically. We will create  a standardized data model (GraphQL Schema) for structuring data on Startup Commons side and making that data available via GraphQL API endpoint. Some of the attributes we are collecting are Event name, Event Organisation, ID, category, Date, time, timezone, description, format or  website link.

What are we creating at the end/along the way?

​Initially, to get more startup events data visible, identify key attributes of startups events and an integrated API service to enable data transfer within and between ecosystems.

How do we measure our progress/outcomes?

From Startup Commons point of view, we are looking at the quality of the startup events data model and the API performance. Regarding the data model, these are the main factors to consider:

• Clarity - attributes and information are clearly defined
• Accuracy - Information is true and correct
• Completeness - information is understandable
• Conciseness - same information is repeated
• Consistency - one piece of information doesn’t contradict another

Additionally, we could get static data from the model itself, data from usage of the data model, data from the comparison with similar data model.

From API perspective, these are some of the KPIs we are looking at tracking:

• Locations 
• Calls Made 
• Best Quality APIs 
• Fastest APIs
• Best Cloud (latency) 
• Cloud Services 
• APIs Tracked 
• Worst Quality APIs 
• Slowest APIs 
• Worst Cloud

Did you find this functionality valuable? 

RSVP TO OUR DEMO EVENT COMING UP!