总结了近 3000 字，从大的场景切入、到小的关键指标，最后再通过一个案例来回答这个问题，希望能对大家有所帮助。

一，电商数据分析需围绕“成交”核心目标，“人、货、场”三个概念

电商的本质是零售，我们在做数据分析时，始终都要围绕“成交”这个核心目标。这其中就涉及到人、货、场，这三个概念：

• 人：流量、用户或会员；
• 场：每个人的理解不同，我个人认为，凡是能将人与货匹配，最终完成转化的都可以称之为场。如：搜索，推荐，推送，导航栏，活动，视频，图片，文本，直播等都属于场的范围。

这三个概念组合起来，就是电商需要核心关注的问题，也是我们数据分析的重点：

1. 不同商品需要放置在什么场中卖给用户？

举个例子，口红在搜索、短视频、直播场哪个渠道卖最好？不同商品适合的场是不同的，有巨大区别。比如很多女孩会通过观看短视频购买化妆品，在图片展示区买衣服，如果用错了场，商品的转化率会有明显差异。各位电商从业者是否知道不同的商品在哪些 “场”好卖，哪些难卖吗？如果知道，你会和现在采取不同的方法吗？

2. 不同场应该卖什么商品给用户？

导航栏、搜索推荐分别适合卖什么产品、卖什么特征的商品，打折券的 ROI 如何衡量，这些对于成交非常关键的洞察，是可以通过数据分析来判断的。

3. 不同用户需要的商品和场有何不同？

对不同用户画像，需要呈现哪类商品和相匹配的场。不同生命周期、不同级别的用户，应该采取什么样的运营手段？你们是否了解新用户首次购买路径？在哪些路径下最高？新用户倾向买什么产品？

二，电商增长需要关注的 10 大关键指标

了解完三个大的场景后，接下来就细分到各个场景的具体数据指标。这些指标是制定电商优化策略的基础、是店铺正确发展的指明灯，对我们的整体增长至关重要。

1. 总销售额（总收入）

总销售额以金额的形式呈现，是衡量我们线上店铺经营状况最佳的“整体主要指标”（OMM）之一，可以用它来衡量业务的整体增长和发展趋势。

该指标几乎反映了所有电商运营环节的效果——像市场营销、流量积累、商品优化、产品迭代等。只要我们的销售额实现逐月增加，就基本可以确定我们的策略是正确的。

需要注意的是，跟踪总销售额的过程中存在潜在陷阱，我们要确保销售额可持续地长期增加才是最重要的。

如果只关注短期效果，可能会错误地认为策略正确，反而不利于整体业务。但通常情况下，当我们将总销售额（总收入）作为核心指标时，基本不会出错。

转化率表示进行购买的访问者所占总访问者的百分比，是以特定时期内实现交易的总人数除以访问的总人数得出的。一次访问行为就是顾客与我们的店铺进行的一次独立互动，无论时长是三秒钟还是三小时。

对于电商而言，转化率优化事关重要，通常需要花费大量的时间和精力。

电商行业的平均转化率为 2％，业绩最好的店铺通常会达到平均水平的两到三倍。亚马逊的转化率高达 13％。这就意味着每 100 人访问店铺，就会有 13 人产生购买行为。

需要注意的是，很多电商会紧紧围绕转化率形成狭隘的指标视域。如果仅关注转化率，几乎牺牲所有其他指标，这将是一个灾难性的错误，肯定会在销售方面遭受损失。

3. 平均订单价值（AOV）

平均订单价值是指顾客进行一次购买（一个或多个商品）的平均值。

提高平均订单价值就会增加销售额，这是毋庸置疑的。平均订单价值（AOV ）还通常是代表收入增长速度最直接的指标之一，甚至比转化率优化更重要，我们在产品页面、购物车页面和结帐后页面中添加少量的相关内容就可能会产生重大影响。

购买频率一般是指顾客在给定时间段（通常是一年）内进行的购买次数，通过将过去 365 天的订单总数除以同期的顾客人数得出。

提高购买频率并不容易，涉及了站外的维护，像在顾客购买商品后通过电子邮件、再营销和社交媒体等营销渠道与顾客建立关系。

5.留存期（以及留存率和流失率）

