OTA实战分解(1):快速阅读API及场景应用

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

如何快速阅读一个API并且转化为线上场景应用,这应该是产品经理尤其是B端产品经理必备的技能。本系列文章将从笔者亲身的一些OTA旅游产品对接经历入手,分享一些踩过的坑,背过的锅。

在一个公司中免不了有很多业务需要对外合作,当业务规模成长到一定阶段后就需要技术的介入:解放生产力,降低成本,提高效率。

此时,产品经理在了解业务需求、调研需求、解决需求的过程中就需要接触到各个外部接口。

一、API的认知

1. 场景举例

  • 场景一:某平台对商户出了最新的考核标准,要求拒单率控制在3%以内,及时确认率控制在98%以上,我们还差得远——来自运营的忧虑。
  • 场景二:公司有一批很好的门票产品,在我们的自己的渠道销售得非常好,现在公司想把这些产品放到几个OTA上去售卖,并且资源可控可以满足运营与要求。但是数量是1000条,假设上线到3个平台,按照1个员工手动搬运产品(Ctrl+C然后Ctrl+V),6条/天/人,处理完3个平台需要500个工作日,约2年。

上述两个场景中,我们可以明显得到的信息是人工生产力已经不能满足当前公司业务的发展需求了。

那在这个时候,API就要开始大显身手,产品经理需要从技术层面来解放生产力。

2. 什么是API?

Application Programming Interface,应用程序编程接口,即单方面约定一些预先定义的数组或字段,便于模块外开发人员获取信息并了解API想表达的细节。

API应用到上述场景中,即为了解决两个主要的问题:

  1. 快速上线产品到OTA平台:通过API将完整的产品拆分为若干模块,在符合平台要求的场景下传输到平台上完成上线,并且可以自动化的更新多个平台的产品信息、价格、库存等;
  2. 快速获取OTA平台订单信息:通过API的订阅或主动查询,以最快速度获取到各个平台的订单详情,通过标准解析后统一输出到自有ERP中进行相关处理。

还是不懂?

再举一个直白的例子:

小时候妈妈经常让我去打酱油,每次都要去村口很远的小卖部去付钱购买,再拿酱油回家;一贪玩把酱油摔坏了,回家骗妈妈说小卖部不卖酱油了,钱掉了,一顿胖揍(人工搬单、效率低下、责任不清)。

时代进步,现在有了微信,妈妈再也不用我打酱油了。

妈妈微信里面问询:老板,酱油一瓶(API数据请求)。

老板回复:30元起送,一瓶不够(API响应报错)。

妈妈再次问询:老板,10瓶酱油(API重试,数据请求)。

老板回复:好勒,10分钟送到,30元,老规矩微信支付(API响应成功)。

妈妈:微信红包30元(调用其他API接口请求)。

老板:已收款(API响应成功并确认)。

流程结束,效率提升,责任清晰,有聊天记录(日志)可查。

二、业务侧的理解

此时的流程与正常的需求处理是完全一致,需要全面的了解业务侧的真实意图,并针对API进行相关调研,最后进行需求的确认。

1. 业务想要的是什么?

我们需要对业务的两个场景进行拆分,通过场景一分析,见图1,可得业务方想得到为“拒单率3%以内”。

淘宝购物都知道供应商拒单无非三个方面:没货了,价格涨价了,产品拍错了;即要降低拒单率,在这三个方面进行优化即可。

“及时确认率98%以上”:及时与确认是两个维度,一个要求对时间掌控强,一个要求订单要确认成功;即我们需要深入分析如何提高及时响应订单,成功确认订单(与上一个需求环环相扣)。

综上所述,我们需要的API不仅要满足产品更新的需求,也需要满足订单的需求。

图1 场景一需求拆分

场景二的分析,业务方的需求比较简单,即实现快速上线。但我们对需求进行拆分挖掘(见图2),发现需求除了要求上线产品基本内容+价格库存外,其实还有一个非常重要的隐藏需求,即下单相关属性的需求(因为部分产品上线前就要预置下单信息,例如必填信息,是否限购等)。

综上所述,本需求除了产品API,还应该去匹配API中其他必要字段,并可能需要有分平台的管理系统来分别匹配各自平台的不同字段需求。

图2 场景二需求拆分

2. API怎么做需求调研?

很多人会问上面的需求是怎么分析得到的?API不就是完成数据解析,存储就可以了吗?

此言差矣,API数据接入其实只是API接入的一小部分,更多是数据接入后的处理兼容,以及如何让数据发光发热。

API的需求调研主要分为两个方面来做:

首先,将业务分为已经存在的业务优化方向以及新增业务的功能新增方向。

  • 已经存在的业务优化方向:例如已经接入了A平台,现在要接B平台,工作量一致,内容相似度较高,只需要将我们之前积累的对接经验搬出来套用即可;
  • 新增业务的功能新增方向:例如已经接入了产品更新功能,现在要接入订单确认功能,完全不同的业务,需要我们重新分析业务需求,重新定义接口数据。

此时,我们再回来对之前的场景一、二进行深度挖掘与分析。

场景一中对于拒单率的要求,我们初步理解为其实是对库存、售价、产品内容的要求,针对性的场景中需要满足我们对库存的分发实时把控,可以理解为某个平台库存为0并不等于总库存为0,此时我们需要采用总分的结构来设计功能;针对价格的更新亦是同样的道理,针对不同平台的人群画像,其采用的销售策略是完全不一致的。

但是针对产品内容来说,则需要保持高度一致,因为所有的人出游产品是一致的那披露的内容也应该是一致的,必须要做到全平台的一致,既范了流程,也节约了后续开发工作量,如图3。

图3 场景一需求进一步