IPLv2 BI data plan and events
IPLv2 is such an amazing and exciting project. If you haven’t read the product overview then please take a few minutes to go through it.
In this post I wish to share with you the business intelligence (BI) side of things. At kik we value data and insights. We are data driven company and as such we look at all BI aspects alongside the product life cycle.
Data is always a challenge when developing a new system. In between the architectural design, defining the product specs and the project goals you need to also take a broader BI look. This is the spot where you need to think how data should be integrated. Making sure it empowers the ability to validate that the project is on track, whether it is performing as expected or perhaps there are issues that needs fast resolution. This is exactly the place where I love to be. Making sure we we have a solid data plan for the project, followed by realizing it to information and insights.
For IPLv2 we have set several key success criteria:
- Reaching 10,000 KIN users with kin wallet on the blockchain.
- Full wallet engagement: having each wallet user spending and earning kin.
- Meaningful blockchain transaction volume.
The architecture of IPLv2 combines the kik messenger, Kik bots, new SDKs, kin wallet service and kin award service. For having a clear visibility in to answering how the KIN ecosystem performs, how success criteria are met I planned these KPIs and dashboards:
Planned KPI & Dashboards:
High level KPIs and metrics: Summarize main information such as KIN users and conversion, KIN active users, transaction volume and kin amounts, errors and failure counts, spent activity (sticker spends, stickers sent), earn activity (poll initiated/completed), and retention.
A note about errors and failure: Just recently we saw how unexpected the ethereum can be (for example, CryptoKitties caused a slowdown in the network) It is crucial for us to give the wallet users the best experience. We intend to monitor successful transaction creation, failures to create transactions and will monitor in the background how submitted transaction are processed/rejected/timed out.
Other drill down dashboards:
- Full participation funnels — for on boarding flow.
- Wallet dashboard — for tracking actions within the wallet.
- Sticker shop dashboard — tracking top stickers and sticker usage
- Poll dashboard — for tracking polls completion and optimize poll participation.
- And ad-hoc dashboard for any different use cases (QA, support, partnerships, etc.).
Data Infrastructure and event definition:
Our data infrastructure is based on Amazon data lake. We collect events triggered by user actions within the kik messenger alongside other events triggered by backend services. Our data is can be queried using both Amazon Redshift Spectrum and kibana and we use re:dash and databricks as our main BI platforms.
Here is just one example of event definition that will facilitate our BI need:
Main onboarding flow — introducing Kik users to the Kin wallet:
More on events: All screen opens and screen taps have a dedicated event.
Core event properties: All of our events have common data that consists of kik user ID, kik username, timestamp, IP, platform, operating system, kik version
Event specific properties:
We store additional event specific data on a per case basis, for example:
- For blockchain related events we store transaction id and amount.
- For poll events we collect poll name, question information, response information.
- For screens with lists we collect on which item the user tapped.
Data quality and event structuring:
Events are strictly defined based on data engineering guidelines which exist for keeping aligned naming convention, correct event structuring, qa validation and help automating event creation across all teams in the company. All events are defined using JSON schema files which details event names, description, types and QA validation if applicable. Example of such JSON for wallet_offer_tapped event:
Happy to hear your thoughts and comments!