留存期是指顾客保持活跃状态的平均时间长度。一般顾客超过 6 到 12 个月没有再次来到店铺购物，通常被视为不活跃顾客。

留存期或“顾客寿命”可能很难计算。但从本质上讲，是对顾客第一次购买行为到最后一次购买之间时间的度量，需要历史数据才能计算出该数字。一般来说，一到三年是一个很好的估计范围。

留存率和流失率也是有效的指标，两者均与留存期密切相关。

顾客留存率用于衡量在给定期间内平均留存的顾客数量，可以用它来衡量短期内实现顾客留存时间增长的效率。如果要提高顾客留存率或降低顾客流失率，则留存期就会增加。

我们计算一段时间内（通常是十二个月）的顾客留存率，可以用以下公式：

6. 顾客生命周期价值（CLV）

顾客生命周期价值是通过将平均订单价值、购买频率和留存期三个指标相乘得出的。

举个例子：假设店铺的平均购物金额为 100 美元，顾客每年平均进行 5 次购买，留存期为两年，那么您的顾客生命周期价值计算方法就是：$ 100 x 5 x 2 = $ 1000。

当我们优化上述三个指标时，顾客生命周期价值就会增加。

如上文所述，流量和转化率是另外两个至关重要的指标，是完整优化策略形成的基础。提升顾客生命周期价值时，实际上就是在提升已经拥有顾客的价值；而优化转化率，就能增加顾客人数；吸引更多流量时，实际上也就有了更多的人可以作为转化基数。

购物车放弃率是指在将商品添加到购物车后离开，未购买的访问者所占的百分比。

购物车放弃率是一个广泛的指标，由一系列微观转化决定。具体来说，这些微观转化包括：单击“继续进行结帐”按钮、从购物车页面转到结帐页、在结帐期间成功完成付款。

结帐放弃率是指开始结帐流程，但未完成购买而离开的访客所占的百分比。结帐放弃率的行业平均值为 25％。

如果顾客已进入结帐阶段，则他们很可能要购买商品。因此，较高的结帐放弃率通常表明存在可优化的空间，而不是缺少增加购买欲望的要素。关注顾客体验是确保最终完成转化的最佳方法。

9. 广告投资回报率（ROAS）

广告投资回报率是指广告回报占初始投资的百分比。提升这一指标有两种角度切入：减少广告支出或增加广告收入。

10. 单次转化费用（CPA）

单次转化费用是指获得一位新顾客所需花费的成本。这可能是一个相对棘手的指标，因为它要求我们在所有的营销活动（包括搜索引擎优化）中监控数据。

计算单次转化费用的方法，是用给定时期内的总营销支出除以新订单的总数量。例如，如果一家公司在 30 天的时间里在营销方面花费 1000 美元，并产生了 100 个新顾客，那么 CPA 为 10 美元。

如果要使我们的营销活动能够获利，无论是常规还是特殊的营销行为，我们的 CPA 都必须低于顾客生命周期价值（CLV）。

三，浅谈以「电商搜索效果评估」为例

对搜索的数据分析可以由浅到深有以下几个层次：

• 第一步，监控有多少用户使用搜索功能、通过搜索能看到返回结果并进入到商品详情页，进行加购或购买；
• 第二步，评估搜索路径的转化率及具体转化步骤流失情况，发现痛点进行优化；
• 第三步，评估不同搜索词的引流、加购、购买效果；
• 第四步，评估不同搜索方式等带来的搜索效果，如很多电商逐步支持图片搜索，可以用 Instagram 的明星穿搭图片直接搜索；
• 第五步，总结高搜索转化的商品特征，并指导选品。

以上这些搜索分析场景，通过 采集数据，可视化的呈现方式见下图：

最后，大家如果有兴趣，可以看看我们 。

总结了来自每日优鲜、喜茶以及汉光百货等 100+ 电商企业增长经验。凭借 11 套预置模板、埋点方案自动生成等手段，实现数据体系搭建时间缩短 60% 以上。落地千人千面的精细化运营，帮助电商企业精准定位客户、降低获客成本以及提升客户转化。

做实施项目，SD模块的静态主数据主要是客户主数据和价格主数据，这篇主要记录项目过程中关于客户主数据遇到的一些问题和看法。

