作为产品经理,不懂一点接口怎么行?

55 评论 194547 浏览 1733 收藏 10 分钟

本文针对没有接触过接口的PM来说是划知识点,对接触过的PM来说是讨论和分享。

接口有什么用?

作为一个互联网公司,很多资源和信息需要内部共享或外部流通,那相关的数据就需要通过接口来传输。无论是2C还是2B的产品,都会用到接口,其中2B的产品们——数据、后台、开放平台/供应链,几乎和接口都是正面接触。

接口怎么用?

目的千差万别,用法殊途同归。本文主要以美团门票举例,介绍接口的基本属性、产品逻辑和异常情况等,供大家参考和讨论。

怎么理解接口?

API接口是Application Programming Interface的简称,是一些预先定义的函数,包括接口地址、传入参数和返回参数。

可以简单理解为,当需要访问某些数据,正常状态下传入合格参数,会收到该数据范围内的返回参数。

场景:在美团旅游频道,用户选定时间、地点后搜索航班,后台会调用搜索接口传入时间、地点等参数,接收航班类别、价格等参数,在前台页面上进行排列展示。同理,下单时会调用生单接口确认是否成单,支付时会调用支付接口完成交易,自动修改订单状态。

产品逻辑

很多公司都有开放平台(也叫供应链),比如美团作为一个平台,很多的供应商需要把自身资源导入平台,在平台页面上集中展示,供用户选择。一般情况下,美团会有自身的一套接口,供应商可以开发对应的接口进行对接,这种叫(运价)直连。

以下以美团门票为例,此链接http://open.trip.meituan.com/是商家对接的开放平台,不涉密,商家技术、业务人员可以通过该地址上的接口说明进行商家对接。

1.系统结构

门票直连系统是通过接口,把商家的门票数据导入到美团上收单,按用户行为轨迹来说,实现“搜索-预定-下单-支付-售后”的自动化。异常情况通过邮件等形式预警,手工介入处理。

