V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
awanganddong
V2EX  ›  程序员

关于广告 rtb 竞价请求响应问题

  •  
  •   awanganddong · 2020-04-13 17:11:58 +08:00 · 1580 次点击
    这是一个创建于 1499 天前的主题,其中的信息可能已经有所发展或是发生改变。

    用户打开集成了 SSP 的 SDK 的 App,广告即将被展示但是还未展示时; SDK 会将用户的一些信息(例如 imei,app 名称,广告位信息等)上报; SSP 收到自己 SDK 上报的这些信息,然后向和 SSP 对接的 ADX 发起 Bid Request ; ADX 会将此 Bid Request 发送给所有和此渠道对接的 DSP 上,要求 DSP 对此次展示进行出价; DSP 收到 Bid Request 后会先拿到 SSP 通过 ADX 传递过来的数据( imei,app 信息等) 然后利用这些信息在 DMP 中进行匹配,如果符合投放要求,则进行出价,向 SSP 发送 Bid Response,此 Bid Response 会携带广告主要投放的物料信息;如不符合要求,则不参与出价; 此时 ADX 会收到来自各 DSP 的出价信息,若到达规定时间内有 DSP 没有返回 Bid Response,则视为不参与竞价。 ADX 对此次出价的 DSP 进行竞价,选出出价最高者视为竞价成功的 DSP,通常情况下,此 DSP 只需支付第二高的价格即可(规则可调,会影响到收益); ADX 将竞价成功的 DSP 的物料信息等返回给 SSP ; SSP 将物料信息(例如一个广告图片的 url )下发给 SDK,此时 APP 展示广告; SSP 向胜利的 DSP 发送 Win Notice,通知 DSP 该次 Impression 已经竞价成功 至此 RTB 交易结束。

    作者:夜_雪 链接: https://www.jianshu.com/p/aa9a3371d598

    这是网上找的 rtb 竞价流程。就是 ssp 发送请求给 adx,然后 adx 把 ssp 发送请求转发给众多 dsp,然后 dsp 竞价, 返回竞价成功的物料。返回给 ssp 。

    我比较困惑的是,这之间是一个请求响应还是两个请求响应。

    如果是一个请求响应的话,adx 转发给 dsp 这里不理解。

    15 条回复    2020-04-23 13:44:57 +08:00
    yumenawei
        1
    yumenawei  
       2020-04-13 17:39:10 +08:00
    多个请求。
    ssp 请求 adx 这是一个请求,这个地方会阻塞住直到 adx 获取到广告返回或者所有 dsp 都超时。
    adx 会像每个 dsp 都发送一个请求去请求广告,每个 dsp 的请求都是一次独立的请求。
    “然后 adx 把 ssp 发送请求转发给众多 dsp,然后 dsp 竞价”,这句话里的请求更多的是指请求的参数,imei 和 app 信息 这些东西,并不是真正的把那个请求转发。
    awanganddong
        2
    awanganddong  
    OP
       2020-04-13 18:25:47 +08:00
    @yumenawei 我后台语言 php

    ssp 发起请求,在本次请求中,设置唯一标识,将本次请求写入 redis list 中。然后在代码中用 usleep()设置延迟毫秒数。

    另外我起个守护进程,对 redis 的 list 进行消费。curl 多线程请求 dsp 接口,获取最高价 dsp,并将其存入 redis 中。然后 usleep 执行结束,获取 redis 的值。返回给 ssp 响应。

    这个流程,你觉得存在什么问题吗?
    yumenawei
        3
    yumenawei  
       2020-04-13 18:36:09 +08:00   ❤️ 1
    是可以满足需求的,但是这样做合理吗?
    为啥要引入一个 redis 呢?感觉增加了实现的难度。万一守护进程挂掉,没有人消费怎么办?
    ssp 请求 adx,等待 adx 返回结果。adx 去 dsp 请求广告,拿到广告到给 ssp 返回。
    整个流程是一个同步请求的过程,不需要异步去操作。
    广告系统对时延要求较高,如果有结果应该立即返回给 sdk,而不是还要等一个延迟周期。
    awanganddong
        4
    awanganddong  
    OP
       2020-04-13 18:42:18 +08:00
    @yumenawei 我明白你的意思,我把问题想复杂了。
    awanganddong
        5
    awanganddong  
    OP
       2020-04-14 16:53:09 +08:00
    @yumenawei 再请教个问题,adx 中,ssp 设置有浏量策略,也就是对 dsp 数据过滤的一些条件,那我是需要把这些数据传给各个 dsp 平台,然后各 dsp 筛选出适合广告数据的吧。
    yumenawei
        6
    yumenawei  
       2020-04-14 19:29:32 +08:00
    @awanganddong #5 浏量策略 具体是哪些策略?如果 adx 能处理,就处理了,把调控策略可以掌握在自己手里。
    如果 adx 处理不了,这个可能需要和 dsp 协商
    awanganddong
        7
    awanganddong  
    OP
       2020-04-15 10:04:55 +08:00
    @yumenawe 就是采用你现在说的逻辑,就像广告方面的业务,有推荐的书吗?
    yumenawei
        8
    yumenawei  
       2020-04-15 13:21:48 +08:00
    @awanganddong #7 印象里只有一本,计算广告。
    awanganddong
        9
    awanganddong  
    OP
       2020-04-15 13:44:52 +08:00
    这本书我看了,算是给一个思路吧。剩下就是自己摸索了
    awanganddong
        10
    awanganddong  
    OP
       2020-04-15 18:25:13 +08:00
    @yumenawei 又要请教个问题,最后竞价成功,win_notice 和用户浏览和点击的问题。

    win_notice 是直接由 ssp 发送给 dsp 。不经过 adx 。(这里为什么不通过 adx 呢)
    用户点击和浏览 是 ssp 请求 adx,然后 adx 转发给 dsp 。
    yumenawei
        11
    yumenawei  
       2020-04-15 18:35:24 +08:00
    @awanganddong #10 adx 的一些细节没太了解过。这个问题没法准确回答,我猜是因为 ssp 会有过滤逻辑,在 adx 胜出的广告,不一定能过 ssp 这一关。
    用户点击和浏览 这是广告的打点流程,不涉及 ssp 和 adx 了呀
    awanganddong
        12
    awanganddong  
    OP
       2020-04-15 18:54:01 +08:00
    瞬间清晰了许多。
    awanganddong
        13
    awanganddong  
    OP
       2020-04-21 11:07:27 +08:00
    @yumenawei dsp 平台扣费分为 cpm 与 cpc,ssp 那里扣费是 cpm 。这两者之间关于费用扣减我应该是有误区的
    yumenawei
        14
    yumenawei  
       2020-04-23 12:12:34 +08:00
    @awanganddong #13 ssp 和 dsp 都属于广告的下发线,而扣费更多的是关于打点线。
    awanganddong
        15
    awanganddong  
    OP
       2020-04-23 13:44:57 +08:00
    不太理解
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2270 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 15:39 · PVG 23:39 · LAX 08:39 · JFK 11:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.