Back

Enterprise Data Analysis: From Data Integration to a Closed Decision Loop

Tengence Team ·
Technical Solutions Data Analytics E-commerce
Enterprise Data Analysis: From Data Integration to a Closed Decision Loop

Summary: Enterprise data problems are rarely about missing data. Data is scattered across traffic, advertising, order, support, and user systems; metric definitions are inconsistent; and analysis results never reach budget, operations, or inventory decisions. For data to produce real business value, you need a complete loop from collection and governance through analysis to action. This guide follows that system end to end: a four-layer analysis model, data collection and standardization, funnel and attribution analysis, retention and segmentation, dashboard design, an anonymized e-commerce case, and how to calculate project ROI.

1. The Four Layers of Data Analysis

Data analysis capability can be grouped into four layers by decision depth. Companies do not need to start by building a complex AI decision system. The more sensible path is to unify data and metrics first, then move step by step from describing results to diagnosing causes, predicting trends, and recommending actions.

1.1 The four-layer analysis model

Analysis layer Question it answers Typical output Core capability
Descriptive analysis What happened? Reports, dashboards, KPI monitoring Data aggregation and visualization
Diagnostic analysis Why did it happen? Drill-down analysis, root-cause location, attribution analysis Multi-dimensional correlation and problem decomposition
Predictive analysis What will happen? Trend forecasting, risk alerts Statistical models and machine learning
Prescriptive analysis What action should we take? Budget recommendations, automated rules, decision support Optimization algorithms and business rules

Some industry articles divide enterprise maturity by percentage, but any such ratio must state the survey sample, industry scope, statistical year, and measurement method at the same time. Without a traceable source, it is better treated as a maturity example than as an industry conclusion that applies to every company.

1.2 Inputs and boundaries of each layer

Descriptive analysis: one shared version of the facts

The goal of descriptive analysis is to let the team see the same set of numbers. Core work includes unifying metric definitions, building data marts, producing operating reports, and monitoring key metrics. For example, sales revenue should state whether refunds, discounts, and taxes are included, and user counts should state the deduplication rule and the statistical time window.

It can answer "what is today's sales revenue", but it cannot by itself explain why revenue changed.

Diagnostic analysis: locating the cause

Diagnostic analysis drills down by channel, device, region, user segment, and product dimension to find the specific reason a metric moved. Funnel analysis, attribution analysis, correlation analysis, and segmentation analysis all belong at this layer.

It helps a team identify which step a conversion drop happened at, but correlation does not prove causation, and important conclusions still need validation through experiments or controlled analysis.

Predictive analysis: spotting risk early

Predictive analysis uses historical data and models to estimate future trends, such as sales forecasting, churn prediction, and inventory demand forecasting. Model output should include the forecast horizon, confidence interval, training data range, and error metrics, not a single number torn from its context.

Prescriptive analysis: connecting to action

Prescriptive analysis combines forecast results with inventory, budget, margin, and business constraints to generate budget allocation, outreach strategy, or inventory configuration recommendations. Before any automated execution, set permissions, thresholds, human review, and a rollback mechanism.

1.3 Data analysis maturity assessment

Maturity Data foundation Analysis capability Decision mechanism
Level 1: Initial Data scattered, definitions inconsistent Relies on manual reports Decisions mostly driven by experience
Level 2: Basic Core data collected Can produce basic dashboards Metrics reviewed on a regular cadence
Level 3: Defined Metrics and data models unified Supports funnel, segmentation, and attribution Analysis results enter business review meetings
Level 4: Managed Data quality monitored continuously Supports forecasting and alerts Strategies validated through experiments
Level 5: Optimized Data, models, and permission systems mature Supports prescriptive analysis Automated decision and rollback mechanisms in place

2. Data Collection and Integration: The Foundation of Analysis

The first step in data analysis is not choosing a BI tool. It is deciding which business objects, events, and metrics need to be tracked. An executable data pipeline usually looks like this:

User touchpoint → Tracking code → Data collection → Data cleaning → Data warehouse → Analytics app → Business action
  ↓                  ↓                 ↓                ↓               ↓                ↓              ↓
Website/App        JS/SDK             API              ETL          Data Lake         BI/AI        Ops/Budget/Inventory
Ad platforms       Click ID       Real-time stream   Dedup      Standardization     Dashboard    Experiments/Review

2.1 Full-funnel data tracking

