对于没有接触过本文界面的PM,是知识的重点,对于接触过的PM,是讨论和分享。
接口有什么作用?作为一家互联网公司,很多资源和信息内容必须内部共享或者对外流通,所以相关数据必须按照接口传输。2C和2B的产品都会使用接口,其中2B的产品——数据、后台管理、开放平台/供应链管理——基本都是面对面接触接口。
接口如何使用?目的不同,使用方法并列。本文通过美团的门票来说明重点,详细介绍了界面的基本特点、商品逻辑和异常现象,供大家参考和讨论。
怎么理解接口?API是应用程序编程接口的总称,是一些预定义的函数,包括接口的详细地址、传递参数和返回参数。
可以简单理解为,当你要浏览一些数据时,一切正常都达到标准参数,你会收到数据类别内的返回参数。
情况:在美团旅行频道栏目中,客户选择时间、地址搜索航班,后台管理会启用搜索界面传输时间、地址等参数,接受航班类型、价格等参数,并在前台接待页面按顺序显示。同样,提交订单时会启用生成单据的界面来确定是否生成,支付时会启用付款的界面进行买卖,订单情况会自动修改。
商品逻辑性很多企业都有开放平台(也叫供应链管理)。比如美团外卖做服务平台,很多经销商要把自己的资源导入服务平台,集中展示在服务平台的网页上,供客户选择。正常情况下,美团外卖里会有一个windowssockets。经销商可以开发设计接口进行连接,这个接口叫做(货运价格)传输数据。
以美团以下门票为例。这个链接http://open.trip.meituan.com/是一个商店连接的开放平台,它不是保密的。门店技术人员和销售人员可以根据详细地址上的界面连接门店。
1.体系结构
票费传输数据系统软件根据接口将门店的票费数据引导至美团外卖业务,根据顾客个人行为轨迹完成“搜索-预订-提交订单-支付-售后服务”的自动化技术。通过邮件等方式对异常现象进行预警,并进行人工干预解决。
(详细步骤见此链接https://www.processon.com/view/link/5943EC7A4B0BDEFC0582E3E)
①正常情况下,涉及前台接待和客户个人行为的工作流程:
②与后台管理和订单信息升级相关的商品数据(部分简单):
2.接口一览根据接口类型和特点,可分为三类:数据类、交易类和公告类。一部分是美团的外卖界面,另一部分必须由店家开发设计。
数据类:店家数据对收到美团外卖(牵涉到店家的4个接口,获取商品信息、商品转变通告、获取旅游景点信息内容、获取价钱日历)买卖类:“客户——美团外卖——店家”的买卖个人行为(牵涉到店家的五个接口)通告类:包含店家开发设计的已取票、票已应用、已退钱3个接口,美团外卖已有的已退钱、查询余额、编辑出版情况通告的3个接口。出现异常难题我做的界面产品不多,但是问题都差不多。重点包括两类:界面问题和商品问题。界面问题反应迟钝,反应慢,反应反复等。商品问题有总量小、调价快、因时差升级不及时等。
在做与接口相关的产品时,异常的发生和所有正常步骤一样关键,这不是用关键客户和边缘客户来定义的。所以在考虑每一步的时候,既要有异常问题的发生,也要有异常问题的解决,这样才能最大限度的减少对顾客体验的伤害和店铺的损害。
一般的解决方案是数据监管,基于每个业务流程连接点的多种指标。一旦超过阈值,可以通过邮件和短信的方式通知相关工作人员,立即解决困难。
接下来我们实际上从两个层面来讨论如何解决这个问题。
1.客户体验-实际情况和数据监督
对于客户来说,任何一个步骤的连接点不顺畅,都会造成不好的感受。所以数据监管是根据客户的个人行为轨迹来进行的。
①网页显示缓慢——界面响应时间、客户端网页停留时间、跳出率。
Reason:即时调接口查看旅游景点&商品信息,因数据量大或頻率快造成。Solution:缓存文件数据,每N分鐘升级一次。②异常数据呈现——后台管理返回异常界面的频率和概率。
Reason:接口请求超时或出现异常。Solution:能够设置反复启用,数次再试不成功后,根据电子邮件等方式通告到经营、技术性或店家。对于数据接口,停止销售或隐藏商品。
对于交易界面,提交订单和付款的问题可以提示客户,强烈推荐客户同行业,停售商品或隐藏;退款问题可以建议客户以后再试,如果比较急可以联系在线客服解决。
对于公告界面,如果不涉及客户,可以通过电子邮件解决,通过人工干预升级信息内容。
③商品变化,尤其是调价——订单提交出错率、调价率、出票失败率。
Reason:数据升级有时差。Solution:当某一商品的失误率或调价率超过要求,可掩藏或停售;对于一些商品库存量少的状况开展提醒,预告片风险性;设置有效的定时执行升级每日任务。④提交订单/付款/退费不成功-错误率和不成功原因。
Reason:客户很有可能数次递交,或是订单信息已应用、已关掉等客观因素,没法取得成功。Solution:必须添加检测体制,例如在短期内内反复递交不启用接口,立即回到原結果;真诚提示客户不必反复递交,如“您的手太快,请歇息30s后再试”;能够出示IM人力或咨询热线、留言板留言等选择项。⑤服务项目响应速度长——手订单信息量和份额。
Reason:例如客户递交退票费后长期不退钱;付款后长期不取票Solution:定时执行启用订单号查询接口,升级订单信息并短消息/消息推送信息告之客户;超出服务质量标准時间前推送预警信息电子邮件,人力干预解决。2.商店感受-数据监督和实际情况
对于门店来说,客户体验不重要,转化率和利润才是关键,所以数据监管以业务流程指标值为主。
①订单重复、订单不付款占库存-订单信息、订单信息交易转化率、付款差错率、使用情况占库存、第三方支付。
Reason:客户反应力太快;故意占库存量Solution:制订标准,同一人只有占一个库存量;同一订单信息数最多只有订N本人。②界面的有意和重复激活——所涉及的每个界面的激活频率。
Reason:例如短期内反复启用某一接口Solution:要求同一IP地址不可以在短期内内数次启用;立即回到第一次启用接口的結果,已不反复启用;每一个接口在同一时间数最多N次启用,不然回到不成功等。(3)数据升级不及时造成的损失——(佣金、广告)投入产出率,人为因素损害。
Reason:客户应用后退钱进行、客户付款后调价等Solution:依据时差、解决标准来确立划分义务方。④清算问题——会计审计本身的费用(退款)和收入(卖给美团外店铺的清算金额)
Reason:服务平台和店家以“TN”的方法清算Solution:B端订单管理系统里的会计查账作用,可以用电子邮件方式每日推送;检测出现异常数据,如当日无清算、清算额度与订单金额不一致。也就是界面的关键应用目标和逻辑。逻辑不是太难,而是复杂。我们必须仔细和全面地考虑各种情况,并期待与您讨论。
文章作者为@大乔,未经批准严禁截取。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)