作为产品经理,不懂一点接口怎么行?
本文针对没有接触过接口的PM来说是划知识点,对接触过的PM来说是讨论和分享。
接口有什么用?
作为一个互联网公司,很多资源和信息需要内部共享或外部流通,那相关的数据就需要通过接口来传输。无论是2C还是2B的产品,都会用到接口,其中2B的产品们——数据、后台、开放平台/供应链,几乎和接口都是正面接触。
接口怎么用?
目的千差万别,用法殊途同归。本文主要以美团门票举例,介绍接口的基本属性、产品逻辑和异常情况等,供大家参考和讨论。
怎么理解接口?
API接口是Application Programming Interface的简称,是一些预先定义的函数,包括接口地址、传入参数和返回参数。
可以简单理解为,当需要访问某些数据,正常状态下传入合格参数,会收到该数据范围内的返回参数。
场景:在美团旅游频道,用户选定时间、地点后搜索航班,后台会调用搜索接口传入时间、地点等参数,接收航班类别、价格等参数,在前台页面上进行排列展示。同理,下单时会调用生单接口确认是否成单,支付时会调用支付接口完成交易,自动修改订单状态。
产品逻辑
很多公司都有开放平台(也叫供应链),比如美团作为一个平台,很多的供应商需要把自身资源导入平台,在平台页面上集中展示,供用户选择。一般情况下,美团会有自身的一套接口,供应商可以开发对应的接口进行对接,这种叫(运价)直连。
以下以美团门票为例,此链接http://open.trip.meituan.com/是商家对接的开放平台,不涉密,商家技术、业务人员可以通过该地址上的接口说明进行商家对接。
1.系统结构
门票直连系统是通过接口,把商家的门票数据导入到美团上收单,按用户行为轨迹来说,实现“搜索-预定-下单-支付-售后”的自动化。异常情况通过邮件等形式预警,手工介入处理。
(详细流程见此链接https://www.processon.com/view/link/5943ec7ae4b0bdefc0582e3e)
①正常情况下,涉及前台和用户行为的业务流程:
②涉及后台的产品数据&订单状态更新(部分简略):
2.接口总览
按接口类型和属性可分为三类:数据类、交易类和通知类。有一部分为美团接口,另一部分接口需要商家进行开发。
- 数据类:商家数据对接到美团(涉及到商家的4个接口,拉取产品信息、产品变化通知、拉取景点信息、拉取价格日历)
- 交易类:“用户——美团——商家”的交易行为(涉及到商家的5个接口)
- 通知类:包括商家开发的已出票、票已使用、已退款3个接口,美团自有的已退款、查余额、编审状态通知的3个接口。
异常问题
我做过的接口产品不多,但问题类似,主要包括两类:接口问题、产品问题。接口问题就是无响应、响应过慢、重复响应等,产品问题就是存量少、变价快、时间差导致下架更新不及时等。
在做接口相关的产品时,异常与正常流程同等重要,这与核心用户和边缘用户不是一个概念。所以在考虑每一步的流程时,必须兼顾异常问题的发生与解决方法,尽量避免损害用户体验和商家损失。
一般的解决方法是数据监控,通过对每个业务节点的多项指标进行监控,一旦超出阈值,就可以用邮件、短信等形式通知相关人员,及时解决问题。
接下来我们从两个方面具体探讨如何应对这些问题。
1.用户体验——具体场景&数据监控
对用户来说,流程的任一节点不顺畅,都会导致体验不好,故根据用户行为轨迹来进行数据监控。
①页面展示慢——接口响应时长、用户页面停留时长、跳失率
- Reason:实时调接口查询景点&产品信息,因数据量大或频率快导致。
- Solution:缓存数据,每N分钟更新一次。
②数据展示异常——后台返回接口异常的次数和概率
- Reason:接口超时或异常。
- Solution:可以设定重复调用,多次重试失败后,通过邮件等形式通知到运营、技术或商家。
针对数据型接口,对产品进行下架或隐藏处理。
针对交易型接口,下单、支付的问题可以提醒用户、为用户推荐同类产品、对产品进行下架或隐藏处理;退票类问题可以建议用户之后重试,如果比较紧急可以联系客服加急处理。
针对通知型接口,不涉及用户,邮件处理即可,可人工介入更新信息。
③产品变动,特别是变价——下单失败率、变价率、出票失败率
- Reason:数据更新有时间差。
- Solution:
- 当某一产品的失败率或变价率超出规定,可隐藏或下架;
- 针对某些产品库存少的情况进行提示,预告风险;
- 设定合理的定时更新任务。
④下单/支付/退票失败——失败率、失败原因
- Reason:用户可能多次提交,或者订单已使用、已关闭等客观原因,无法成功。
- Solution:
- 需要加入检验机制,比如在短时间内重复提交不调用接口,直接返回原结果;
- 善意提醒用户不要重复提交,如“您的手太快了,请休息30s后再试”;
- 可以提供IM人工或电话咨询、留言等选项。
⑤服务响应时间长——手工操作订单量和占比
- Reason:比如用户提交退票后长时间不退款;支付后长时间不出票
- Solution:
- 定时调用订单查询接口,更新订单状态并短信/推送消息告知用户;
- 超过服务规范时间前发送预警邮件,人工介入处理。
2.商家体验——数据监控&具体场景
对商家来说,用户体验不重要,转化率和利润才是重点,故数据监控以业务指标为主。
①重复生单、生单不支付占库存——订单量、订单支付转化率、支付失败率、库存占用量和支付量
- Reason:用户手速太快;恶意占库存
- Solution:制定规则,同一人只能占一个库存;同一订单最多只能订N个人。
②恶意重复调用接口——涉及到的每个接口调用频率
- Reason:比如短时间重复调用某一接口
- Solution:
- 规定同一IP地址不能在短时间内多次调用;
- 直接返回第一次调用接口的结果,不再重复调用;
- 每个接口在同一时间最多N次调用,否则返回失败等。
③因数据更新不及时等导致的亏损——(佣金、广告)投入产出比、人为损失
- Reason:用户使用后退款完成、用户支付后变价等
- Solution:根据时间差、处理规则来明确划定责任方。
④结算问题——财务对账自身支出(退款)和收入(美团给商家的结算金额)
- Reason:平台和商家以“T+N”的方式结算
- Solution:
- B端订单系统里的财务对账功能,可以用邮件形式每日发送;
- 监测异常数据,如当日无结算、结算金额与订单金额不一致。
以上即为接口主要的应用对象和逻辑,逻辑不难但复杂度高,需要细心周到地考虑各种情况,希望能与大家一起讨论。
本文由 @小乔 原创发布于人人都是产品经理。未经许可,禁止转载。
我想问透传该怎么理解。。。
透明无感知地传输数据的含义。举个例子:
发短信功能(利用第三方服务腾讯云的发短信接口):当用户输入手机号码点击发送验证码时,先调用我们自己后台的发短信接口,然后我们后台调用腾讯云的发短信接口,把用户从前端传过来的手机号码再继续传给腾讯云接口。数据传递的链路是:前端->我们后台->腾讯云。后台没有对数据做任何修改就直接传给腾讯云的这个过程就是透传。
作者姐姐,我想问一下,系统与外部系统对接,是两边都需要出说明文档吗?各自对各自的,有的直接接口,没的再做?我是小白,老板让我负责这个
首先你们是平台方还是接入方?文档是平台方出的,接入方按照文档做就可以了。
是否异步出票为“是”时,为什么支付状态是“支付中”呢,前面不是已经支付过了吗?
前面的是否支付成功我认为应该是客户支付验证是否成功,提交后,还未划款,需要先做验证—是否可以出票,如果出票不成功,则支付无效,结果是支付不成功。故在出票过程中可定义为支付中。如果理解错了,欢迎指正
前面还有一步“是否可支付”,不是在验证订单是否可支付么
作者大大可以问两个问题么?
1.为什么拉取商户的产品信息要透传,加密传输一般写一套应该就行,加密传输不会影响效率也不会增加工作量,所以这里使用透传和非透传是不是没有什么区别?
2.什么叫变价率呢?
期盼回复~~ 😉
1.没有特殊要求,都行没区别。
2.变价率是指某一条数据产生的价格变动的情况较多,超出自设的警戒值。
接口其实就是实现两个系统(平台)之间数据相互调用,以保证数据闭环。对于2C产品来说,数据的共享是很敏感的事情,必须有商务运作。
能加个联系方式吗 微信或者QQ什么的
公众号:qiaomaihexiaoqiao(乱入花间化绿叶)
有问题可以私聊
接口文档也是产品写吗?
是技术写,但是需要了解一下会出现的问题 知己知彼
已退款消息,应该是合作方→美团吧。
透传是啥意思
不加工的传输
你是数据产品吗?
不是,算是参与过
突然想拜你为师了,可以吗
来啊来啊,关注我的公众号吧~~ 😉
公众号是啥
qiaomaihexiaoqiao(乱入花间化绿叶)
搜不到这个公众号呀
可以转发到朋友圈吗
可以啊,你说的是转载还是转发?
感谢分享
文章写的很好,再接再厉!
get知识点了~~
感同身受。遇到接口调用无响应、响应过慢、重复响应,接口调用无重发机制,回调超时……
很厉害
mark
作为程序员给作者点个赞,头像也好看
收藏了,不错 😮
接口总览那里的通知类接口是不是说反了?已出票、票已使用、已退款3个接口是美团开发的,已退款、查余额、编审状态通知的3个接口是商家开发的才对吧?
不是的。有些接口其实意思一致,但因为行为发起方和接收方不同,所以开发者不同。
已出票是商家在接到付款成功订单后为用户出票,然后通知美团票已出,之后美团再去通知用户,票已使用、已退款这两个接口同理。
订单退款通知接口和已退款接口其实是一样的,只不过行为分别由商家和美团发起(因为用户提交申请的理由和时间等情况不同),所以分别开发接口。查余额是美团通知商家,需要连接商家的接口才能通知到;编审状态通知也是美团去通知商家。
我突然间混乱了。。。。
正确的应该为:“通知类接口:包括美团开发的已出票、票已使用、已退款3个接口,商家的订单退款、查余额、编审状态通知的3个接口。”
恩恩,感谢作者的认真解答~对接口的理解更进了一步 😉
谢谢你的细心和反馈~~ 😉
作者对接口了解这么多 是程序出身吗
不是,正经文科生 😎
难得
向你学习了。
好文 好文 收藏了!我喜欢主页那个图片哦!
小乔你好,我是大乔。来吧,一起王者荣耀。
没玩过~
好尴尬
我是周瑜
围观丑拒。
撩妹失败 换个套路吧
围观丑拒。
围观丑拒。
会员强撩翻车现场
你好我是孙权,快跟我回家。