随着互联网新零售模式的发展，营销已不是单一个体运营的时代。互联网的发展促使各个群体相互联合，使自身在互联网这个生态链上站稳脚跟。互相联合自然少不了平台的连接，今天和大家分享一下开放平台的构建思路。有些文章讲的过于产品，要么就是太偏向技术，今天我将产品与技术结合的方式来深入的梳理一下思路。

各大电商以及一些互联网应用公司，都建立了自己的平台，让更多的外部商户享受到平台带来的利益。如淘宝、支付宝、京东、开放了几百个不同的接口，外围商户可以根据需要创建不同的应用，为客户提供个性化的服务。

建设开放平台的意义在于，外部商户可以快速接入，投入很小的人工成本便可完成第三方接入能力。促使业务或应用快速上线。另外还可以提供一些基础服务，如果查询订单，交易、客户服务、对账、方便快捷的提供业务支持。并且可以很方便的管理第三方应用。

今天以某餐饮品牌为例，来梳理一下思路。某知名餐饮品牌为了推广自己的饮品，向其它渠道输出自己的的代金券。企业要生产自己的代金券，然响有需求的渠道分销，用户兑换这个券之后，便可拿到门店使用。假定该品牌也有自己的会员体系，不同等级的会员会享受不同的礼遇。

一、产品和开放对象

首先确定我们有哪些内容？

哪些内容是开放给外部商户的，这里我们把能开放给第三方的代金券、订单信息、会员信息、评论信息等统称为内容。

以某品牌为例：我们现在有自己生产折扣券和代金券，同时还有会员体系、会员产品，这里所说的会员产品比如月会员、年会员等。这些产品是可开放给外部商户进行商业行为的。

大概如下情况：

其次，考虑我们的平台为谁开放，谁可以接入到我们的平台？

这也是我们最原始的搭建开放平台的出发点。现在开放内容已经定了，哪些用户会跟我们的内容有关呢？分销商销售我们的券码、和充值会员产品、当然也可以销售会员兑换码。所以又要支持核销券码和充值会员。这里将会涉及到分销商、核销商。如果你与其它品牌进行联合会员，还会涉及到第三方会员的供货商，这里就不再提及了，思路都是一样。

这两种角色商户在我们平台涉及的交互主要有：

• 分销商：从我们平台上获取券码、充值券码、充值会员、查看订单、查看费用等。
• 核销商：客户拿到一个会员兑换码后使用的途径。当然我们自己的应用或网站也可以使用。为核销商开放核销途径有个好处一是业务灵活应用，二是核销可以保存使用记录方便处理客户投诉。在这里强调一下，分销商与核销可能是一个主体或不同主体，如分销商既卖券码，又核销券码。

二、平台开放能力

现在已经确定我们有哪些产品，并且也确定了开放的对象。现在需要确定我们平台可以开放哪些能力。针对不同的业务开放的能力也是不同的，以上述业务场景为例：我们为分分销商提供充值、获取、查询、作废权益，同时提供券码消兑。

如果涉及到用户隐私信息或者需要支持其它app使用当前会员账号登录的情况，更安全的做法提供获取Token的服务。

外部商户如何才能获取到这些服务能力呢？我们需要支持商户自主创建应用，通过应用创建的方式提供货以这些接口服务。

三、平台服务能力

外部商入驻我们的开放平台，平台上将为外部商户提供一些基本的支撑能力。支付宝开放平台为了安全还专门为外部商户分角色创建子账号，用以管理不同的业务。这根据公司需要和能力提供更安全可靠的能力，根据业务范围，可为外围商户提供提交资质、应用管理、财务管理、申请和查看商品、查看交易流水、订单查询功能。

四、平台内部支撑能力

我们的开放平台当然不只是给外部人使用的，还有本公司的人员。所以还要确定内部人都什么角色使用这个平台。现在列出几种基本上都会有的，销售、运营、技术、法务、会计。

