1.carrier数据会有一个group_id
mysql> select * from afrtb_carrier where name like ‘%China mobile%’;
+—–+————–+——-+————+————–+———-+
| id | name | code | country_id | brand | group_id |
+—–+————–+——-+————+————–+———-+
| 255 | China Mobile | 46000 | 45 | China Mobile | 201 |
| 257 | China Mobile | 46002 | 45 | China Mobile | 201 |
| 261 | China Mobile | 46007 | 45 | China Mobile | 201 |
对于以上数据情况,统一个国家下面会有name相同的carrier,因为他们的code不一样,所以这些carrier确实是不同的,这样如果在前端直接显示的话,会出现同一个国家下面有相同name的carrier,所以新增加一个group_id,同一个country下面,name相同的carrier,他们的group_id相同.
在dsp系统中,后端和web的交互完全使用group_id,脚本和rtb的交互则会把group_id转成code
2.给PM做的小工具
这两个工具的代码不再master,在分支liuke_dev上,前端是自己写的,没用到大师他们那些逻辑
前端代码:
后端代码:
1.上传inventory(http://pre3.papayamobile.com:9082/price.html)
功能如下
2.查看campaign的targeting信息(http://pre3.papayamobile.com:9082/monitor_campaign.html)
功能如下:
3.同步脚本部分
以下几个是会加到crontab中执行的任务
1. sync() (scripts/sync_data.py)
同步campaign信息,目前是5分钟执行一次
生成campaign同步信息的过程:
1.排除过期的
2.排除没钱的
3.排除超daily budget的
4.placement budget的控制在xuedong那儿控制
check_campaign_expired()
# 根据campaign的start_time和end_time信息判断campaign的status是否应该为STATUS_EXPIRED或者STATUS_ACTIVE
real_time_check_account_points()
# 根据account快照中的points信息,实时先判断account是否有钱
real_time_check_campaign_daily_budget()
# 根据RTB_CAMPAIGN_DAILY_SPEND_KEY判断是否超daily budget
2. sync_account_points() (scripts/sync_data.py)
每天零点同步account的points信息给xuedong,相当于是account的每天的快照,每天只能执行一次
3. rtb_bid_tansfer_points() (scripts/dsp_transfer_old.py)
目前的扣费逻辑,5分钟执行一次,在咱们这边切换扣费表和扣费逻辑完成后,这个脚本就可以停掉了
4. transfer_points() (scripts/dsp_transfer_new.py)
新的扣费逻辑,上线后可以每两分钟执行一次,因为是逐条扣费,所以如果每两分钟的扣费记录比较多的话,这个脚本的扣费时间就会长