Skip to content

Latest commit

 

History

History
65 lines (46 loc) · 6.62 KB

1_Starting_the_adventure.md

File metadata and controls

65 lines (46 loc) · 6.62 KB
Raw

OKR and KPI

I am responsible for bringing the first flying taxi service to market by analyzing data and building a product proposal. My team and me have discussed and defined Objectives and Key Results (OKR) we want to hit. We want to tackle the most important one right now:

Objective: “Introduce Flyber Taxi as a trustworthy & unique experience to the market in Q2”

The Objective is focused on User Acquisition. At this point in the Product Development Cycle, we want to introduce our service into the market and gain trust of the customers and show them the benefit of Flying Taxis. In the Growth Phase we can focus more on User Engagement where we can improve the awareness and incorporate lessons learned through our first service flights. Later on in the Maturity Phase we can focus more on User Retention & Profitability to secure revenues and improve margins. Key Performance Indicators will help us to measure our actions.

  1. Customer Acquisition Costs ➡️ 1/3 of the income per User (CLV)
  2. Number of Flights/ Week ➡️ ~ 105 Flights each Aircraft per Week
    • Best Days and Time to operate is Friday and Saturday between 8am – 4pm as well as 5pm – 9pm
    • This makes up 24 operating hours per week which equals 1.440 minute per week
    • 1440 minutes divided through median duration (11min) = 131 Flights per Week
    • Using Pareto Principle (80/20) we estimate that 131*80% = 105 Flights per Week are doable
  3. Number of Weekly active Users ➡️ ~ Assuming 3% Conversion rate => 7000 weekly active Users Source:
    • Having two aircrafts we are aiming for 105 *2 = 210 Flights per Week in Total
    • Assuming that 210 Flights is the result of a 3% conversion rate we expect 6.982 weekly active Users which makes up approx. 7000 Users
  4. Net Promoter Score ➡️ in average 10 out of 10 times the customer would most likely refer us for network effects
  5. Average Score of Recommendation ➡️ in average around 8 out of 10 times the customer had a good experience for gaining trust

Creation of an Instrumentation Plan

Having well designed KPIs we need to make sure that we collect the right data. By creating an instrumentation plan for the events, we need to collectand log, we will be able to physically measure the KPIs. The events will be stored in databases for access. First we start with KPIs & breakdown the user steps that contribute to the KPI. Next, we understand the transaction flow and build in events that should be recorded. Here is the result:
  1. Customer Acquisition Costs (UserSignUp, UserRideHistory, MarketingCosts)
  2. Number of Flights/ Week (AircraftPaidTakeoffs, UserOnboard, UserOffboard)
  3. Number of Weekly active Users (UserLogIn, UserFlightSearch)
  4. Net Promoter Score (RatingNPS)
  5. Average Score of Recommendation (UserRideHistory, UserRatings)

A distinction is made between Entity and Event data. An Entity is a unique object such as a customer, product, order, etc. Entity Attributes are the properties that describe it. Entity data is stored in a table, for every entity there is a separate table, and every table has columns that describe these entities. One row is dedicated to recording one type of each entity. The drawback of the entity data model is that the joins might get complicated and introduce latency. The advantages are the removal of data duplication and a simple, easy to understand basic structure. Event data mainly describes the actions performed by entities. A Few key pieces of information that are captured in event data might be the action, timestamp and state. Below you see examples how Entity and Event Data can be required:

Having an instrumentation plan, we also would need to think about the Data Strategy in terms of

  • Data Processing (ELT vs ETL/ Batch vs Stream),
  • Data Storage (SQL vs NoSQL/ Data Lake/ Data Warehouse),
  • Data Infrastructure Strategy (Build vs Buy/ Cloud vs On-Prem) and Security & Compliance.

While we are running business and collecting data, we would also like to test features to improve our product (here helps the Design Thinking Framework). Therefore we need enough data to run experiments (MVP sample size). Assuming we are able to get 7k new sign ups per week we might be able to have sufficient users to build up two variations within a month. We expect to have first insights after 2 months of the launch. Source

Building a Data Pipeline with AWS

Having considered all of the areas above, we are able to structure data pipeline.

How does the life cycle of data and processes work?

  1. Data is collected from the user (either through usage of desktop or app version) & from Taxi Drones
  2. Data is transferred through an Load Balancer to our Servers who are writing entity data to a structured database and event data into an unstructured database (S3 bucket as Data Lake)
  3. Data Storages are hosted through AWS. Location is Frankfurt (Germany).
  4. Both data storages will send their information regularly to the Data Warehouse.
  5. Databases and the Data Warehouse are mirrored in another AWS data center (Milan) for Disaster Recovery purposes.
  6. Flyber is evaluating the information with Tableau, MS Excel and an Integrated Development Environment for applying Machine Learning Frameworks like Scikit-Learn, Keras/Tensorflow. Access is enabled through an authorization concept and custom build APIs.

➡️Data is collected with each User2Product and Drone Interaction (aka not time dependent); Storage Duration: 1 year and unlimited after anonymization

Are the data accurate and kept up to date?

Data is collected based on action and stored in the connected database/ data lake. From there the data will be forwarded to the Data Warehouse during night (supports completeness & accuray of data through usage of low latency timeframes). Data Validation after transfer is automatically done via scheduled job between data sources and Data Warehouse. Deviation will be investigated & solved by employees.