對品牌來說，訂單數據是較為重要的數據板塊，也是其進行數據分析時常用的數據，那么，訂單數據包括哪些模塊？在實際業(yè)務中，訂單數據又是怎樣被應用和分析的？本篇文章里，作者便做了總結和分析，以前來看一下。

訂單數據和會員數據肯定是各個品牌最重要的數據，也是數據分析最常用的數據。這次先聊一下訂單數據，其中細節(jié)太多歡迎討論。

訂單數據主要分為線下訂單、線上訂單。其中線上訂單又分為自有商城以及各平臺商城。

因為品牌的一方數據通常是指可以拿到的個體級別的數據，所以不同渠道供應商提供的統(tǒng)計級別的數據暫不包含在這里。

一、線上平臺商城

現(xiàn)在品牌能拿到的線上平臺訂單數據基本只有通過運營商提供的天貓訂單，又因為個人數據安全政策的推進，天貓訂單個人信息的部分也發(fā)生了一些變化。

1. 天貓

最初的天貓數據無論消費者是不是品牌的會員都可以獲取到消費者的AlipayID，收件人手機號以及詳細的住址等個人信息。

當時這類數據的處理，會有消費者是以家庭為單位好一些還是以個人為單位好一些的問題。解釋起來也比較好理解，購買的產品可以寄回住的地方，也可以寄給父母。所以AlipayID和手機號就會出現(xiàn)多對多的關系，在品牌做oneid打通時也會帶來一些邏輯上的矛盾，需要根據品牌產品的使用場景或側重點補充oneid的判斷邏輯。

但是個保法推出后這類信息就比較敏感了。當然天貓也曾短時間內推出過ouid、omid這類的過渡ID。目前一些背靠阿里的CRM公司可以通過會員通的會員號，將品牌會員的訂單數據和自有渠道的訂單數據打通，當然本質上還是通過會員手機號完成的。所以個保法推出后，品牌能拿到可用的天貓訂單數據就僅剩會員這部分了。但是品牌可以直接通過天貓數據銀行去對天貓的全量訂單做分析以及站內的二次觸達。

2. 京東

京東訂單不少品牌是以自營店的形式與京東合作的，所以大部分品牌是拿不到京東訂單的數據。當然一些體量比較大的集團可以與京東合作拿到數據。

目前各個品牌查看京東的數據還是通過京東數紡。但是現(xiàn)在京東貌似也有開放一點的傾向，京東會員通以及京東到家等合作可以回傳相關的訂單數據，一些字段會用md5加鹽后再md5的加密形式給到。有意向的品牌可以溝通起來。

3. 抖音/拼多多/小紅書

這三個渠道合并在一起聊是因為在經歷的項目中都沒有接觸到相關的數據。如果有誰接觸過可以溝通一下。

抖音因為直播以及短視頻的火熱也成為品牌的一個主戰(zhàn)場，字節(jié)也將抖音電商的業(yè)務獨立了出來。

拼多多是一個超出預期的渠道，一些高端品牌也在拼多多上運營了自己的店鋪，理由是品牌如果不自己開店鋪一些渠道商也會去開，所以就索性自己運營了。

小紅書這類內容分享性平臺也漸漸有了自己的商城系統(tǒng)，各個品牌也會基于品牌的特性去評估要不要拓展這個渠道。

二、線上自有商城

目前因為各個平臺的一些規(guī)則限制，不少品牌開始規(guī)劃構建自有線上商城。相對來說優(yōu)勢包括可以結合品牌形象去做UI設計，更全面的訂單數據，商城內訪客的瀏覽軌跡數據。這些都可以轉化成為品牌的一方數據，并且數據的分析維度可以從購買階段拓展到興趣階段，從而去做各類優(yōu)化。

缺點當然也很明顯，開發(fā)運營的成本，以及最重要的引流問題。如何給消費者一個理由來你的自有商城購買是品牌需要回答的問題。渠道限定的產品以及額外的會員權益可能是目前稍微好一點的答案。

1. 官網

一般有官網商城的品牌都是很早就開始運營的品牌，奢侈品以及服飾類的品牌會多一些，大部分在早期就開始有了自己的會員體系。但因為官網監(jiān)測回傳的是cookie，所以歷史數據的價值不大，如果沒有將相關的瀏覽數據打在會員號上的話，那么就沒法做到購買的歸因分析，頁面路徑優(yōu)化也就斷掉了。

不過目前官網為各個品牌帶來的銷售份額都是逐年遞減，其中一些渠道限定的新品也會通過會員體系、導購、MA等渠道傳遞給忠誠客戶，官網產生的數據也的確是不多了。

2. 小程序

目前不少品牌都在微信小程序內推出了自有的小程序商城，而且因為微信生態(tài)的原因scrm也和小程序商城有很多的交互場景。

微信商城的優(yōu)勢肯定是在微信體系內，有比較好的引流基礎，而且開發(fā)的成本也沒有之前那么高，再結合微信生態(tài)內優(yōu)惠券、紅包、轉盤抽獎等活動小程序的交互引流，已經成為了一種趨勢。

微信商城內除了實物商城，為了配合一些scrm的會員權益，也有一些品牌開發(fā)了積分商城，積分商城內一般除了一些實物、周邊獎品外，也有三方合作的會員權益（騰訊視頻，QQ音樂等）。

