Every Chinese marketplace gives you data. None of them give you the same data in the same way. If you are trying to consolidate reporting across Tmall, JD.com, and Douyin, you have discovered that each platform has its own data model, its own export formats, and its own idea of what counts as a completed order.
This article breaks down the practical differences in how each platform structures and delivers data, and what that means for brands trying to build a unified view of their China operations.
Platform Data Philosophies
Before comparing specific data fields, understand that each platform was built around a different commerce model, and that shapes every aspect of how data is structured.
Tmall is a brand storefront platform. Data is organized around the store, the product catalog, and the transaction. Tmall’s data model assumes you care about brand health, competitive positioning, and long-term customer value.
JD.com is a logistics-first platform. Data emphasizes fulfillment, delivery, and inventory management. JD’s data model reflects its warehouse network and same-day delivery infrastructure.
Douyin is a content commerce platform. Data ties every transaction to the content that drove it — which video, which livestream session, which creator. Douyin’s data model is fundamentally attribution-first.
Data Structure Comparison
Order Data
| Field | Tmall | JD.com | Douyin |
|——-|——-|——–|——–|
| Order ID format | Numeric, 18-20 digits | Numeric, starts with platform code | Alphanumeric with session prefix |
| Order status values | 6 statuses | 8 statuses | 5 statuses |
| Payment confirmation | Alipay settlement callback | JD Pay or third-party | Douyin Pay |
| Shipping data | Linked via logistics partner API | Integrated (JD Logistics) | Third-party logistics reference |
| Return/refund model | 7-day no-reason return standard | Category-dependent | Creator/shop-dependent |
The most common integration headache: order status definitions do not map 1:1 across platforms. Tmall’s “shipped” includes JD’s “picked” and “in transit” stages. Douyin’s “completed” means something different than Tmall’s “confirmed receipt.” Your normalization layer needs explicit mapping rules for every status transition.
Product and SKU Data
| Aspect | Tmall | JD.com | Douyin |
|——–|——-|——–|——–|
| SKU structure | Hierarchical (SPU > SKU) | Flat with variant attributes | Content-linked SKUs |
| Product categories | Tmall category tree | JD category system | Douyin product taxonomy |
| Listing data points | 50+ per product | 30+ per product | 20+ per product + content metadata |
| Image requirements | 800×800 minimum, white background | Similar to Tmall | Vertical video-first, images secondary |
| Price fields | List price, promo price, coupon price | List price, JD price, member price | Anchor price, live price, coupon stack |
The SKU mismatch problem is real. The same physical product might be SKU-TM-001 on Tmall, 10029384 on JD, and linked to three different Douyin content pieces with their own identifiers. Without a master SKU mapping, you cannot calculate true unit economics across channels.
Financial Data
| Metric | Tmall | JD.com | Douyin |
|——–|——-|——–|——–|
| Commission structure | Category-based % (2-5%) | Category-based % (3-8%) | Per-transaction (1-5%) + content fees |
| Settlement cycle | T+7 to T+15 | T+1 to T+7 (JD Logistics) | T+7 to T+14 |
| Fee transparency | Detailed breakdown available | Moderate detail | Limited, bundled with content costs |
| Currency | RMB | RMB | RMB |
| Invoice/fapiao | Golden Tax integrated | Golden Tax integrated | Golden Tax integrated |
Settlement timing differences mean your cash flow view is always a mix of recognized and unrecognized revenue. A Douyin sale from last Tuesday and a JD sale from the same day might settle 10 days apart.
Marketing and Traffic Data
| Metric | Tmall | JD.com | Douyin |
|——–|——-|——–|——–|
| Ad platform | Zhitongche, Diamond Booth | JD Express, JD DMP | Ocean Engine |
| Attribution model | Last-click, 15-day window | Last-click, 7-day window | Content-based, real-time |
| Organic traffic data | Search ranking, category traffic | Search + recommendation | Algorithm feed, hashtag, search |
| KOL/influencer data | Limited, via Taobao Live | Limited | Native (creator linked to every sale) |
| Available via API | Yes (authorized partners) | Yes (authorized partners) | Yes (limited endpoints) |
Douyin’s content-native attribution is the most granular of the three. You can see exactly which 15-second video drove a purchase. But this data does not map to Tmall’s search-based attribution or JD’s category-based traffic model, making cross-platform ROAS comparison an apples-to-oranges exercise unless you normalize the attribution framework.
API Access and Data Export
| Aspect | Tmall | JD.com | Douyin |
|——–|——-|——–|——–|
| API maturity | Mature, well-documented | Mature, logistics-focused | Evolving rapidly |
| Authentication | OAuth 2.0 via Taobao Open Platform | JD Open Platform key + secret | Douyin Open Platform OAuth |
| Rate limits | Per-app, varies by API tier | Per-app, moderate | Stricter, content APIs separate |
| Bulk export | CSV from seller center | CSV/Excel from seller center | Limited bulk export |
| Real-time webhooks | Order and logistics events | Comprehensive logistics events | Limited |
| Data retention | 90 days standard in seller center | 90 days | 30-60 days for some metrics |
Data retention is a hidden trap. If you are not pulling data regularly, you lose access to historical detail. Tmall and JD retain 90 days in the seller center; Douyin can be as short as 30 days for certain analytics. Your integration must run continuously, not as an ad-hoc export.
The Normalization Challenge
The core problem is not accessing the data — APIs exist for all three platforms. The challenge is normalization: making data from fundamentally different systems comparable.
To build a unified view, you need:
1. Master SKU mapping that links platform-specific product IDs to a single internal identifier
2. Order status harmonization that converts platform-specific status flows into a common lifecycle
3. Financial normalization that accounts for different commission structures, settlement timing, and fee bundling
4. Attribution alignment that makes cross-platform marketing ROI comparable despite different attribution models
5. Timezone and calendar handling for promotions (618, Double 11, Douyin flash sales) that span different platform timelines
Building this normalization layer in-house is a 6-12 month engineering project that requires deep knowledge of each platform’s data model and the ability to adapt when platforms change their APIs — which happens multiple times per year.
Practical Recommendations
If you sell on one platform: Use the seller center’s native reporting. It is good enough.
If you sell on two platforms: You can probably manage with manual exports and a well-structured spreadsheet, but budget for 20+ hours per month of finance team time.
If you sell on three or more platforms: Manual reconciliation breaks down. Invest in a platform that handles extraction, normalization, and delivery to your ERP. The cost of the platform is less than the cost of the errors you are making without it.
—
Digate connects to Tmall, JD.com, Douyin, Pinduoduo, RED, and 30+ other platforms. We handle the normalization so your data arrives in your ERP clean, consistent, and ready for analysis. [See how it works](https://calendly.com/sanja-digate/30min).