Business stage Main data Common techniques Downstream use
Traffic acquisition Source, channel, keyword, creative ID UTM parameters, click ID Channel evaluation and attribution
Landing page interaction Page URL, clicked elements, dwell time Page instrumentation, heatmaps Page experience and conversion analysis
User behavior Browse path, scroll depth, events Event tracking, session recording Funnel and segmentation
Conversion behavior Add-to-cart, order placement, payment Conversion tracking, order system Revenue and conversion analysis
Post-purchase behavior Repeat purchase, refunds, support contact CRM, support system Retention, LTV, and risk analysis

Every event should define an event name, trigger condition, attribute fields, user identifier, timestamp, and data owner. Without an event dictionary, the same event name can mean different business behaviors in different systems.

2.2 Data source onboarding

Data source Typical data Update frequency Onboarding focus
Website/App PV, UV, clicks, conversions Real time or minute level Instrumentation version and anonymous user identifier
CRM/User system User attributes, lifecycle, behavior records Real time or daily User ID and access control
Order/Transaction system Orders, payments, refunds, discounts Real time Order status and amount definitions
Ad platforms Impressions, clicks, spend, conversions Hourly or daily Channel ID and attribution window
Support system Conversations, tickets, satisfaction Real time or daily Masking, classification, and correlation IDs
Social media Engagement, followers, content performance Daily Platform field mapping
Third-party data Industry, competitor, sentiment Weekly or monthly Source licensing and update time

Prioritize the systems that directly affect operating decisions. Solve data quality and definition problems first, then widen the scope. Do not onboard data you cannot use or verify just to grow the data volume.

2.3 Data cleaning and standardization

Step What it processes How it is verified
Deduplication Remove duplicate events and duplicate orders Unique ID, time window, idempotency checks
Missing value handling Identify missing fields and separate fixable from unfixable Missing-rate monitoring, business rule checks
Formatting Unify dates, currency, encoding, and enumerated values Schema validation
Anomaly detection Identify abnormal traffic, amounts, and event volumes Thresholds, distribution, historical trend comparison
Relationship building Build relationships between users, orders, products, and channels Primary keys, foreign keys, join success rate
Quality scoring Record completeness, timeliness, consistency, and accuracy Data quality dashboard

Set up baseline data standards:

Data type Standardization requirement
User ID Unify the cross-system identifier, and separate the anonymous ID from the signed-in user ID
Timestamp Unify the time zone, for example UTC+8, and use the ISO 8601 format
Amount State currency, tax, discounts, refunds, and retained precision
Channel name Use channel codes and a versioned mapping table
Event name Unify naming, trigger conditions, and field definitions
User permissions Apply least-privilege access to support records, behavior data, and sensitive attributes

3. Core Data Analysis Methods

3.1 Funnel analysis: locating conversion loss

Funnel analysis identifies where users drop out between the first visit and conversion. Common designs include:

Scenario Funnel steps Optimization direction
User registration Visit → Register → Activate Reduce form and verification friction
E-commerce purchase Browse → Add to cart → Checkout → Pay Improve product, checkout, and payment experience
Content marketing Browse → Read → Engage → Convert Strengthen the bridge from content to action
App growth Click → Download → Install → Activate Reduce drop-off in download and first use

Example: an anonymized e-commerce funnel

The figures below are example analysis data. Industry benchmarks for a specific business must be built separately from business type, device, region, and observation window, and should not be applied directly as industry standards.

Step Users Step conversion rate Reference example Gap
Product browse 100,000 100% — —
Add to cart 28,000 28% 35% 7 percentage points lower
Enter checkout 14,000 50% 65% 15 percentage points lower
Complete payment 7,000 50% 67% 17 percentage points lower
First step to payment 7,000 7% 15% 8 percentage points lower

The example shows meaningful room to improve both the checkout-to-payment step and overall payment conversion. The next step is to break down payment failure reasons, device, payment method, discount usage, and stock status, rather than judging the problem from the overall ratio alone.

3.2 Attribution analysis: evaluating touchpoint contribution

Attribution analysis allocates conversion credit across touchpoints and works well for informing channel budget and content strategy. Common models:

Model Allocation method Best for Main limitation
Last click All credit to the last click Short-path performance advertising Ignores earlier touchpoints
First click All credit to the first touchpoint Initial acquisition and brand reach Ignores later conversion actions
Linear Credit split evenly across touchpoints Quickly establishing a shared definition Does not reflect real contribution differences
Time decay Higher weight closer to conversion Businesses with longer decision cycles Depends on parameter settings
Data-driven Contribution computed from path data Multi-channel, large-sample businesses Needs stable data and model validation