• 销售、法务：负责管理商户，审核合同等。
• 运营：管理日常业务，负责整体日常运营事务。
• 技术：开放平台涉及到技术部分的维护、完善文档。
• 会计：商户付款等费用管理。

这里简单的列了几个模块，依据业务不同所涉及到的功能模块也各不相同，而且可能会涉及到更多的角色。

五、平台业务流程

六、商户入住

首先商户需求入住我们平台，也就是注册、登录、提交相关资质。此时商户入住时，提交相关资质，那么在我们的平台内部，必然涉及到商户的审核，此场景基本上都会涉及到运营、销售。

运营主要是审核商户资质正确性、审核后，如果后续需要销售跟进。所以还还需要指定一位销售人员跟进业务进展情况或商务层面的沟通，信息化比较完善的企业，建议平台与CRM系统进行结合。每个公司的情况有所不同，根据实际情况制定相应的业务流程。这里面主要是强调开放平台与内部业务衔接的思考方式。

七、创建应用

为什么说是创建应用呢？而不是直接找到相关接口文档直接对接。

创建应用的好处在于：

• 第一、以应用方式提供，在商户创建应用前，我们的平台已经为商户开放出各种应用类别，应用类别在后台已经绑定好了必要的api接口。一个应用创建后要实现哪些开放的api接口，也就一目了然了，这非常适用于有几十个或几百个接口的平台。也就是在我们平台内部应用管理模块来管理，一般由产品经量和技术经理来负责。
• 第二、在平台内部，接口与应用类别绑定后，也便于追溯应用都对接了哪些api接口。基于能力开放的要求，进一步简化服务复杂性，面向SOA的设计，采用微服务架构，松耦合的方式。在保障安全稳定的前提下，快速灵活开发应用。
• 第三，商户在创建应用后，也可以在开放平台方便管理自己的应用。当存在多个应用时，也容易分辨出业务订单来源于哪个应用，便于归类结算。

创建应用离不开应用类别、应用、 api接口这三个关键资源。下面详细说明一下三者之间的关系，这也是本文的重点部分。

应用、接口、应用类别三者关系：

1. 一个api接口可以属于0个或多个应用类别。比如一个作废的api，并不一定默认就开放给商户使用，由于涉及到结算，可能需要协议的支持才会开放，当需要开放时直接给相应的应用进行开放即可。而对于一个查询订单状态的api来说，默认可能属于多个应用类别，它属于公用api。
2. 一个应用类别可以包含0个或多个api接口，这种情况下当按照此类别创建应用后，需要人工添加与之关联的接口。比如很多情况下，不是所有商户都会按照你的开放平台标准进行对接，此时需我们就需要按一个不包含任何接口的类别创建一个应用，然后将按对方标准定制化开发后的api接口与应用直接绑定。
3. 一个应用只少且只能属于1个应用类别，为什么这么说呢，一个应用类别，就相当于一个抽象的应用，一个模子，而创建应用正好像实例化的过程，按照模子造东西的过程。
4. 一个应用类别可以包含0个或多个应用。当没有按照这个类型创建应用时，自然就不包含应用了，同理按这个应用类型也可以创建很多应用。
5. 一个api接口也可以属于0个或多个应用。如上述第1点，一个特殊的api需要手工开放给某个应用使用。
6. 一个应用也可以包含0个或多个api接口。如上述第2点，按照一个不包含任何api的类别创建应用时，这个应用也不会包含任何api。一些公用的api可以同时让多个应用来使用。

以上就是三者逻辑上的关系。在开放平台内部使用原型图呈现出来如下，仅供参考，模式是固定，思维是灵活的。

（1）api接口管理

将已部署到开放平台网关的api接口添加到开放平台。

（2）应用类别管理

创建应用类别，关联到api接口。

（3）应用管理

在平台内部，创建应用

创建应用，生成应用信息，主要是 appID、appKey、appSecret。创建应用时，需要指定应用类别、所属商户。我们自己创建应用的原因是，不是所有的商户都会主动的按照我们开放平台的标准api接入。但是我们依然可以按照开放平台的模式管理自己的应用，手动关联已定制开发好的api。

