来自 科技 2020-01-14 14:52 的文章

考拉POP生态建设之路:如何做“开放”

从考拉POP的缘起到运作逻辑,今天,笔者介绍了考拉POP平台的核心原则。围绕这个原则,团队进行了不少尝试,也留下了一些遗憾。

前面两篇分别介绍,以及,POP的核心是开放和平台化,本篇以“开放”为契机谈谈考拉生态建设的一些收获。

需要说明的是,这里仅是个人实践的点滴,里面的内容与阿里开放生态、“商业+开放平台+云计算商业平台”的高度不可同日而语。

在“开放、连接、赋能……”这些与平台生态建设相关的概念里,“开放”是生态建设首要考虑的问题。

我参与过的B端产品设计里,有关“开放”的产品设计是里最具挑战性的产品域之一。

如果说C端很多域的产品设计需要“艺术”sense,那么开放这个B端域的产品设计需要的是“哲学”修养。它的哲学性体现在“目标与手段、过程与结果、矛盾与统一”等诸多关系的理解和处理。

让我们从灵魂三问开始,聊聊“开放是什么?如何开放?为什么开放?”

开放既是目的也是手段,平台通过向合作伙伴开放平台的服务和能力,可以让合作伙伴更好完善平台开放的开放能力。当平台采用开放的态度时,在一定程度上就实现了开放。

开放既是过程也是结果。真正的开放是一个不断深化,持续完善的过程。

以上有关“开放是什么”的解释里,也包含了“如何开放、为什么开放”的思路。如何开放的首要条件之一是保持开放的态度,构建平台生态是为什么要开放的核心奥义。

在介绍具体的产品体系之前,花篇幅来解释“开放”的种种关系,一方面是因为这些关系本来就是产品体系的基石,另一方面是因为这些关系影响着我们团队产品设计原则的形成。

“开放”之于POP,就像“克制”之于微信,属于我们产品的核心设计原则。

以下从产品角度介绍我们团队对开放策略的思考。

一、开放产品体系

行业里有些团队“认为开放平台就等于开放”,从产品的角度看,这种说法稍有欠妥,这会让开放平台的产品边界有些模糊。

我们团队定义的开放产品体系,包含一套开放能力(Open API),一个开放平台和一系列SAAS产品。

Open API是开放平台能力的基础,开放平台是SAAS的平台基石。这个产品框架与阿里开放生态、“商业+开放平台+云计算商业平台”的范围不可同日而语。

1. 开放能力(Open API)

POP的API体系经历了两个版本,实现了一些基础能力的开放,包含商品、交易、订单、会员、商家、物流等100+接口(详见:接口中心),比较友好地支持了商家“商品管理”、“订单履约”、“物流发物”、“财务结算”等四个大的业务场景,高频核心业务场景的覆盖度在75%左右。

POP业务完整的业务场景以及API覆盖的核心场景见下图。

一个完整的API体系是一张庞大的网络,要完善这个网络,负责API定义的人既要吃透产品业务场景,又要了解技术实现细节,需要产品和技术的双重能力。而且API的提供方散落在各个业务域,有效推动各业务域来完善丰富API,需要极高的协调能力,哪怕有战略优先级支持。

POP的API体系设计之初没有产品经理负责,全赖技术支持来负责API设计,后面逐渐将各业务域的API定义交给对应的产品经理来负责。

这个产品过程走得比较漫长和艰辛,其结果是API的完善度一直不太理想,其中也不乏一定API的定义本身不太合理的原因,甚至出现个别API返回、报错内容可读性差的情况。

回顾这个过程,有以下几点经验:

  • API的定义尽量用行业统一的标准,包括接口名称、接口字段、常用的接口动词都等;
  • API的字段提供要尽力最大化满足合作伙伴不同业务需场景需求,实现业务闭环;
  • API接口设计保持单一性,维护合适的粒度,并保证好的扩展性;
  • API定义要保持稳定性,力争不要变化;
  • API的可读性要好,最好提供示例;
  • 建立一套各方认可的API完善机制;
  • 做好打持久战的准备。
2. 开放平台(Open Platform)

开放平台算是软件行业最古老的产物之一,属于标准得不能再标准的产品。

这个产品设计的难搞的地方正好也在于它的“标准化”,我们团队产品经理一半对它“发怵”,另一半对它“嫌弃”。产品经理“发怵”的核心原因是因为这是一个偏技术的“产品”,而“嫌弃”是因为做它没有太多“成长性”。

产品经理对开放平台不感冒,技术人员却对它趋之若鹜。

技术同学做开放平台的直接原因有两个:一是因为开放平台实现的技术挑战性较高;二是大量的合作伙伴对接联调以及API的管理,需要无休止的投入时间,他们亟待开放平台赋能(从这点看,技术比产品经理有远见得多,难怪很多公司要消灭产品经理)。

其实,开放平台还有另一层更重要价值:开放平台是生态赋能的基石,基于开放平台开发者可以为商家开发出更多有价值的工具和服务,赋能平台。

POP开放平台是由技术同学自发构建的业务型开放平台,经历过两次大的版本迭代,实现了基础的API网关、开发者中心、授权中心、控制后台等模块,下面附上开放平台系统架构图与核心关系图便于大家理解。

POP开放平台系统架构:

POP开放平台系统关系:

