一起做网站怎么下单,常州市城投建设工程招标有限公司网站,时尚网站,无锡专业网站建设公司前言
名词解释
基础名词
订单金额#xff1a;用户下单时支付的金额#xff0c;这个最好理解
产品分成#xff1a;也就是跟其他人合做以后我方能分到的金额#xff0c;举个例子#xff0c;比如用户订单金额是 100 块#xff0c;我方的分成是 80%#xff0c;那么也就是…前言
名词解释
基础名词
订单金额用户下单时支付的金额这个最好理解
产品分成也就是跟其他人合做以后我方能分到的金额举个例子比如用户订单金额是 100 块我方的分成是 80%那么也就是我方能得到 80 块
联运商分成跟产品分成类似就是说我方还需要分去一部分的前给联运商比如广告商巨量快手等一般是不高的也就10%左右
综合例子订单金额 100 块产品分成 80%联运商分成10%那么最终我方得到的金额就是如下的计算公司 100 * 80 -10% 70 块
行业名词
LTV表示用户在时间段内的下单增长情况比如第1天下了100块第二天下了200块。然后去除以注册用户
ROI类似于LTV的算法只不过金额部分需要减去分成的情况也就是第1天70块第二天下了140块然后去除以消耗的金额
原有设计 原来的LTV和ROI是使用的同一张表格里面的金额存的是用户的真正金额获取LTV的时候就直接拿出来即可而在获取ROI的时候就是结合金额*分成比例提前算好入库的 也不能说这样有问题但是这种算法就只能适应分成比例不变的情况下
目前需求 之前由于分成比例是固定不变的但是现在ROI分成金额还需要增加微信、支付宝的分成而用户选择支付宝还是微信支付是人为不可控的因此需要把LTV和ROI拆开进行处理才能符合。
需要解决的问题 1. 拆开LTV和ROI逻辑不讲 2. 历史的LTV数据迁移看情况而地 3. 新的ROI表设计核心主要还是讲设计模式的运用
问题解决 首先算法如下可以看到还区分IOS和安卓以及切支付这里就不细说了主要讲设计思路 按不同维度统计的总充值*产品分成比例-联运商分成比例-支付宝/微信 安卓 按不同维度统计的总充值产品分成比例-联运商分成比例 iOS 按不同维度统计的总充值产品分成比例-支付宝/微信 iOS切支付 设计模式-策略模式使用
设计图如下 AbstractCostStrategy 抽象类//处理类型public abstract int getCode();protected abstract double doDeductCostAmount(OrderInfo orderInfo, DeductCostVo deductCostVo, double productDividedRatio, double finalDividedRatio, boolean applePay, boolean aliPay, boolean webPay);public double deductCostAmount(OrderInfo orderInfo, DeductCostVo deductCostVo, GameProduct gameProduct)AndroidCostStrategyImpl 安卓实现IOS实现类似Overridepublic int getCode() {return ProductSubTypeEnum.ANDROID.getCode();}Overridepublic double doDeductCostAmount(OrderInfo orderInfo, DeductCostVo deductCostVo, double productDividedRatio, double finalDividedRatio, boolean applePay, boolean aliPay, boolean webPay)CostStrategyComponent 对外暴漏类Resourceprivate ListAbstractCostStrategy abstractCostStrategyList;public AbstractCostStrategy getCostStrategy(GameProduct gameProduct) 主要是动态控制变化不写死public class DeductCostVo {//支付宝分成private double aliDivide;//微信分成private double webDivide;
}设计描述 其实关键在于AbstractCostStrategy的设计可以看到deductCostAmount是public的也就是对外使用的而通用的逻辑被放置在了这里而doDeductCostAmount是一个抽象的方法也就是子类需要实现的具体因安卓和IOS不同getCode就是子类来进行实现的 DeductCostVo的结构主要是为了不写死分成搞成可配置的 CostStrategyComponent主要是为了使用端不需要介入系统内部逻辑而设计的 这样其实就已经完成了设计到这里本来就已经完成了但是中途需求方又发生了变化需要根据每个具体的商户进行分成统计也就是说订单支付到哪个具体的商户号其实也是不定的那么DeductCostVo的数据就不能是全局配置了需要根据订单支付时的商户来找到对应的分成进行统计但是原有的设计是不是就废弃了其实并不是因为可以使用所以才有了如下的设计
