How Kevin changed the world
Recently, I landed the data kanban with my team, and made a case review on how to carry out data burying, data cleaning and data kanban establishment. The pits and difficulties encountered in the process are also summarized here.
Data kanban can be completed by visual data tools or by building data background. Different roles represent different roles
Leaders: see their business progress, suggest business changes and risk control
Data BP: chart model, digital field update, data viewing efficiency, core data mining
Product Manager: Product optimization suggestions
Operations Manager: Activity optimization recommendations
Whether the data report is graphical or tabular, it needs to be clear about the required fields and boundaries. However, the field is given by the data demander, and the understanding of the same data field may be different between the developer and the demander.
Once the two parties understand the difference, it will cause the data report construction can not start or data error.
Therefore, the process of data burying document is very important, and the demander needs to explain the meaning and logic behind the burying field. Some fields are simple, such as a page UV \ PV, but some fields are the underlying logic: successful transactions, referring to successful orders within orders.
Around the buried data field, three key words should be clear: event, parameter and value
Event: What is the user’s behavior or action at this time
Parameters: What is the buried data, such as an order or a page click
Data: Specific value size: what it is.
Some of the data can be stored in the team server after burial, which is the fastest and easiest way to analyze it. But need to pay attention to is similar to the public number, small program such wechat ecological products. It is impossible to export the corresponding data of the front end, and to link with the corresponding transformation and e-commerce data, it requires the cooperation of background development.
Either do your own data mining or use third-party tools. There are also many open source methodologies available online
Only when the summary data enters the data warehouse can the construction and cleaning of the data report be completed.
The data under the product of each team has different latitude, so there are various data reports that can be formed. Therefore, sometimes during the construction of data reports, I think that too much entangling in data reports will make the work become bottomless, just like a bottomless pit.
The core requirement for data reporting is to be able to look at the good and bad of the current product and make recommendations for optimization
But it should be clear what data requirements should be handled by the product manager and what data requirements should be handled by the BP.
Generally, I suggest that if there is a dedicated data product manager or data analyst in the team, the product manager should be responsible for the data requirements of his own module or product line, and the data of other product lines should be consolidated in a large report.
Collated by data product manager and BP, and viewed by standing on the business line.
In other words:
Operation side: Activity data requirements
Product side: own product line or module data requirements
Service side: The data required by the service side
Note that often the product-side data requirements are already met on the business side. A report is not only the product data, but also the channel, transaction volume, conversion number, etc., as well as the data required by the business side (market, sales).
Well, that’s our original for today. I will write 2 original articles per week