當然微信商城埋點的瀏覽數據可以通過unionID和公眾號，scrm或其他微信系的數據打通，為數據的分析、應用提供了更多的可能性。

目前除了微信，京東以及支付寶也有了自己的小程序商城，可能與微信相比是否有強ID可以和其他的數據打通會是一個問題，目前這類的數據接觸到的不多，后續(xù)有新的了解再來分享。

三、線下訂單

線下訂單就不多說太多了，POS系統(tǒng)的數據也已經非常的成熟。數據質量根據不同的行業(yè)特性以及成熟程度會有一些差異。

當然現(xiàn)在從門店送出去的外賣類數據（餓了么、美團等）或是線上下單線下領取我比較傾向于歸為門店數據。與線上訂單相比會有更多的觸客機會以補充一些信息，而且門店在的地方也包含一些隱性信息，這類補充信息在主數據的漫談中有一些涉及。

四、訂單數據相關

1. 訂單相關表

一般訂單數據主要包含訂單主表、訂單明細表以及各類字段配合的主數據。

訂單主表內一筆訂單一行數據，訂單ID為主鍵，數據包含這筆訂單的整體信息，大致分為這樣的幾部分：

• 購買渠道相關（門店、渠道、購買形式、導購ID等）；
• 消費者相關（會員號、平臺id等）；
• 購買產品相關（總金額、購買件數、運費、折扣金額等）；
• 支付相關（支付賬號、支付渠道、實際支付金額、支付時間等）；
• 物流相關（物流形式、物流單號、收件人信息等）；
• 補充字段（首單標識，大單標識等）；
• 狀態(tài)相關（訂單ID，訂單狀態(tài)，狀態(tài)時間）。

訂單明細表往往會繼承一部分訂單主表的字段，一般是訂單ID和sku id雙主鍵，主要會包含這筆訂單更詳細的單品信息，例如這筆訂單每個sku的數量以及附屬信息（贈品標識、所屬品類等）。

2. Omni-channel訂單整合

多渠道訂單整合往往是一個相對棘手的問題。各渠道的訂單數據一般會做一些簡單的清洗后直接先落到ods層，不同品牌的數據是不是需要分表可以根據實際的情況確認，跨渠道的數據整合一般不在ods層完成。各個渠道的訂單整合會在dw層完成，其中一些合并、清洗規(guī)則，ID的打通需要根據實際情況做相應的設計和開發(fā)。

如果上游數據的邏輯產生變化這里也要同步做調整，所以上游數據有變化要及時的同步信息。

另外一個需要考慮的是上游各個渠道數據的接入時間要互相協(xié)調，如果某天一個渠道數據有問題（缺數或沒有按時傳數）可能會影響合并后的數據。因為相關的標簽或數據分析基本都是從這套整合后的數據中產出，所以這套表出問題影響的范圍就會很大了，基本會影響所有的下游系統(tǒng)（CRM、MA、Dashboard）。

3. 訂單的狀態(tài)處理

訂單的狀態(tài)這里僅聊兩種情況，退單以及訂單的狀態(tài)變化。

退單其實很多時候難以避免，有的時候可能下單和退單不是同一天發(fā)生的（訂單數據一般按時間分區(qū)增量更新），所以一般退單會生成一筆新的訂單，金額是負數，并且會標注上原單ID以供查詢。也有一些品牌可能會有一張獨立的退單表。

退單在一些業(yè)務場景下也是比較難處理的，例如積分/會員等級的退還，首單獎勵等。如何處理退單以及退單的影響范圍需要小心處理。

另外就是訂單狀態(tài)的變化，這類問題主要是發(fā)生在線上訂單，訂單狀態(tài)從下單、支付、發(fā)貨、送達、確認收貨會經歷各個狀態(tài)，在確認收貨之前訂單都可能會變成無效訂單。

而天貓的訂單大多數都是收貨后自動確認收貨的，導致最終狀態(tài)有比較長的滯后性，如何處理這類數據也是比較頭疼的。一些該渠道體量不大的品牌也有等到訂單狀態(tài)變?yōu)榇_認收貨后再回傳入庫的情況。

4. 訂單數據的應用

訂單數據的使用場景其實是非常多的，后面可能會專門談一下，這里先簡單列舉一些場景。

品牌最常用的一般是RFM模型，也會開發(fā)對應的標簽，結合會員等級可以做更精細的高價值客戶細分；另外以個人的訂單視角可以做首單和尾單的分析；以某些品類為視角則可以做同單，前后單的關聯(lián)性分析；針對一些特定的消費場景例如生日，節(jié)日可以做專項的場景分析；也可以根據特定的數據模型去做特殊人群的甄別例如黃牛和羊毛黨。

當然根據數據更新頻率以及數據顆粒度，也可以做一些Dashboard更直觀地了解業(yè)務趨勢。

以上是針對項目中遇到的一些訂單數據介紹，后續(xù)如有補充的內容會再行修改。

當然這也肯定不是全面的介紹，每個品牌都會有自己的訂單數據邏輯，因為行業(yè)會有不同程度的差異，即使是相同的行業(yè)不同的供應商數據也會有些許不同。訂單數據遇到的問題也是多種多樣，歡迎各類討論共同學習。