如何设计并搭建开放平台?
随着ChatGPT和AI绘画的爆火,市面上关于AI的工具型产品越来越多。作者从产品经理角度,并结合自身经验,分享从0到1设计企业的开放平台过程中,需要考虑哪些环节,如何设计并搭建开放平台?希望对你有所启发。
本篇文章介绍了从产品经理的角度,以作者亲身经历,在从0到1设计企业的开放平台过程中,需要考虑哪些环节,搭建哪些基础功能,技术接口设计,以及如何落地并推进开放平台项目启动。
写在前面
随着ChatGPT和AI绘画的爆火,市面上越来越多的工具型产品继而出现。
那么为这类产品开发以及设计者提供底层能力的OpenAI到底是什么公司?
实际上OpenAI是一家全球最著名的人工智能研究机构,发布了许多著名的人工智能技术和成果,而这次爆火的ChatGPT便是OpenAI所研发的InstructGPT模型,这是一个AI对话系统,也是OpenAI对外开放平台收费的API能力之一。
一、企业为什么需要搭建开放平台
什么是开放平台?
在互联网时代,把网站的服务封装成一系列计算机易识别的数据接口开放出去,供第三方开发者使用,这种行为就叫做Open API。
而提供开放API的平台本身就被称为开放平台。(狭义角度,本文后续将阐述当前各个企业开放平台的定位区别)
企业为什么要搭建开放平台?
最早尝到开放平台甜头的公司是Facebook,扎克伯格所崇尚的开放思维、群体智慧和创新精神汇聚到一个平台。
Facebook搭建的开放平台,为网站源源不断地注入群体开发者的智慧,开放战略使得Facebook迅速脱颖而出,并且得以积聚人气,为下一步的拓展、布局做好准备。
开放平台的能力简而概之,就是将Facebook拥有的海量社交用户档案和关系数据,通过API开放给第三方开发者。
一般大厂做开放平台的目的:
- 平台本身核心服务能力输出(比如百度AI开放平台,文字识别、图像技术等一系列的技术能力,场景方案、部署方案)
- 平台延展服务能力引入,吸引各种服务商(ISV)在上面创建应用,为客户提供更丰富的解决方案(比如,拼多多的易掌柜、口碑的生态市场提供的各行业服务插件等等)。
- 形成平台的生态圈以及影响力,为下一步布局做好准备。
二、开放平台的分类以及服务形式
1. 开放平台分类
一类是输出自身海量的基础数据,例如极速数据的API接口。
另外一类则是输出自身业务能力,例如高德地图、微信、支付宝开放平台等。这种类型紧贴业务场景的开放平台建设,按照业务能力形成一道护城河,也极大丰富了开放平台这个大家庭的种类。本文也将重点阐述这种类型的开放平台建设。
2. 服务形式
纯API形式和H5形式:
如需引用请联系作者
如需引用请联系作者
两种服务形式的优势和劣势:
两种服务形式各有优劣势,当然目前市面上也有变种,即某些部分H5形式 某些接口api输出。具体哪种形式建设开放平台,要依赖自身业务模式、团队情况、业务发展阶段、系统稳定性等诸多因素综合考量。这也是开放平台建设者需要第一步考虑的事情。
以我建设的开放平台为例,最早在设计开放平台之初,需求方来自于技术以及商务,需要一个可以便捷管理接口,支持让异业接入方能快速接入并且投入使用。那么基于这些考虑,最早第一版本的开放平台是只支持H5模式的输出,一直迭代到2.0才支持API模式的输出。业务方通常不会给太多的时间给到产品设计者,只有在保证业务模式清晰的基础上,快速上线满足业务方需求,才能有下次迭代。
三、开放平台设计
1. 整体架构设计
如需引用请联系作者
这里架构设计按照市面主流开放平台的架构来绘制,包括门户中心、开发者接入板块、开放能力运营板块、运维中心、API网关。
门户中心:这里主要涉及到开放平台的访问入口,设计者需要考虑到有多少角色参与到开放平台里。一般正常最基础的角色是 平台运营者、开发者,平台提供api能力给开发者接入。再次基础上,较大规模的开放平台一般构建一个大生态体系,那么对于API接口服务能力的提供不仅仅需要依靠自有能力,更加重要的就是要依赖于开发商和合作伙伴的可共享能力接入。此时便有合作伙伴,也就是服务商的角色参与。
这里参考抖音的林客,本地服务商经营平台:
开发者接入板块:这个版块的主要使用角色是开发者,此时众多开发者就是直接用户。产品经理在设计这个版块的时候,需要考虑到各个类型的开发者。
用户体验里面最重要的一个原则就是把用户当“傻子”,开发者接入板块要做到尽可能简明扼要,你面对的可能是刚从培训班出来的小白,或者是接入过无数接口的大佬。
这里重点阐述一下接口文档板块,一直以来接口文档的维护相较于产品说明文档都会比较弱,强依赖于开发者的描述,需要注意的是产品经理可以适当介入接口文档的撰写,尽量做到文档清晰易懂,重点注意事项需要标明。
之前在做实际对接过程中,常有错误返回的追述发现只是开发者看漏了部分文档参数。
开放能力运营板块:这里的用户角色参与者较多,可能是平台实际管理员、财务、客服、商务等。由于参与方较多,对该板块的需求也会较为繁杂,产品经理需要梳理好必要的功能建设。
运维中心:运维中心承担了推动开放平台正常往前的齿轮角色,这里部分开放平台会缩减部分,例如白名单管理、数据库管理 这里在部分企业中,已经被其它系统所承担,复用这个版块即可,无需重新建设。
API网关:网关可以说是开放平台的核心,承担了整个开放平台的流量入口,同时还要有足够的系统容错能力。如上图所示,网关包含应用的校验、能力权限校验等功能。
市面上无论大厂还是中小厂的开放平台,或多或少都会在其中有部分体现。中小厂在考量到开发能力,业务模式等因素,可以按照最基础的板块建设,但是涉及到安全中心这种必要板块,产品经理在设计开放平台之初就需要和公司安全部门进行协商。防止开放平台被接口攻击。
作为产品经理的角色,不管是哪个阶段设计开放平台,需要清晰自己业务开放平台的最终形态是什么,反推目前必要板块的建设。反推之后,下一步才是进行功能设计以及技术方案敲定。
2. 功能设计
由于我当前项目涉及到api形式和H5形式,这里两块形式都会做一定的介绍,其中有部分重叠的设计思路就不予赘述。
在正式介绍功能设计之前,产品经理需要明确一点开放平台的服务对象是谁?
这里具体服务对象包括大型连锁企业、中小企业、小微商家、有分销能力商家、个人开发者、合作伙伴服务商。
根据不同的服务对象,主流开放平台一般区分为,标准接入型开放平台(例如微信、支付宝开放平台)以及解决方案接入型开放平台(例如高德开放平台提供的解决方案)。
两种开放平台的整体架构不会有太大差别,但是具体对接流程、收费模式、服务形式会有差别,在这个基础上延展出来运营设计也会有所不同。这里需要产品经理按照各自业务特性来进行设计。
根据使用角色,延展出来主流开放平台主要解决以下几个层面的需求:
- 开发者需求,开发者身份注册、应用申请与数据权限授权、开发者获取相关资料(接口文档、使用说明、对接人联系方式等)
- 平台管理需求,平台方内部管理,客户管理,申请审核流程、服务配置、财务对账管理、参数配置、角色分配等
- 业务需求,业务交易管理及统计看板、报表分析(涉及业务结算类型,例如预充值或者CPS返佣)
- 安全层面需求,数据加密、应用秘钥、应用接口权限控制、系统角色权限、访问黑白名单、字段脱敏等
如需引用请联系作者
3. 功能设计说明
(1)运营管理后台
开放平台运营管理后台主要是基于销售、商务、运营者、财务的多端需求建成的管理后台,其中功能需要能满足接入申请审核、接入方管理、账号管理、业务数据管理、文档管理、工单管理。如果财务板块有对账以及开票需求,还需要融合进财务管理系统中的自动对账中心以及自动开票中心。
(2)开发者门户(接入方后台)
开发者门户的入口一般来说是网站为主,由于目前开发者大部分通过搜索引擎来查询,网站的包装也比较重要。门户网站的主要功能职责就是帮助开发者用户了解开放平台的能力,帮助企业或者开发者做到什么,引导用户进行注册。
一般主流开放平台会选择云服务控制台给到开发者进行应用的申请、账户充值等操作,控制台一般需要承载能力签约、账户充值、文档下载检索、业务数据查看等多项功能。
(3)后端安全中心
开放平台的后端安全中心要解决的问题主要由两个:由接口调用一定会碰到的数据安全以及相关鉴权。这里做安全的小伙伴一定比我更专业,产品经理需要和运维中心、安全部门同事协商考虑好开放平台的后端安全中心建设。
四、技术接口设计
这里主要是基于目前项目的技术方案做的接口设计,当然市面上已经有很多技术大佬写过的开放平台技术设计方案,我这里不做过多的描述。产品经理了解大概的实现原理即可,这里更多需要关注的是接口在设计时候,作为开发者接入时候的开发成本,提高开发者的用户体验,我从这个角度来阐述下接口设计原则。
1. 接口简洁性
这里要考虑到,由于不同业务输出的复杂程度,会导致接口数量指数级飙升。如果是纯API接入的开发者,在理解接口调用时序图时会花更多时间。尝尝会在实际调用时卡在莫名其妙的节点,这里就需要只输出必要接口,并且保证接口足够简介易懂。
由于开发平台建设方,未必有足够资源建设SDK中心,那么对于开发者来说就不是那么友好,因此纯API接入文档的接口和调用方式需要保证和主流接口有一定相似性,最大程度确保开发者能快速熟悉接口。
2. 接口兼容性
这里主要是考虑到,不同开发者应用的平台不同。例如某些专门输出给硬件厂商的开放平台,此时就需要考虑到应用设备前端版本不同,对应参数范围也会造成差异。这里可以考虑各自业务具体形式来设计。
五、运营设计
开放平台的成功运行,离不开良好的平台运营。那么这里需要对平台运营的各个环节进行流程设计,确保每个环节都保证足够高效。
这里我贴上一份目前项目开放平台的对接流程示意图
如需引用请联系作者
大部分商业化的开放平台项目可以基于上述流程做变更。
需要注意的是,业务输出特性不同,会影响运营参与角色不同。比如我所在项目,实际运营人员还包括了客服,因为需要用到客服能力解决接入方平台的客诉问题。那么次数处理流程里面就需要包含客服处理流程。以及产品需要针对业务,给内部客服部门做客服文档,提供客服sop,优化处理流程。
六、落地细节
撰文过程中,考虑到开放平台建设的通用性,没有将建设的很多细节写出来,这里我单独加一个板块来介绍,希望给平台设计者避坑。
需要明确开放平台的核心用户是谁?大部分人的第一反应,核心用户一定是开发者。其实这个答案可以说是也可以时候不是,由于B端商业化商品的特殊性,大部分产品设计出来是给到某一类角色用的(而非具体某个人),开放平台的使用用户角色大部分是开发者,这点没错。
然而,实际上为这个商业产品买单的用户,大部分情况下是公司决策者,这里就代表,如果需要这个平台持续被买单,需要满足的核心用户实际上是公司决策者。
举个例子,只要是打过工的小伙伴大部分都过钉钉打卡这样类似功能。这个产品本质上是B端产品,有签到的功能,签到的时候直接可以定位,对员工而言这简直就是个反人性的功能,员工作为个体本身是很排斥打卡的,钉钉却把打卡功能延展了各种反作弊的功能(比如定位、面容识别),可没办法谁让钉钉是个B端产品。
所以B端产品就算体验不好,甚至是反人性的,只要管理者觉得达成了管理目标,你就要必须使用系统,因为你不是你自己,你是企业的一份子。
企业决策者最关心的问题,实际上是开放平台的能力是否能给企业降本增效,当然并不是说不需要关心开发者的用户体验,而是平台设计者需要把更多的时间花在企业决策者的考虑角度上,要满足为你付费的用户的核心需求。
七、后记
感谢能坚持看到最后的各位,开放平台的建设是一个长期的过程,中间会经历多次迭代,甚至由于公司的业务的调整影响开放平台的基础能力的建设。
设计者除了要为功能负责之外,更多的是陪伴开放平台的成长,开放平台的概念最早形成于2010年左右,目前各大互联网平台都有自己的开放平台生态,服务了无数开发者以及企业。随着OpenAI的火爆,相信平台建设者都逐渐致力于形成自己平台的护城河,为企业提供更多元化,更有意思的能力。我作为建设者之一,也很希望看到中小厂利用核心能力建设开放平台,也希望本文能帮助到各位建设者。
本文由 @不知柯 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
![ChatGPT爆火的下一步:API与平台战争](https://image.woshipm.com/wp-files/2023/03/xyWJANuyMUcS1xRZYy1Z.jpg!/both/120x80)
![入局跑腿业务,滴滴、高德们找到新战场](https://image.woshipm.com/2023/04/13/ffdf9b9a-d9ee-11ed-a8b0-00163e0b5ff3.jpg!/both/120x80)
![对账时的“支付清算文件”解析配置](https://image.woshipm.com/2023/04/14/e76d762c-da8e-11ed-a86f-00163e0b5ff3.jpg!/both/120x80)
![浅谈拉新环节的黑产防控](https://image.woshipm.com/wp-files/2023/03/QEvUEwULrKDrwKpknkTW.png!/both/120x80)
![小白必看!3 个方法,教你从容应对业务需求](https://image.woshipm.com/2023/07/07/47087d62-1c97-11ee-94c6-00163e0b5ff3.jpg!/both/120x80)
你好,文章很有启发,可以针对平台架构设计,再深度讲解一下吗,例如图示的API网关的每一项是起什么作用的,十分感谢
感谢分享,请问笔者有上线的门户网址可以查阅学习吗
目前项目上线的开放平台主要面向B端企业,需要签约后创建应用。建议可以先体验百度、微信、支付宝、高德这种可以对个人开发者的开放平台,整体设计理念是一致的。
好的,还想问一下这些接口是沿用已有的直接开发给商户调用,还是说是重新出接口给商户调用的呢【重新出的接口实际输出内容跟原因的一样】
可以根据自身业务依赖接口的复杂程度来决定。就我项目的接口设计来说是沿用部分已有的接口做封装给到开发者调用,因为业务本身逻辑已经比较复杂且关键节点接口数量较多,如果全部重新出接口开发成本过大,测试端的压力也会比较大。