Attribution output is an allocation of credit, not proof of incremental causation. If you adjust budget from model results, validate the real effect further with A/B tests, control groups, or incrementality experiments.

3.3 Retention analysis: measuring long-term value

Retention analysis starts by defining the user cohort, first action, return event, and observation window. Common metrics:

Metric Definition How to use it
Day-1 retention Share of users still performing the target action on day 1 after the first action Evaluate the first experience
Day-7 retention Share of users still performing the target action on day 7 after the first action Evaluate short-term value
Day-30 retention Share of users still performing the target action on day 30 after the first action Evaluate sustained usage
LTV/CAC Ratio of user lifetime value to acquisition cost Evaluate growth sustainability

Numbers such as "day-1 retention above 40%" or "LTV/CAC above 3:1" are reference ranges for specific products and industries. Real judgment should combine product type, user source, statistical window, revenue recognition, and cost scope.

3.4 Segmentation: turning differences into action

The goal of segmentation is not to add more tags. It is to identify user groups that a business action can actually serve.

Segmentation dimension Examples Business action
User attributes Region, company size, device Adjust product and outreach approach
Behavioral traits Activity level, purchase frequency, browse depth Tiered operations and content recommendations
Lifecycle New users, active users, churn-risk users Design stage-based outreach
Value contribution High, medium, and low value Allocate service and marketing resources
RFM Recency, frequency, monetary Identify priority retention groups

RFM usually standardizes and scores recency, frequency, and monetary separately. Scoring rules, time windows, and group proportions should follow the actual business distribution; fixed scores should not be treated as a universal conclusion.

4. Dashboards and Alerting

4.1 Dashboard design principles

An effective dashboard serves a specific decision scenario instead of piling up every available metric. Recommended principles:

  1. Goal-driven: name the user, the decision question, and the update frequency.
  2. Transparent definitions: show metric definitions, calculation methods, data refresh time, and the owner.
  3. Clear hierarchy: drill from the executive summary down to channel, user, product, and order detail.
  4. Linked to action: give every core metric an owner, a threshold, and a handling action.
  5. Tiered permissions: control revenue, user attributes, and support data by role.
  6. Avoid overload: keep only the small set of core metrics that drive decisions.

4.2 An enterprise metric framework

Module Example metrics Update frequency Main users
Growth New users, new orders, new revenue Daily Growth and operations teams
Traffic UV, PV, source, CTR, acquisition cost Daily or hourly Marketing team
Conversion Add-to-cart rate, payment conversion rate, order value, repeat purchase rate Daily Operations team
Revenue GMV, net revenue, gross margin, channel ROI Daily or weekly Finance and operations teams
Users DAU, MAU, retention, LTV, churn risk Daily or weekly Product and user teams
Inventory Sales forecast, inventory turnover days, stockout rate Daily Supply chain team

GMV, revenue, gross margin, and profit must each be defined separately. Advertising ROI should also state whether the denominator is ad spend alone or the full investment including people, platform, and operating costs.

4.3 Alerting

Alert type Example rule Follow-up action
Absolute value Metric exceeds the business threshold Notify the owner and check data quality
Period-over-period Change versus the previous period exceeds the threshold Break down by channel, device, and user group to locate the cause
Year-over-year Same-period change is abnormal Rule out seasonality, holidays, and campaign factors
Trend Several consecutive periods moving in the same direction Assess whether the strategy needs adjusting
Data quality Latency, missing data, duplicates, or abnormal volume exceeds the threshold Suspend use of the abnormal data and repair the pipeline

The alerting system should define alert severity, notification channel, handling deadline, and closing conditions. Alerts without a handling process turn the dashboard into yet another source of noise.

5. Case Study: Data Analysis at an Anonymized E-commerce Company

5.1 Baseline problems

An e-commerce company needed to manage advertising, order transactions, user behavior, support, and inventory data at the same time. Its main problems:

Problem Baseline Business impact
Hard to compare channel performance Ad ROI about 1:1.2 No shared basis for budget changes
Slow analysis turnaround One operating analysis took about 2 weeks Hard to react to market changes in time
Late churn detection Monthly churn rate about 15% No early outreach mechanism
Unstable inventory forecasting Inventory turnover about 90 days Capital tied up and higher overstock risk

The data in this case illustrates the analysis process and metric definitions; it does not mean every company will reach the same results. Before publishing, add the actual observation window, sample size, data sources, and experiment design.

5.2 Data onboarding and unified definitions

