The details below outline the scope for the MVP version of the KPI Crunch platform.
Purpose of the product
KPI Crunch is a web platform that enables users to position web domains within their competitive landscape based on a number of indicators. The selected indicators are intended to characterise brands’ organic footprint including search traffic, ranked keywords, Alexa rank, social media activity across various social media networks.
Some of the indicators will be retrieved from 3rd party systems using APIs, the rest will be retrieved via proprietary social media scrapers built specifically for the product.
Target audience
Venture investors
KPI Crunch will provide data for Venture Investors to evaluate competition and trends in the domain from a marketing perspective; as well as define the position of their prospective investment within its competitive niche.
Business owners
Business owners will benefit from the data provided by KPI Crunch by evaluating the marketing trends in the selected industry and deriving conclusions to outline their marketing strategy.
Project Description
Technologies
TBD
Adaptivity
Both desktop and mobile versions need to be implemented
Scope (user point of view)
The MVP will include the following features:
Login functionality (sign up, sign in, sign out, reset password), handled by a ready-to-use solution - OUT OF SCOPE FOR THE DESIGN PROJECT
Home page
Report Page
Home page
Home Page will include the following features:
If the user specifies a single domain, the system will automatically retrieve the list of competing domains and their corresponding metrics.
Otherwise, if several domains are used as input the system will interpret this as user willing to form the competitive landscape manually and will retrieve metrics only for the specified domains.
At the MVP stage, there will be no autocomplete or any sort of instant check whether the specified domain exists.
There will be a simple validation of the domain format. A complete domain name will have either a two-part or a three-part structure. It may start with the machine or hostname such as “www” (optionally), followed by the name of the website itself (mandatory), and finally the TLD like .com or .gov (mandatory). Each part of the domain must be separated by a dot.
If the user isn’t authorised in the system, the system will prompt for login upon applying the search.
Report
The report page will display search results for the authorised users.
The page will include the following features:
State and Progress bar of a search
Date, time started, time finished (if finished) for a search
Summary for a search (if several domains have been analysed in the search)
Metrics for each domain in a search (grid??)
Facility to download the metrics to CSV (download the grid to CSV)
List of previous searches
Facility to start another search
State and Progress
Given the process of real-time scraping is quite lengthy (search for one domain takes approximately 1.5 minutes, data is loaded gradually in real-time ), we need to come up with a sophisticated progress bar notifying users about the progress of the processing.
There will be 3 states: ‘Pending’, ‘In Progress’ and ‘Finished’.
Summary of a search
If the user performed a search for several domains, the Report will have the overall summary over (placed over the grid) containing the following analytics:
Percentage of domains having a Facebook presence
Percentage of domains having an Instagram presence
Percentage of domains having youtube presence
Average traffic
The average number of keywords
The list of the indicators will evolve over time.
Domains metrics
The grid will include the following elements/metrics for each domain:
Metrics must have tooltips containing clarifications for the users.
Sorting
By default, the grid will be sorted by Alexa rank in descending order. Users will be able to sort the table descending or ascending by any column containing a numeric value.
Interpretation of results in the grid
If the user has specified a non-existing domain, the grid should explicitly state that.
Some of the scraping results may return errors due to various reasons like accounts privacy settings or technical failures. The grid should explicitly state which of the results were returned with an error. This is to differentiate between the cases where data didn’t exist and where scrapers failed to retrieve the data.
It would be nice to have something like a progress bar in the cells while the grid is loading. This is because we have a different pace of populating the grid cells depending on the data source.
Users will be able to perform the following actions with the search:
List of previous searches
The system will store up to 20 latest searches.
Users will be able to access their previous searches and perform the same actions as mentioned above.
Behance