编辑应用。

白名单：用来控制商户哪些地址可以访问我们的业务平台。

授权回调地址：一般用来单点登录，授权后通知到商户。

应用网关：商户回调接口API网关.

密钥：接口签名用到。

我们的api接口开发完后已部署到了开放平台网关，并且在平台上创建了应用类别，将接口与类别进行关联。商户在开放平台上注册完成后便可以按照类别创建应用了。

（4）在开放平台创建应用

那么，商户入驻开放平台后，商户按照某个类别创建应用，应用创建后便生成了一个appId,一个appKey，此时相关接口便与一个应用的实例进行了关联。商户便有了一个身份来访问这些接口，这里有必要提一下，一个appID,与appKey不一定是一对一的，根据业务的复杂度有可能是一对多的，用来申请不同权限的token。

有了身份之后我们还需要对身份进行鉴权，否则就相当于只有账号没有密码一样。所以在生就应用时，还需要生成 appSecret 。 appKey相当于账号，appSecret相当于密码，也就所说一个公钥和私钥。

有了这个关键数据，我们就可以通过已绑定的接口请求一个Token。这个token就相当于访问其它接口的一个临时令牌。短时间内有效的，当应用访问用衣隐私信息时，都必须带上Token。如果想深入了解token的获取和使用逻辑请查阅 OAuth2.0协议。

根据平台配置展示公开申请的应用：

商户应用创建完了，但是此时应该让应用停留在测试或待审核阶段，如果商户想访问正式资源，还需要正式上架应用或提交审核。在提交之前可以要求用户提供必要的信息，如果IP或域名白名单、授权回调地址。和其实一切你希望用户提供的信息。也可以在此展示该应用需要必要的信息，如 appkey、appSecret、默认API网关等。

此时商户的应用已经创建完成，商户侧可以根据指定的接口协议进行开发，所以我们还有必要在开放平台提供详细的文档说明。即前面提到的文档管理部分，内部技术人员对文档进行管理。

编辑完成后，开放到外部平台，供商户开发使用。我们还有必要提供一沙箱环境，让测试测试环境生产环境进行分离，视各公司情况而定。而在生成环境，也有必要提供一个灰度上线的方式，这样可以在保证全部测试通过的情况下再对外发布。

商户应用开发完成后需要提交审核，如果平台开发得智能化一下结，可以让商户在非正式环境，模拟一些业务数据，当商户提交审核时，自动去验证这些数据，是否合法、合规、验证通过的情况下自动审核通过。如果有特殊要求，也可以加入人工控制，实现半自动审核。

（5）财务管理

应用上架后，那么就可以进做正式业务了，在做正式业务之前，多数平台都需要商户预付一些款项，所以我们应该为商户提供一些线上付款功能，支付宝、微信、云闪付企业版均可以提供很好的支持。

如果没有提供线上的方式，商户在线下汇款后，平台应该支持提交付款信息和上传付款凭证的功能。以便财务人、运营可为商户认款到商户账户。根据需要还可为账户设置不同的账户，如现金账户、奖励账户等。涉及到款项时，平台还应该为商户提供一些预警机制，以免余额不足时影响业务。

（6）正式运营

商户付完款后，运营人员要为商户配置相关商品，如果你平台上的商品足够开放的话，也可由商户自己选择上线哪些商品。商品配置完后，商户便可以平台浏览到已开放的商品，以便上架到商户自己到平台。应用正式运营后，平台还应该为商户提供订单查询、交易数据查看分析等基本数据，方便商户进行对账，减少人工沟通成本。

小结

至此，已具备一个基本的开放平台的概念，核心思想主要是对开放接口、应用类别、应用的统一管理。以及业务为中心的涉及到运营、财务、等方面的功能支撑。实际正式的业务会比这复杂的多，重要的是在于构建思想。

欢迎各位互相交流学习！

本文由 @大王寻山 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议