The problem moonblock brand radar solves

Situation:

NFTs are not just speculative assets but a new way of how brands, like Patagonia, can interact with their users. In order to make informed decisions on how to enter web3, marketing managers need real-time data to answer crucial questions like:

• What playbook do successful brand NFT projects follow?
• Who of my competitors has already launched an NFT?
• How much revenue do brand NFT projects in my industry generate on average?
• and much more

Complication:

Existing tools focusing on web3 native target groups fall short when it comes to the needs of marketing managers to quickly assess and report marketing KPIs of brand NFTs:

• Most web3 analytics tools require technical skills, like SQL, that most marketing managers lack
• Most tools provide insights on non-marketing related subjects and KPIs, like financial due diligence
• Most UI seems not trustworthy to corporate managers

Solution:

With moonblock brand radar, non-technical marketing managers from existing brands (e.g., Patagonia) can quickly find, analyze and benchmark brand NFTs in an easy to navigate way and without one line of code. Think of google analytics, similarweb, and mixpanel for web3.

Challenges we ran into

Timed-out Dune Queries: Some advanced queries that we wanted to include in our dashboard (e.g. table with all holders alongside with ETH Balance and Wallet Age of each holder for a collection) took too long for the Dune Engine to execute and eventually timed out. These queries were not suitable to transform into an API endpoint.

Loading time of front-end: The content of the front-end (KPIs / Charts) takes quite a bit to load as different endpoints take different time to be executed. There are quite some longer computation and dune queries that impede the user experience. If we would have had more time, we could have added caching in order to avoid frequent live queries.

Comprehensivity of Brand NFT Projects: We wanted to enrich the existing list of NFT brands with useful insights e,g, type of NFT projects, utilities, crypto native project partners, implementation partners, but ended up realizing that this type of qualitative research was not feasible in the scope of the Hackathon.

Data Ingestion of Notion API to PostgresSQL Database: It was challenging to match projects we collected in the notion data base across 2 tables using the Notion realtionship into a Postgres Relational Database. We used Airbyte together with the Notion API to ingest the data, however, there was a lot of hacks neccesary to match unique notion ids. After duplicating the notion database to use working copies, we needed to re-join these notion identifiers.

Visualization of Data in suitable Chart libraries: Initially we wanted to visualize the data using Ant Design Charts given the aesthetic look and feel. We encountered difficulties when passing down the data down into the child components. Eventually we ended up using the recharts library for most of the dashboard.