京东业务中台接口之一：剔除/清洗标/售后逆向流
2022-06-24 09:57阅读：
业务值罗列
1、扫二维码-首次风控（PIN） -剔
- 1、应用于：前置二维码扫描校验 和 用户输入手机号校验，参与资格和黑户的校验
- 2、RCS风控接口：【风控网关】接入文档
- 3、应用说明：入参对应字段，返回参数关注点步骤
步骤1、return（接口调用是否成功）
步骤2、dangerResult （风控是否拦截，以该字段为最优先判断）
步骤3、dwWqRisk （具体code含义看文档最下方）
注：不能使用dwWqRisk作为拦截判断
,观察者模式也会返回该原因,如果需要根据不同拦截原因做相应策略，请优先判断dangerResult（存在部分是正常延迟）
2022.3.8给出
风控部署：
1、【事前】运营侧下发奖励任务，团长通过活动链接生成专属推广二维码并分享给用户，用户扫描团长二维码时，调RCS风控策略
741场景，如果命中风控用户，则提示”活动火爆，请试试其他活动“，如果非风控用户，符合任务规则的受邀人下载APP且在规定时间内完成首购则代表团长邀新成功，邀新状态显示”有效“，不满足以上条件，邀新状态显示”无效“，；
2、【事后】受邀人在规定时间内下单后到收货后之后开始算（不包含收到货的当天）7天内，每天调取一次RCS风控策略
750场景，如果命中风控用户，则邀新状态显示为”无效“，佣金失效，失效类型为：本用户暂无法参与活动，请试试其他活动；如果未命中风控用户，且
业务侧逻辑判定为订单和用户为有效状态，风控侧与业务侧逻辑且为正常非风险的关系，则邀新状态继续维持为”有效“，佣金正常结算。
2、订单取消剔除-剔
ODC_CANCEL 取消消息
3、离线后置风控（PIN）-剔
- 1、应用于：应用于京喜新和黑的识别（T+2）
- 2、方式：待风控组制作给出
- 3、应用说明：
风控组：风控建议，先不用，拼拼拉新在做过滤的时候风控掉30%的用户；建议还是采用RCS风控，采用不同场景值；
4、售后订单 （AFS_StepResult）-剔
- 1、应用于：识别订单是否售后中、售后成功，方便做奖励剔除
- 2、接口：1.4
服务单全流程消息通知
- 3、应用说明：主要采用该stepType 和 afsResultType，2个字段搭配使用
- 4、场景区分：a）非结算当天：剔除【售后成功】b）结算当天：剔除【售后中】【售后成功】
- 5、注意事项：同个订单先命中了【售后中】，又命中【售后取消】【售后拒绝】，那么相当于【无售后】
参是识别
|
参数名称
|
类型
|
说明
|
| stepType |
处理环节 |
String |
申请(APPLY) 、审核(AUDIT) 、收货（RECEIVED）、
处理(PROCESS)、确认(CONFIRM) 、 用户点击已解决(COMPLETE) |
| afsResultType |
服务单状态 |
String |
stepType(APPLY)-- 创建 (APPLY)、 |
识别客户预期处理方式customerExpect的退货refund ，并看服务单状态afsResultType的一些枚举：
分为锁定、解锁、不发钱
1、 若命中stepType(申请APPLY)-- 创建
(APPLY)，裂变环节拆分新服务单（SPLIT_FLOW_NEW），则进行锁定； 【售后中】
（注释：售后单创建成功）
2、 若命中stepType(处理PROCESS)--原返取消(RETURN_CANCEL),则进行锁定。
【售后中】
（注释：客户提交退货申请，售后商品不符合售后要求，退还回客户这个流程被中止，售后服务继续进行）
3、 若命中stepType(审核AUDIT)--审核不通过(AUDIT_FAIL),
审核取消(CANCEL)，则做解锁。 【售后取消】
（注释：售后申请，消费者取消）
4、 若命中stepType(处理PROCESS)--原返(RETURN)，则做解锁
【售后拒绝】
（注释：客户提交退货申请，售后商品不符合售后要求，退还回客户，售后服务中止）
5、 若命中stepType(处理PROCESS)–退款（REFUND），则代表退款成功，不能给予客户奖励。
【售后成功】
（注释：售后成功退款）
设想应用：
可以通过售后命中类型，抽象成售后状态：售后中、售后成功、售后取消、售后拒绝，来提效判别
5、虚拟类-剔
1）订单中台类：
- 1、应用：订单区分虚拟订单的识别，方便做奖励剔除
- 2、接口：【官方】国际化订单类型
- 3、应用说明：下单MQ，通过消息体 = orderXml解析出OrderType、sendpay进行过滤
处理方式：通过ordertype进行打标
OrderType=4、8、28、33~39、43~48、51~53、55、57、58、62、64~74、76~87、90~100、102~111、113~201、128~141、143~150、153~173、176、180-192、194、196~203、205~208、210、213~215、217~221、224
2）京喜方：
处理方式：通过ordertype和sendpay进行过滤
ordertype（以上已包含）
1、京东小程序话费充值：ordertype：37
2、京东小程序流量充值：ordertype：87
3、游戏点卡：ordertype：34
4、京喜话费：ordertype：109（通用充值平台统一）
sendpay：通用充值平台给业务订单154~156打特殊标识
1）pop话费：033；
2）京喜话费：036；
3）Q币充值：040；
5、慢充业务Brand：
69 ，70，71， 306（慢充分运营商和慢充全国）
6、京喜激活设备新（登录）-剔
（T+1）
- 1、应用于：识别该用户是否采用设备新
【定义：历史没有京喜APP访问记录（离线T+1）的用户，则为新用户，用户标识为设备号ID
关键动作：历史上没有登录】
- 2、接口： 【接入指南】京喜APP激活设备新用户
-
3、应用说明：传入deviceid来查看是否有Redis缓存（value是否有作弊标识），无缓存则查询Hbase业务关键日志流水（是否有作弊标识）——来判断是否是京喜激活设备新
7、非京喜App订单-剔
- 1、应用于：识别是京喜App的订单
- 2、应用说明：sendPay （236=3）为京喜App的订单
8、同用户参与任务奖励上线-剔
- 1、应用于：针对同个团长，参与任务奖励上线识别
- 2、应用说明：同一个subUnionId参与任务奖励上限 ，超过部分则不奖励 （以结算日当日进行统计剔除）
9、非京喜新-剔
10、访问超时
- 无接口，业务逻辑计算
- 访问时间+24小时<当前服务器时间，则剔除打表（该剔是纯用户维度，需要和扫码的用户团长关联入表）
11、离线风控（设备）
方案1：
- 1、应用于：识别该用户是否采用设备新（不用） 和 设备是否有作弊（采用）
- 2、接口： 【接入指南】京喜APP激活设备新用户
-
3、应用说明：传入deviceid来查看是否有Redis缓存（value是否有作弊标识），无缓存则查询Hbase业务关键日志流水（是否有作弊标识）——仅用来判断是否有作弊标识
- 4、调用节点：付款成功后，隔天调用一遍
- 备注：底层采用的是火眼的离线风控表
方案2：
数据组拿火眼离线风控表app_jx_jxapp_activation_base_mid_d，申请权限查看权限，然后做出服务能力，输出给业务研发使用
入参：设备标识
出参：是否被风控
注释：该设备标识用户登录App的时候会生成，但是用户卸载App后重新安装，设备标识会变；
方案3：
数据组拿火眼离线风控表app_jx_jxapp_activation_base_mid_d，申请权限查看权限，把表并入
【接入指南】京喜APP激活设备新用户；输出给业务研发使用
其他：
调用RCS时上次“设备指纹”
1、
【风控网关】接入文档
2、
设备指纹能力
场景：识别同个客户端是否变更 手机号重新注册来领奖
应用：
1、关于RCS风控，入参XX的场景值后，把前端获取到的eid在调综合网关场景741的时候，传到mapMapExInfo['finger_info']里
2、研发需要自行建表：设备是否重复；且该表什么时候清除或者不引用（比如：任务结束、每日）；
eid
|
PIN
|
time
|
| abc |
jd_1 |
22/5/18 11：47 |
| abc |
jd_2 |
22/5/18 11：57 |
设别到后，ja_2,采用弹框温馨提示，或者奖励兜底奖项
缺点：——拿到设备指纹信息后，结束流程，适用于一定要拿到设备指纹的场景，缺点是需要等上报完成才能进入下一环节，等待时间长（1S）
备注：eid根据风控的说法，是普通的客户端卸载重装，不会导致eid变化；