The data sources onboarded in the case and their average daily record counts are below. Records from different sources are not the same kind of event, so record volume cannot be read directly as user count, order count, or revenue scale.

Data source Onboarding method Daily records Main use
Website traffic Instrumentation and logs About 500,000 Traffic, page, and conversion analysis
Order system API integration About 100,000 Order, payment, and refund accounting
Advertising Platform API About 1,000,000 Spend, clicks, and channel attribution
User behavior Event tracking About 2,000,000 Funnel, retention, and segmentation
Support system Webhook About 50,000 Service issues and user feedback

The unified data layer focused on user ID, order ID, product ID, channel ID, event time, and amount fields, and built an event dictionary and a metric dictionary. Ad conversions, order payments, and refunds must use the same attribution window before they can be compared meaningfully.

5.3 Implementation path

Phase 1: Build the data warehouse

Onboard core data sources and set up collection, cleaning, validation, and storage processes. The point is not to connect every system at once, but to prioritize the traffic, order, advertising, and user behavior links that most affect operating decisions.

Phase 2: Build core dashboards

Build four dashboards covering growth, channels, users, and inventory:

Phase 3: Build analysis models

Build multi-touch attribution, sales forecasting, churn prediction, budget allocation, and inventory optimization models as data quality and sample size allow. Every model should record its input data, training cycle, validation metrics, scope of application, and conditions for human intervention.

Phase 4: Close the decision loop

Connect monitoring, analysis, experimentation, and review: find the problem, form a hypothesis, validate it with an incrementality experiment or control group, then update budget, operations, and inventory strategy. Model output should not affect all users directly without review and rollback mechanisms.

5.4 Case results and metric definitions

Metric Before After Change
Decision cycle 2 weeks 2 days Shortened by about 85.7%, calculated from 14 days to 2 days
Ad return ratio 1:1.2 1:3.3 Ratio up 175% relatively, not the same as net ROI
Acquisition cost RMB 180 RMB 99 Down RMB 81, a relative decrease of 45%
Monthly churn rate 15% 8% Down 7 percentage points, a relative decrease of about 46.7%
Inventory turnover days 90 days 45 days Turnover days reduced 50%
Reporting workflow Manual consolidation Automated dashboard Less repetitive reporting work; efficiency must be calculated from work hours

These results must be read together with sample size, observation window, channel scope, business activity, and control design. A before-and-after comparison alone cannot prove that every change was caused by the data analysis system.

5.5 How to calculate ROI

The original case material listed system build, training, and ongoing operations costs, but the stated total investment and its return ratio were not consistent with each other. This article does not keep that unvalidated ROI conclusion.

A data analysis project should first align the definitions of investment and return:

Benefit/investment ratio = attributable incremental benefit ÷ total project investment
Net ROI = (attributable incremental benefit - total project investment) ÷ total project investment

Total project investment should state whether it includes:

Returns should also be separated into:

If RMB 1,200,000, RMB 200,000, and RMB 300,000 are all first-year investments, then total first-year investment is RMB 1,700,000. If RMB 12,000,000 is confirmed as attributable incremental benefit, the benefit/investment ratio is about 7.06:1; but if RMB 12,000,000 is only total revenue growth, it cannot be used directly as ROI output. Published cases should confirm the nature of the benefit, the cost scope, and the attribution method before releasing a specific ROI figure.

6. Roadmap for Data-Driven Decisions

Phase Reference timeline Goal Key deliverables
Foundation 1–3 months Establish collection, governance, and baseline reporting Data model, event dictionary, core dashboards
Analysis capability 3–6 months Support diagnostic analysis Funnel, attribution, retention, and segmentation analysis
Forecasting capability 6–12 months Build forecasting and alerting Forecast models, monitored metrics, alerting
Intelligent decisions 12 months and beyond Connect models to business action Strategy recommendations, experiment system, automated rules

Actual timelines depend on the number of data sources, historical data quality, organizational collaboration, and business complexity. Phases can overlap, but you should not chase complex models while metric definitions are still inconsistent.

6.1 Implementation notes

Risk Response
Data silos Build a unified data model, master data, and metric dictionary
Unstable data quality Monitor completeness, timeliness, consistency, and accuracy
Too many tools Evaluate integration capability, ease of use, and total cost of ownership by business scenario
Analysis never lands Bind an owner, threshold, and business action to every metric
Models misused Define scope of application, validation metrics, human review, and rollback
Unclear ROI Define the baseline, observation window, and attribution method before the project starts
Permission and privacy risk Apply masking, least-privilege access, and access auditing