在HANA系统里，客户主数据和供应商主数据的创建、修改、查看都是用的T CODE BP。所有的业务伙伴数据都会在后台表BUT000中创建唯一一条记录。也就是说，如果是外部给号的话，必需理清楚是否存在一个业务伙伴既是客户也是供应商的情况。

如果既是客户，又是供应商，是要分开用不同的代码呢还是用同一个代码？通常，对于业务部门来说，采购部和销售部的用户是希望供应商编码和客户编码分开来，但是财务部出于核对账务等角度考虑，会希望同一个外部会计主体在SAP里用同一个代码。这个时候，资深的顾问可以从过往的经验给出建议，当然了，主要还是看用户最终采用哪一种方案。

客户和供应商采用不同代码

如果是分开用不同的代码，即，同一个外部会计主体，比如客户A，既是客户，也是供应商，那么当A作为客户和作为供应商的时候，其代码在SAP里是不一样的。由于是外部给号，需要采购部和销售部定好各自的编码规则，号码段需要在10位以内(SAP标准)，编码范围不可重叠。这种时候，客户和供应商的BP分组就可以分开来。(HANA的BP分组可以理解为ECC的account group. )通常来说，不建议弄太多个BP分组，客户最好两个分组即可，一个内部给号，一个外部给号。不同的BP分组赋予不同的视图，HANA的标准客户分组需要的视图有：000000业务伙伴常规视图、FLCU01客户视图、FLCU00财务视图。

除此之外，对于关联公司(同集团下的其他分子公司)，通常既存在采购关系也存在销售关系，对于这种关联客户，最好是采用外部给号，并且用单独的一个BP分组，SAP HANA中针对这种关联公司客户有标准的BP分组-K400 关联方客商，建议直接用标准的即可。

客户和供应商采用同一代码

对于同一个外部会计主体，即是供应商又是客户的时候，如果采用同一个代码，那么建议客户和供应商公用一个BP分组，该BP分组可以参考上文提到K400复制创建。如果不用同一个BP分组，而是专门建一个Z001的BP分组给客户，一个Z002的BP分组给供应商，而一个业务伙伴只能有一个BP分组，这样就会对用户造成困惑。而且，对于后期给客户扩充供应商视图，给供应商扩充客户视图都比较麻烦。采用同一个BP分组，该BP分组同时存在客户和供应商所需要的视图，对于后期扩充等都比较方便。如果用户需要知道这个业务伙伴是客户还是供应商，可以在主数据中另外找一个字段来存储该信息。

为客户定义科目组和字段选择

路径：实施指南>后勤 - 常规>业务伙伴>客户>控制>为客户定义科目组和字段选择

定义客户主数据的编号范围

路径: 实施指南>后勤 - 常规>商业伙伴>客户>控制>定义和分配客户编号范围>定义客户主数据的编号范围

定义分组和分配编号范围

路径：实施指南>跨组建应用>SAP业务伙伴>基本设置>编号范围和分组>定义分组和分配编号范围

指令客户到业务合作伙伴的BP角色 (即给BP分配视图)

路径：实施指南>跨组建应用>主数据同步>客户/供应商集成>业务伙伴设置>客户集成的设置>定义指令客户到业务合作伙伴的BP角色

定义方向业务伙伴到客户的编号分配(即给BP分组分配账户组)

路径：实施指南>跨组建应用>主数据同步>客户/供应商集成>业务伙伴设置>客户集成的设置>集成的字段分配>定义方向业务伙伴到客户的编号分配

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴功能

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>账户组-功能分配

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴确定过程

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴确定过程分配

客户主数据涉及的开发主要有：批导程序、接口、报表

如果客户主数据是从外部系统传入的，则会涉及到接口，建议接口字段和批导字段以及报表字段保持一致，便于用户理解，也比较容易开发。

在与外围系统谈接口字段的时候，还需要注意的以下事项：

对于外部系统传入的客户主数据，一般需要区分3个动作：创建、修改、删除。因此在与外围系统谈接口字段的时候，需要指定一个字段用于区分是创建、修改还是删除？当然，SAP的客户主数据一般不做物理删除，而是打上冻结标记。

