对品牌来说，订单数据是较为重要的数据板块，也是其进行数据分析时常用的数据，那么，订单数据包括哪些模块？在实际业务中，订单数据又是怎样被应用和分析的？本篇文章里，作者便做了总结和分析，以前来看一下。

订单数据和会员数据肯定是各个品牌最重要的数据，也是数据分析最常用的数据。这次先聊一下订单数据，其中细节太多欢迎讨论。

订单数据主要分为线下订单、线上订单。其中线上订单又分为自有商城以及各平台商城。

因为品牌的一方数据通常是指可以拿到的个体级别的数据，所以不同渠道供应商提供的统计级别的数据暂不包含在这里。

一、线上平台商城

现在品牌能拿到的线上平台订单数据基本只有通过运营商提供的天猫订单，又因为个人数据安全政策的推进，天猫订单个人信息的部分也发生了一些变化。

1. 天猫

最初的天猫数据无论消费者是不是品牌的会员都可以获取到消费者的AlipayID，收件人手机号以及详细的住址等个人信息。

当时这类数据的处理，会有消费者是以家庭为单位好一些还是以个人为单位好一些的问题。解释起来也比较好理解，购买的产品可以寄回住的地方，也可以寄给父母。所以AlipayID和手机号就会出现多对多的关系，在品牌做oneid打通时也会带来一些逻辑上的矛盾，需要根据品牌产品的使用场景或侧重点补充oneid的判断逻辑。

但是个保法推出后这类信息就比较敏感了。当然天猫也曾短时间内推出过ouid、omid这类的过渡ID。目前一些背靠阿里的CRM公司可以通过会员通的会员号，将品牌会员的订单数据和自有渠道的订单数据打通，当然本质上还是通过会员手机号完成的。所以个保法推出后，品牌能拿到可用的天猫订单数据就仅剩会员这部分了。但是品牌可以直接通过天猫数据银行去对天猫的全量订单做分析以及站内的二次触达。

2. 京东

京东订单不少品牌是以自营店的形式与京东合作的，所以大部分品牌是拿不到京东订单的数据。当然一些体量比较大的集团可以与京东合作拿到数据。

目前各个品牌查看京东的数据还是通过京东数纺。但是现在京东貌似也有开放一点的倾向，京东会员通以及京东到家等合作可以回传相关的订单数据，一些字段会用md5加盐后再md5的加密形式给到。有意向的品牌可以沟通起来。

3. 抖音/拼多多/小红书

这三个渠道合并在一起聊是因为在经历的项目中都没有接触到相关的数据。如果有谁接触过可以沟通一下。

抖音因为直播以及短视频的火热也成为品牌的一个主战场，字节也将抖音电商的业务独立了出来。

拼多多是一个超出预期的渠道，一些高端品牌也在拼多多上运营了自己的店铺，理由是品牌如果不自己开店铺一些渠道商也会去开，所以就索性自己运营了。

小红书这类内容分享性平台也渐渐有了自己的商城系统，各个品牌也会基于品牌的特性去评估要不要拓展这个渠道。

二、线上自有商城

目前因为各个平台的一些规则限制，不少品牌开始规划构建自有线上商城。相对来说优势包括可以结合品牌形象去做UI设计，更全面的订单数据，商城内访客的浏览轨迹数据。这些都可以转化成为品牌的一方数据，并且数据的分析维度可以从购买阶段拓展到兴趣阶段，从而去做各类优化。

缺点当然也很明显，开发运营的成本，以及最重要的引流问题。如何给消费者一个理由来你的自有商城购买是品牌需要回答的问题。渠道限定的产品以及额外的会员权益可能是目前稍微好一点的答案。

1. 官网

一般有官网商城的品牌都是很早就开始运营的品牌，奢侈品以及服饰类的品牌会多一些，大部分在早期就开始有了自己的会员体系。但因为官网监测回传的是cookie，所以历史数据的价值不大，如果没有将相关的浏览数据打在会员号上的话，那么就没法做到购买的归因分析，页面路径优化也就断掉了。

不过目前官网为各个品牌带来的销售份额都是逐年递减，其中一些渠道限定的新品也会通过会员体系、导购、MA等渠道传递给忠诚客户，官网产生的数据也的确是不多了。

2. 小程序

目前不少品牌都在微信小程序内推出了自有的小程序商城，而且因为微信生态的原因scrm也和小程序商城有很多的交互场景。

微信商城的优势肯定是在微信体系内，有比较好的引流基础，而且开发的成本也没有之前那么高，再结合微信生态内优惠券、红包、转盘抽奖等活动小程序的交互引流，已经成为了一种趋势。

微信商城内除了实物商城，为了配合一些scrm的会员权益，也有一些品牌开发了积分商城，积分商城内一般除了一些实物、周边奖品外，也有三方合作的会员权益（腾讯视频，QQ音乐等）。