(详细流程见此链接https://www.processon.com/view/link/5943ec7ae4b0bdefc0582e3e)

①正常情况下,涉及前台和用户行为的业务流程:

②涉及后台的产品数据&订单状态更新(部分简略):

2.接口总览

按接口类型和属性可分为三类:数据类、交易类和通知类。有一部分为美团接口,另一部分接口需要商家进行开发。

  1. 数据类:商家数据对接到美团(涉及到商家的4个接口,拉取产品信息、产品变化通知、拉取景点信息、拉取价格日历)
  2. 交易类:“用户——美团——商家”的交易行为(涉及到商家的5个接口)
  3. 通知类:包括商家开发的已出票、票已使用、已退款3个接口,美团自有的已退款、查余额、编审状态通知的3个接口。

异常问题

我做过的接口产品不多,但问题类似,主要包括两类:接口问题、产品问题。接口问题就是无响应、响应过慢、重复响应等,产品问题就是存量少、变价快、时间差导致下架更新不及时等。

在做接口相关的产品时,异常与正常流程同等重要,这与核心用户和边缘用户不是一个概念。所以在考虑每一步的流程时,必须兼顾异常问题的发生与解决方法,尽量避免损害用户体验和商家损失。

一般的解决方法是数据监控,通过对每个业务节点的多项指标进行监控,一旦超出阈值,就可以用邮件、短信等形式通知相关人员,及时解决问题。

接下来我们从两个方面具体探讨如何应对这些问题。

1.用户体验——具体场景&数据监控

对用户来说,流程的任一节点不顺畅,都会导致体验不好,故根据用户行为轨迹来进行数据监控。

①页面展示慢——接口响应时长、用户页面停留时长、跳失率

  • Reason:实时调接口查询景点&产品信息,因数据量大或频率快导致。
  • Solution:缓存数据,每N分钟更新一次。

②数据展示异常——后台返回接口异常的次数和概率

  • Reason:接口超时或异常。
  • Solution:可以设定重复调用,多次重试失败后,通过邮件等形式通知到运营、技术或商家。

针对数据型接口,对产品进行下架或隐藏处理。

针对交易型接口,下单、支付的问题可以提醒用户、为用户推荐同类产品、对产品进行下架或隐藏处理;退票类问题可以建议用户之后重试,如果比较紧急可以联系客服加急处理。

针对通知型接口,不涉及用户,邮件处理即可,可人工介入更新信息。

③产品变动,特别是变价——下单失败率、变价率、出票失败率

  • Reason:数据更新有时间差。
  • Solution:
  1. 当某一产品的失败率或变价率超出规定,可隐藏或下架;
  2. 针对某些产品库存少的情况进行提示,预告风险;
  3. 设定合理的定时更新任务。

④下单/支付/退票失败——失败率、失败原因

  • Reason:用户可能多次提交,或者订单已使用、已关闭等客观原因,无法成功。
  • Solution:
  1. 需要加入检验机制,比如在短时间内重复提交不调用接口,直接返回原结果;
  2. 善意提醒用户不要重复提交,如“您的手太快了,请休息30s后再试”;
  3. 可以提供IM人工或电话咨询、留言等选项。

⑤服务响应时间长——手工操作订单量和占比

  • Reason:比如用户提交退票后长时间不退款;支付后长时间不出票
  • Solution:
  1. 定时调用订单查询接口,更新订单状态并短信/推送消息告知用户;
  2. 超过服务规范时间前发送预警邮件,人工介入处理。

2.商家体验——数据监控&具体场景

对商家来说,用户体验不重要,转化率和利润才是重点,故数据监控以业务指标为主。

①重复生单、生单不支付占库存——订单量、订单支付转化率、支付失败率、库存占用量和支付量

  • Reason:用户手速太快;恶意占库存
  • Solution:制定规则,同一人只能占一个库存;同一订单最多只能订N个人。

②恶意重复调用接口——涉及到的每个接口调用频率

  • Reason:比如短时间重复调用某一接口
  • Solution:
  1. 规定同一IP地址不能在短时间内多次调用;
  2. 直接返回第一次调用接口的结果,不再重复调用;
  3. 每个接口在同一时间最多N次调用,否则返回失败等。

③因数据更新不及时等导致的亏损——(佣金、广告)投入产出比、人为损失

  • Reason:用户使用后退款完成、用户支付后变价等
  • Solution:根据时间差、处理规则来明确划定责任方。

④结算问题——财务对账自身支出(退款)和收入(美团给商家的结算金额)

  • Reason:平台和商家以“T+N”的方式结算
  • Solution:
  1. B端订单系统里的财务对账功能,可以用邮件形式每日发送;
  2. 监测异常数据,如当日无结算、结算金额与订单金额不一致。

以上即为接口主要的应用对象和逻辑,逻辑不难但复杂度高,需要细心周到地考虑各种情况,希望能与大家一起讨论。

 

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我想问透传该怎么理解。。。

    回复
    1. 透明无感知地传输数据的含义。举个例子:
      发短信功能(利用第三方服务腾讯云的发短信接口):当用户输入手机号码点击发送验证码时,先调用我们自己后台的发短信接口,然后我们后台调用腾讯云的发短信接口,把用户从前端传过来的手机号码再继续传给腾讯云接口。数据传递的链路是:前端->我们后台->腾讯云。后台没有对数据做任何修改就直接传给腾讯云的这个过程就是透传。

      来自湖北 回复
  2. 作者姐姐,我想问一下,系统与外部系统对接,是两边都需要出说明文档吗?各自对各自的,有的直接接口,没的再做?我是小白,老板让我负责这个

    回复
    1. 首先你们是平台方还是接入方?文档是平台方出的,接入方按照文档做就可以了。

      来自江苏 回复
  3. 是否异步出票为“是”时,为什么支付状态是“支付中”呢,前面不是已经支付过了吗?

    来自四川 回复
    1. 前面的是否支付成功我认为应该是客户支付验证是否成功,提交后,还未划款,需要先做验证—是否可以出票,如果出票不成功,则支付无效,结果是支付不成功。故在出票过程中可定义为支付中。如果理解错了,欢迎指正

      来自江苏 回复
    2. 前面还有一步“是否可支付”,不是在验证订单是否可支付么

      来自四川 回复
  4. 作者大大可以问两个问题么?
    1.为什么拉取商户的产品信息要透传,加密传输一般写一套应该就行,加密传输不会影响效率也不会增加工作量,所以这里使用透传和非透传是不是没有什么区别?
    2.什么叫变价率呢?
    期盼回复~~ 😉

    来自北京 回复
    1. 1.没有特殊要求,都行没区别。
      2.变价率是指某一条数据产生的价格变动的情况较多,超出自设的警戒值。

      来自北京 回复
  5. 接口其实就是实现两个系统(平台)之间数据相互调用,以保证数据闭环。对于2C产品来说,数据的共享是很敏感的事情,必须有商务运作。

    来自辽宁 回复
  6. 能加个联系方式吗 微信或者QQ什么的

    来自北京 回复
    1. 公众号:qiaomaihexiaoqiao(乱入花间化绿叶)
      有问题可以私聊

      来自北京 回复
  7. 接口文档也是产品写吗?

    来自广东 回复
    1. 是技术写,但是需要了解一下会出现的问题 知己知彼

      来自浙江 回复
  8. 已退款消息,应该是合作方→美团吧。

    来自北京 回复
  9. 透传是啥意思

    来自北京 回复
    1. 不加工的传输

      来自北京 回复
  10. 你是数据产品吗?

    来自广东 回复
    1. 不是,算是参与过

      来自北京 回复
  11. 突然想拜你为师了,可以吗

    回复
    1. 来啊来啊,关注我的公众号吧~~ 😉

      来自北京 回复
    2. 公众号是啥

      来自广东 回复
    3. qiaomaihexiaoqiao(乱入花间化绿叶)

      来自北京 回复
    4. 搜不到这个公众号呀

      来自四川 回复
  12. 可以转发到朋友圈吗

    来自北京 回复
    1. 可以啊,你说的是转载还是转发?

      来自北京 回复
  13. 感谢分享

    来自四川 回复
  14. 文章写的很好,再接再厉!

    回复
  15. get知识点了~~

    来自湖北 回复
  16. 感同身受。遇到接口调用无响应、响应过慢、重复响应,接口调用无重发机制,回调超时……

    来自北京 回复
  17. 很厉害

    来自湖南 回复
  18. mark

    来自江苏 回复
  19. 作为程序员给作者点个赞,头像也好看

    来自广东 回复
  20. 收藏了,不错 😮

    来自上海 回复
  21. 接口总览那里的通知类接口是不是说反了?已出票、票已使用、已退款3个接口是美团开发的,已退款、查余额、编审状态通知的3个接口是商家开发的才对吧?

    来自广东 回复
    1. 不是的。有些接口其实意思一致,但因为行为发起方和接收方不同,所以开发者不同。
      已出票是商家在接到付款成功订单后为用户出票,然后通知美团票已出,之后美团再去通知用户,票已使用、已退款这两个接口同理。
      订单退款通知接口和已退款接口其实是一样的,只不过行为分别由商家和美团发起(因为用户提交申请的理由和时间等情况不同),所以分别开发接口。查余额是美团通知商家,需要连接商家的接口才能通知到;编审状态通知也是美团去通知商家。

      来自北京 回复
    2. 我突然间混乱了。。。。

      来自北京 回复
    3. 正确的应该为:“通知类接口:包括美团开发的已出票、票已使用、已退款3个接口,商家的订单退款、查余额、编审状态通知的3个接口。”

      来自北京 回复
    4. 恩恩,感谢作者的认真解答~对接口的理解更进了一步 😉

      来自广东 回复
    5. 谢谢你的细心和反馈~~ 😉

      来自北京 回复
  22. 作者对接口了解这么多 是程序出身吗

    来自吉林 回复
    1. 不是,正经文科生 😎

      来自北京 回复
    2. 难得

      来自北京 回复
    3. 向你学习了。

      来自上海 回复
  23. 好文 好文 收藏了!我喜欢主页那个图片哦!

    来自上海 回复
  24. 小乔你好,我是大乔。来吧,一起王者荣耀。

    来自广东 回复
    1. 没玩过~

      回复
    2. 好尴尬

      来自广东 回复
    3. 我是周瑜

      来自江苏 回复
    4. 围观丑拒。

      来自北京 回复
    5. 撩妹失败 换个套路吧

      来自北京 回复
    6. 围观丑拒。

      来自四川 回复
    7. 围观丑拒。

      来自北京 回复
    8. 会员强撩翻车现场

      来自上海 回复
    9. 你好我是孙权,快跟我回家。

      来自广东 回复