offer入库筛选吐单逻辑

offer训练（sdk/inapp量）

移除

offer评分数据累积：cvr ecpc cap

pkg+countrys+aff=唯一一条广告=offer id

无效次数阈值

通过这紫色区域部分累积数据标签

旧广告库刷新比对

有效offer库

广告定义

缓冲池/稳定性

人工上下游关系／白名单

开发者放量

Y

价格波动的在缓冲池1-2个小时不能超过4个小时上显现频次不能超过3次（自定义）

联通率/跳转层级检测

不联通：服务器批量跳，服务模拟点击跳转+人工（跳转工具）联通的：1）http解析技术，大部分联盟用的方式。2）js调用跳转。 3）a包跳 b. 4)多层展示 中间层，最后一层跳转到另一个包名上联通率是最关键的：一定要挂着vpn去点，并且记录时间记录日志

1.vps监测跳转成功率（包名匹配&跳转成功率）2.记录稳定性（标签）跳转层级域名级 3-4次以上加黑

客户端监测jumpbreak

cpc*跳转层级系数*offer评分cap低于50不吐单（webeye）吐 top 100-200给下游（每2小时更新一次

对于open cap的切分算法4：3：2：1

主要问题：单子和流量不匹配：（ecpm对placement的匹配）1.cr低：一种是触发的点击，基本上只要触发就会发生激活，CR非常高（mtti短）；一种就是预点击，CR非常低（MTTI长），两种配合，加上实时监控真量，去控制CR就好了2.tti：客户端优化为主解决一定占比；另一种就是掺量3ip：没解决（服务端没查到，开发者反馈正常）-当前人工来

sdk吐单（ecpm排）

服务端监测（vps)

offer筛选

offer：机器根据平均值或动态分布淘汰去重：上下游串单去重，不同来源价格去重

offer抓取

offer训练联盟量（ecpc）

排序吐单（ecpc）

原始广告库

offer筛选和吐单

1. 下游回传子渠道2. 流量标签，针对渠道级别，便于运营优化

有效性

新老广告过滤

通过真实流量累积数据算法可用的标签

黑名单规则，在24小时后重开（自定义）

N

下发流量

新广告

api:参数；pkg pkgcountrysadURLpriceofferId/campaign id

展示-点击-转化情况（量和阈值自定）1.每个campaipn /offer 给定量的展示/点击机会（1个ip一天5次就不展示了）系统算个cvr的标准值，低于过滤掉，过高也过滤掉2.对于cvr2-5%的campaign 给一定的次展示/点击，然后按照ecpm排序3.测试控量和日志记录：（客户端记录日志，时间／cvr等日志，一个广告展在一个ip用户展示5次不再展示（阈值自己控制）4. 客户端的信息收集：日志记录

geo+包名我们是一个offerid

拉取3-5次（自定义）每次隔1-2小时（自定义）

无效广告库

过滤和去重为算法一部分2. pakg-数量（去重新增），3. ADID数量 -新增包名数纯广告去重4. 直客数量5. 高价异常广告

下游放量

1.有些大的上游leadblot youappi 等不能用vpn只能sdk，（sdk我们国家不全）2.主要是联通率测试的时间戳要记录

质量反馈问题处理

广告\bID(唯一）

1. 联通率：(评分）6.跳转层级（联盟）

1. jump记录数据，跳转成功率和跳转层级2 offer 评分数据积累：广告数据 cvr ecpm