当然微信商城埋点的浏览数据可以通过unionID和公众号，scrm或其他微信系的数据打通，为数据的分析、应用提供了更多的可能性。

目前除了微信，京东以及支付宝也有了自己的小程序商城，可能与微信相比是否有强ID可以和其他的数据打通会是一个问题，目前这类的数据接触到的不多，后续有新的了解再来分享。

三、线下订单

线下订单就不多说太多了，POS系统的数据也已经非常的成熟。数据质量根据不同的行业特性以及成熟程度会有一些差异。

当然现在从门店送出去的外卖类数据（饿了么、美团等）或是线上下单线下领取我比较倾向于归为门店数据。与线上订单相比会有更多的触客机会以补充一些信息，而且门店在的地方也包含一些隐性信息，这类补充信息在主数据的漫谈中有一些涉及。

四、订单数据相关

1. 订单相关表

一般订单数据主要包含订单主表、订单明细表以及各类字段配合的主数据。

订单主表内一笔订单一行数据，订单ID为主键，数据包含这笔订单的整体信息，大致分为这样的几部分：

• 购买渠道相关（门店、渠道、购买形式、导购ID等）；
• 消费者相关（会员号、平台id等）；
• 购买产品相关（总金额、购买件数、运费、折扣金额等）；
• 支付相关（支付账号、支付渠道、实际支付金额、支付时间等）；
• 物流相关（物流形式、物流单号、收件人信息等）；
• 补充字段（首单标识，大单标识等）；
• 状态相关（订单ID，订单状态，状态时间）。

订单明细表往往会继承一部分订单主表的字段，一般是订单ID和sku id双主键，主要会包含这笔订单更详细的单品信息，例如这笔订单每个sku的数量以及附属信息（赠品标识、所属品类等）。

2. Omni-channel订单整合

多渠道订单整合往往是一个相对棘手的问题。各渠道的订单数据一般会做一些简单的清洗后直接先落到ods层，不同品牌的数据是不是需要分表可以根据实际的情况确认，跨渠道的数据整合一般不在ods层完成。各个渠道的订单整合会在dw层完成，其中一些合并、清洗规则，ID的打通需要根据实际情况做相应的设计和开发。

如果上游数据的逻辑产生变化这里也要同步做调整，所以上游数据有变化要及时的同步信息。

另外一个需要考虑的是上游各个渠道数据的接入时间要互相协调，如果某天一个渠道数据有问题（缺数或没有按时传数）可能会影响合并后的数据。因为相关的标签或数据分析基本都是从这套整合后的数据中产出，所以这套表出问题影响的范围就会很大了，基本会影响所有的下游系统（CRM、MA、Dashboard）。

3. 订单的状态处理

订单的状态这里仅聊两种情况，退单以及订单的状态变化。

退单其实很多时候难以避免，有的时候可能下单和退单不是同一天发生的（订单数据一般按时间分区增量更新），所以一般退单会生成一笔新的订单，金额是负数，并且会标注上原单ID以供查询。也有一些品牌可能会有一张独立的退单表。

退单在一些业务场景下也是比较难处理的，例如积分/会员等级的退还，首单奖励等。如何处理退单以及退单的影响范围需要小心处理。

另外就是订单状态的变化，这类问题主要是发生在线上订单，订单状态从下单、支付、发货、送达、确认收货会经历各个状态，在确认收货之前订单都可能会变成无效订单。

而天猫的订单大多数都是收货后自动确认收货的，导致最终状态有比较长的滞后性，如何处理这类数据也是比较头疼的。一些该渠道体量不大的品牌也有等到订单状态变为确认收货后再回传入库的情况。

4. 订单数据的应用

订单数据的使用场景其实是非常多的，后面可能会专门谈一下，这里先简单列举一些场景。

品牌最常用的一般是RFM模型，也会开发对应的标签，结合会员等级可以做更精细的高价值客户细分；另外以个人的订单视角可以做首单和尾单的分析；以某些品类为视角则可以做同单，前后单的关联性分析；针对一些特定的消费场景例如生日，节日可以做专项的场景分析；也可以根据特定的数据模型去做特殊人群的甄别例如黄牛和羊毛党。

当然根据数据更新频率以及数据颗粒度，也可以做一些Dashboard更直观地了解业务趋势。

以上是针对项目中遇到的一些订单数据介绍，后续如有补充的内容会再行修改。

当然这也肯定不是全面的介绍，每个品牌都会有自己的订单数据逻辑，因为行业会有不同程度的差异，即使是相同的行业不同的供应商数据也会有些许不同。订单数据遇到的问题也是多种多样，欢迎各类讨论共同学习。