对于修改动作，需与外围系统确认是否有哪些SAP不可修改/不可随意修改但是在外围系统存在修改可能的字段，比如BP分组。我这个项目就遇到这个情况，业务把客户分成2类，因此我们也根据这2类客户建了2个BP分组，但是后来与外围系统沟通过程中发现，用户在外围系统可以修改客户的类别，但是SAP HANA的客户类别无法轻易修改。因此，后来我们把客户的这2个BP分组改成只留一个，另外用字段BPKIND来区分客户类别(常规视图-控制-业务伙伴类型，如下图所示)。

需要注意外围系统的客户号码是否是10位以内。SAP系统的业务伙伴代码最多10位，如果超过10位，则有两种解决方案。

方案一：最好让用户修改外围系统原有的客户代码规则以适应新的SAP系统，并给旧的超过10位的客户重新编码——虽然前期整理数据的时候麻烦，不过后期就轻松了。这种解决方案，从长远来看是值得的，能使整个集团的数据尽量统一，有利于统一规划。推荐方案一。

方案二：如果用户不同意修改原有的客户号码规则，那么，可以将外围系统的客户编号存储在字段BUT000-BPEXT中(常规视图-标识-外部业务伙伴编号，如下图所示), 然后SAP产生一个10位数以内的内部编号。但是，这么一来，如果外围系统修改客户数据，SAP需要先通过外部业务伙伴编号找到对应的SAP客户号码，然后再进行修改。如果业务下单也是在外围系统下单，销售订单传入SAP的时候，也需要对合作伙伴进行转换。方案二是下下之选。

外围系统对一个客户是否维护多个银行账号。如果外围系统会给一个客户维护多个银行账号，假设最多3个，则相应的，接口字段也要多几个。

就接口字段长度/格式/是否必填/默认值等跟外围系统达成一致。长度，比如地址长度、客户号码长度等；格式，比如日期的格式，最好采用这种纯数字格式，尽量避免如或者这种非纯数字的格式；必填项检查，也叫做完整性校验，某些字段值对SAP来说是必填的，则要求外围系统必需传值，比如国家地区等，如果外围系统针对该字段是可填可不填，则最好要求外围系统改造，使用户在外围系统必需维护该字段，亦或者双方约定一个虚拟的默认值，比如说街道字段，如果用户在外围系统没有维护地址信息，则外围系统传入默认值999999给SAP等等；默认值，有些字段，SAP需要，但是外围系统也许没有维护该字段对应的信息，则最好让外围系统根据一定规则传输默认值，最好不要在SAP的接口里直接指定默认值，这样有利于后期业务拓展，比如，统驭科目字段，SAP客户主数据需要填写该字段，但一般来说，外围系统是没有该字段信息的，那么我们可以告诉外围系统根据特定规则传输某默认值。

与外围系统约定处理逻辑，是同步还是异步？同步，可以理解为外围系统发送信息给SAP后，需要等待接收SAP处理后返回的成功或者失败信息。如果SAP返回E(失败)，则需要外围系统处理或者重新发送；异步，则外围系统将信息发送给SAP即可，不需要等待SAP返回的信息。

在FS功能说明书编写这部分，我提供了接口字段模板作为例子。

以下为日志表ZTSD001_CMD所含字段，日志表中包含所有接口业务字段，另标黄的为接口外新增的字段。

对于这种主数据接收程序，程序处理逻辑可参考如下：

步骤1：对接口字段进行完整性校验。如果校验失败则返回错误信息给外围系统。不将信息保存到日志表。

步骤2：对接口字段进行字段逻辑性校验，主要针对长度，值/值域，格式进行校验。如果校验失败则返回错误信息给外围系统系统。不保存信息到日志表。

步骤3：校验成功则将字段信息记录到日志表ZTSD001_CMD，并进行到下一步。

步骤4：对日志表内部分字段根据一定逻辑赋值。

步骤5：根据日志表来创建\修改\冻结对应的客户主数据。

步骤6：如果创建\修改\冻结成功，则返回创建成功的客户号码。如果创建失败，则返回错误信息。

当然，除了接口处理逻辑，通常针对接口，还会有重处理程序，重处理程序需要读取日志表种消息类型为E (Eerror)的数据重新进行处理。如果需要重处理，则需要告知开发，逻辑与接口程序大体一致，需要能够后台处理。