7. FAQ

Q1: What team setup does data analysis need?
A: Team size should follow the number of data sources, business complexity, and analysis goals. Common starting points:

Company size Minimum setup Recommended setup
Small (fewer than 50 people) 1 data analyst with an outsourced BI tool 1 data analyst plus 1 part-time data engineer
Medium (50–200 people) 2 data analysts plus 1 data engineer 3 data analysts, 1 data engineer, and 1 data scientist
Large (200 people and above) 5 data analysts, 2 data engineers, and 1 data scientist Build teams grouped by analysis, engineering, and science capability

Team size is not the only condition for success. Metric definitions, data quality, business owners, and experiment mechanisms matter just as much.

Q2: How do you measure the ROI of a data analysis project?
A: Separate the benefit/investment ratio from net ROI first, then fix the baseline and observation window. Count attributable incremental revenue, gross margin increment, cost savings, and reduced risk losses separately, and include system build, platform, implementation, labor, training, and ongoing operations in the investment. Total revenue growth cannot equal project benefit without an attribution and margin definition.

Q3: How do you choose a BI tool?
A: Evaluate along these dimensions:

Dimension What to look at
Ease of use Can non-technical staff query, analyze, and share on their own
Integration capability Can it connect to the existing data warehouse, business systems, and permission system
Metric management Does it support unified metrics, versions, and definition notes
Scalability Can it support growth in users, data volume, and analysis scenarios
Total cost of ownership Software, implementation, training, maintenance, and migration costs
Security and localization Permissions, auditing, deployment model, and local service support

Tableau, Power BI, Quick BI, FineBI, and Google Data Studio each fit different scenarios; do not choose on feature count alone. The tool has to match the data foundation, team capability, and business decision process.

Q4: Do the case figures apply to every company?
A: No. The metrics in the case are anonymized project data or example definitions. Real results depend on industry, traffic scale, data quality, product structure, campaign cycles, and experiment design. When publishing or citing a case externally, state the sample size, observation window, baseline, control method, and attribution method at the same time.

Q5: How should a data analysis project define investment and return?
A: Investment should at least cover system build, software, implementation, labor, training, and ongoing operations; return should be split into attributable incremental revenue, gross margin increment, cost savings, and risk avoided. Record the baseline at project kickoff, define the metric denominator, attribution window, and revenue recognition rule, and validate results with control groups or incrementality experiments.

8. Summary and Recommended Actions

Data-driven decision making is not about buying a BI tool. It is about building a complete loop from data collection and governance through analysis to action.

The core methods:

  1. Unify the data foundation: build an event dictionary, a metric dictionary, and user-to-order relationship rules.
  2. Raise analysis capability layer by layer: start with descriptive analysis, then move to diagnostic, predictive, and prescriptive analysis.
  3. Connect analysis to business action: funnel, attribution, retention, and segmentation results should each map to a specific optimization action.
  4. Build alerts around core metrics: stop accumulating reports and metrics that cannot drive decisions.
  5. Validate value with experiments: before-and-after comparisons only offer clues; incrementality experiments and control design are better for proving causation.
  6. Calculate ROI transparently: define investment, return, observation window, and attribution method, and do not treat revenue growth as project return.

Recommended starting sequence:

  1. Inventory data sources, metric definitions, and the biggest current decision pain point.
  2. Pick one core scenario where value can be validated quickly.
  3. Finish data collection, cleaning, quality validation, and the baseline dashboard.
  4. Form testable optimization hypotheses through funnel, attribution, or retention analysis.
  5. Evaluate results with experiments or control methods, then expand into forecasting and automated decisions.

Tengence provides data collection, analysis, and decision support capabilities that help enterprises build a data analysis system that can be validated and iterated step by step.

About Tengence

Data analysis runs through the measurement loop of public-traffic acquisition and private-domain conversion, one of the growth technology areas Tengence focuses on. Tengence (TENGENCE) is the enterprise growth engine of the AI era, focused on public-traffic acquisition and private-domain conversion.

Related Reading

Data Notes

The funnel, maturity, retention threshold, and ROI calculation examples in this article illustrate analysis methods. Where market size, industry ratios, or project returns are involved, rely on traceable reports, project data, and clearly stated statistical definitions.

Get Started

Get Started
Book a free expert consultation and diagnosis

← Previous: Unified Search and Recommendations: From Integrated Data to Coordinated Optimization Next: CTR Optimization in Practice: 5 Tactics to Raise Click-Through Rate Fast →
Consult
QR code

WeCom