基于这套OPEN API和开放平台能力,我们在一年时间内完成了95%主流电商ERP系统对接(包括网店管家、E店宝等,详见开放平台ERP名单),支撑了80%以上的POP商品发布和订单处理。ERP服务商的整体对接周期平均从45天缩短至三周以内,服务商对接满意度获得了极大提升(综合满意度从65%提升至90%),对应的开发联调时间也减少了70%以上。

POP开放平台仅仅是支持了POP商家这个角色的生意模型,自营供应商、物流服务商、仓储服务商、清关服务商等、分销商等角色的业务场景分别散落在不同的开放平台里,多个平台没有有效整合,这也是我们团队最大的缺憾之一。

总体上看,POP开放平台支撑业务范围非常有限,成长的空间很大,这里放一张比较古老的淘宝开放的业务结构图做个对照。

团队做开放平台的点滴收获如下:

  • 对于POP来说,开放平台越早做越好,而且要做持续的投入;
  • 公司对外的开放平台最好是做一个统一平台,避免内外部的资源浪费;
  • 开放平台是一个技术、商业、体验三重挑战的产品,值得产品经理投入。
3. 生态赋能尝试(SAAS)

SAAS是软件行业的一种典型的盈利模式,国外电商行业shopify是亚马逊的劲敌,国内的有赞、微店等公司更是以SAAS为收入支柱,淘系SAAS的营收早超过100亿规模。

我们团队的SAAS尝试是从平台赋能角度来切入的,没有做商业化的实践,陆续上线的几个服务也是以免费的形式来向商家提供,个别服务甚至是倒贴钱。

有赞业务结构图,资料来自有赞2019财报:

有赞收入结构图,资料来自有赞2019财报:

之所以把SAAS放在开放产品体系里,是因为SAAS是POP这个业务皇冠上的明珠。我们团队虽然没有太多产品实践,但仍然对这个模式做了许多讨论。

下面对我们提供的几个SAAS服务的构想做个简单介绍。

SAAS服务之一:电子发票服务

电子发票服务,是了为解决商家开票时效慢的痛点而提供的一站式解决方案。

平台引入电子发票服务商,基于商家授权,平台向发票服务商开放相关开票的数据,服务商完成电子发票开票并回传开票信息。

在服务提供前,POP商家的发票客诉和工单长期居高不下;服务上线后,约有90%的电子发票是通过这个服务来完成,相关客诉下降了60%以上。

该服务的业务逻辑图见下:

SAAS服务之二:商品一键搬家

商品一键搬家,是为了解决商家跨平台商品发布难的痛点而上线的服务。

平台引入ISV,ISV提供跨平台抓取商品的能力,商家开通服务后,可以授权ISV抓取指定平台店铺下的商品,并通过类目映射的方式发布到POP的商品库。

这个服务的难点有两个:一是保证商品素材抓取的稳定性,二是确保类目映射的准确性。

商品一键搬家服务在非标类目商家的使用比非常高,在很大程度上缓解了商家商品发布的压力。

有关服务市场的一些不成型的思路:

服务市场是我们团队长期思考的一条产品线,团队的产品参考淘宝服务市场完成MRD和产品框架设计。但受限于业务规模的制约,因此这个产品项目一直未能开始。

POP服务市场产品框架:

项目虽然未能开始,但仍有几条收获可以分享:

  • 业务量是服务市场的根基,淘宝服务市场的成型就来源于“流量”业务规模化的带动;
  • 活跃商数达到2000+,能支撑ISV 10W/月的收入体量时,可以考虑服务市场;
  • 服务市场可以从内到外冷启动,先由平台提供一些核心服务再引入ISV提供其它服务;
  • 可以裹挟TOP商家一起来跟ISV谈判,TOP商家往往是ISV在其它平台的重点客户;
  • 商品管理、订单管理、店铺装修、促销管理、优惠券管理相关的应用是SAAS的重中之重。

SAAS是一个很成熟的行业,各大佬有许多高屋建瓴的探讨,有兴趣的同学可以进一步查找。

“开放”是POP平台的灵魂之石,团队倾全力投入也不为过,这个道理我还是明白得太晚了。

二、开放与不开放

开放与不开放是一对矛盾统一体,对“不开放”的定义越清楚,越有益于更好“开放”。

平台不开放的红线之一是:隐私信息,包含用户隐私、商户隐私等。

要在保护用户隐私的同时又满足合作伙伴需求,个人的建议是:

  • 对信息获取严格的权限控制;
  • 对能获取用户隐私数据以及行为做好溯源跟踪;
  • 对隐私数据获取和使用,做好平台层面定义甚至是法律层面的规范 。

为数据建起一道防护墙,是平台的责任,也是合作伙伴的责任,需要大家一起自律和完善。

其它一些开放与不开放的策略讨论还有:

  • 品类选择性开放,尤其POP以非标为主;
  • 品牌选择性开放,仅选择契合平台调性的品牌;
  • 用户触达的渠道选择性开放,以不打扰用户为原则;
  • 商家经营信息选择性开放,同行数据指数化处理;
  • 流量策略性开放,维持良性生态。

为解决数据安全、稳定性的问题,阿里采用的是“聚石塔”——电商云工作台的方案,比较完美解决了开放与不开放的问题。

最后放一张阿里聚石塔产品架构图来镇楼,向这个行业的引领者们致敬!

注:资料来自《尽在双11,阿里巴巴技术演进与超越》,电子工业出版社,2017年第1版。

本文由 @赢乾 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议