以下是对各个步骤进行详细解析：

1) 将接口字段进行完整性校验。

外围系统推送了客户信息到SAP之后，SAP会进行字段完整性校验：表1第五列标记出了所有接口字段中要进行完整性检查的字段。检查完所有“必填”字段，只要“必填”字段中有一个的值未由外围系统在接口中提供，则针对此次推送返回“E”的错误消息(INFO=E, MESSAGE=Error)、针对错误字段返回Error: incomplete data。然后退出接口。只有表1中所有“必填”字段都有值，才能进入下一步的逻辑性校验。

2) 逻辑完整性校验:

通过完整性校验后，继续进行字段逻辑性校验。表1中第6第7列标出了要进行逻辑性校验接口字段及其校验内容。只要有一个字段逻辑性校验失败，针对此次推送返回“E”的错误消息、针对错误字段返回相应的错误消息，然后退出接口。只有逻辑性校验成功才进行到下一步。相应的错误信息列示如下：

a. 长度：所有字段传输值不能超过设定长度(下称“超长”，但“超长截转”的字段只截转不报错)，若因此项校验失败，则针对此字段返回 “错误：字符长度”，针对此字段返回错误消息(INFO=E, MESSAGE=Error);

b. 值/值域：部分字段只能传输值域内的值(下称“表值”)，部分字段只能传输具体几个值中的一个(下称“定值”)，如因此项校验失败，则针对此字段返回“错误：值域” ，针对此字段返回错误消息(INFO=E, MESSAGE=Error);

c. 检查：基于一定前提下进行完整性检查或唯一性检查，如因此项校验失败，则针对此字段返回“错误：检查” ，针对此字段返回错误消息(INFO=E, MESSAGE=Error);

若长度与值/值域这2种校验在同一字段上失败，则将错误消息内容拼起来(用”/”隔开)统一反馈，如”错误：长度/值域” ，针对此字段返回错误消息(INFO=E, MESSAGE=Error)。

3) 步骤1和步骤2都成功验证，则将字段信息存储在日志表ZTSD001_CMD中。

4) 创建函数ZSDIF001(客户主数据接口)，用于处理该接口相关业务，同时用于重处理调用；

5) 对检查通过并落地后的数据进行操作(也适用重处理机制)。

6) SAP需对日志表内部分字段根据一定逻辑赋值，具体赋值规则请查看表1最后一列中的红色部分。

7) 根据日志表来创建\修改\冻结对应的客户主数据。

如果XBLCK=1，则创建客户主数据；如果XBLCK=2，则修改客户主数据；如果XBLCK=3，则冻结客户主数据。

A. 创建客户主数据：

如果BU_GROUP=Z005，则创建客户主数据时，客户代码采用系统内部给号，不使用外围系统提供的客户号码。BU_GROUP=Z001，则使用外围系统传过来的客户号。

如果创建成功，则在日志表传输状态字段赋值“S”，消息字段清空内容后增加后续信息：“客户”+客户代码+“创建成功”。

如果创建失败，则在日志表传输状态字段赋值“E”，消息字段清空内容后增加后续：“客户创建失败”+系统错误消息代码。进行一次重处理。

创建成功或者失败的消息随后返回外围系统。

B. 修改客户主数据：

如果BP分组是其他，则客户号码直接取接口传入的KUNNR.

如果客户之前冻结过，则需解除冻结，即KNA1- AUFSD=“”。

如果修改成功，则在日志表传输状态字段赋值“S”，消息字段清空内容后增加后续信息：“客户”+客户代码+“修改成功”。

如果修改失败，则在日志表传输状态字段赋值“E”，消息字段清空内容后增加后续：“客户修改失败”+系统错误消息代码。进行一次重处理。

修改成功或者失败的消息随后返回外围系统。

C. 冻结客户主数据：

冻结成功或者失败的消息随后返回外围系统。

输出的数据主要是外围系统客户号和对应产生的SAP系统产生的客户号码。同时SAP系统会将产生的结果通过接口反馈给外围系统。具体反馈的字段如下：

后续关于客户主数据发送接口、批导程序等的笔记留待下一篇讲解。