声明：所有内容均来源于商业PM大本营微信群的日常讨论，无任何立场，请自行判断正确性，并结合自身使用场景。
Q：请问你们把wrapper放client（SDK）上还是sever上呢？ 我们自己想放sever上，感觉更快，主要因为client（SDK）快做完了，再改比较麻烦。 但有人建议放client（SDK）上，理由是“非wrapper”那部分会更快，而且这样不会出现数据差异
A1：我觉得server更灵活，之前看的时候写的一个分析
wrapper的我暂时还没处理哈哈，第一期只做了inline
A2
我以前对接的小的视频媒体，记得都是用vast，放在client上
Q：请问有谁调研过视频广告默认静音/默认有声音 对VTR和用户体验的影响吗？
A1：我测过4周数据，CTR基本一致的，有声音的略低0.01，我测的是信息流里的视频卡片广告，供兄台参考下，还有其他的朋友有测过这个数据么或有相关经验。基本完全一致，但是非贴片场景的视频广告，多半是在信息流里，加载完突然放BGM总有点打扰用户，微信的朋友圈视频广告，也是静音的。还有系统处于静音广告页自动静音，系统没静音广告也没静音，所以做的ABtest也有局限性。最后还是静音了。
A2：我这是获取了一下系统的音量状态，到没做过ABtest，系统处于静音广告页自动静音，系统没静音广告也没静音。视频卡片我在录素材的时候直接剥离了音频，H5里面也设置了自动静音。最后参考了多家，决定直接静音
Q：AdMob 中介与 Open Bidding
Open Bidding 是 AdMob 正在测试并将于 2019 年推出的新功能，此项技术可提供在众多广告联盟中接入实时竞价优化，结合统一的后台报告为你呈现变现情况。具体操作步骤和技术支持，我们会在以后的文章中为大家作详细介绍。
这是我最近了解到的，admob会和某几个广告联盟合作，在admob open bidding中各个广告联盟一起出价，admob open bidding计算ecpm，并返回给媒体
A1：我朋友接了fb的fb bidding之后收入提高很多，不过需要跟fb客服联系才能开，现在貌似后台还没有自助入口
Q：admob的open bidding给我一个启发：一条流量链，一条资金链，有提高效率的空间，就有机会，不用拘泥于产品形态
而且只有admob自己是公正的open bidding业务才能起来，因为自己也有admob广告联盟，如果不公平每次竞价都是admob广告联盟胜出，那open bidding也做不起来
A1：admob自信啊，而且admob的确是有在他的mediation服务里做手脚的
在处理bidding时候，提高自己的返回比例，同mopub和admob在同等条件下ABtest发现，mopub的收入会比admob收入高一截，但中介配置和瀑布流配置是基本一致的，所以怀疑admob有偷吃。
Q：如果视频广告是preload的，那么，下面这个流程图里，在哪一步之后，视频广告开始播放呢？是SDK解析
A1：sdk解析-自动缓存视频到本地-开发者调用预加载（如果没有缓存会再次缓存）-校验视频H5完整性-回调开发者true-开发者调用show（展示）方法-sdk creat webview-渲染视频-播放这个一般性流程凑合够用
这个是H5的做法，native构造的话也差不多
感觉视频sdk，缓存那部分需要多投入精力…怎么样播放快，省流量，下载控制逻辑，缓存体积，缓存数量，覆盖，清除缓存好多逻辑…
而且fb和Google都不值得参考，人家用自己的视频源，YouTube和ins
A2：短视频SDK架构设计实践https://blog.csdn.net/dev_csdn/article/details/78683826
Q：信息流中，如果可见区域内出现两个可以播放的视频广告，我看某些平台定的是只播“后出的一个”，请问大家有研究过这里面的逻辑吗？以及有没有哪家是只播“先出的一个”？
A：一般都是后一个，而且不只是视频广告，视频feed也是这样。因为前一个已经播放过了。而且如果先出现的那个能够吸引用户，为什么用户还会上滑呢，上滑就说明第一个吸引不了用户
Q：请问宽高比4:3、16:9的信息流视频，常见尺寸一般是多少啊？ 竖版闪屏（开屏），常见尺寸一般是多少呢
A1：信息流尺寸，我们一般是限制比例就好，没有限制具体的像素。开屏是全屏的那种么
Q：开屏是全屏，以及另外一种（下方有横条放app自己的logo）。我开始也只是限制比例，不限制像素……但adx那边希望我给具体的宽、高
A2：这个请求时候实时获取不就好了。获取下屏幕尺寸，计算宽高，请求ADX，填充w和h信息。每个广告位，肯定配了比例。SDK在建立广告容器时候应该是根据配置的比例，开发者提供的坐标，屏幕尺寸建立，容器的宽高替换掉RTB请求的wh信息就好啦
其实实时获取宽高请求，bidrate不会很高，如果想要bidrate不错，对于SDK而言fill rate不错的话，定死一个尺寸像RTB请求就可以。例如9:16的统一用320*480请求。
其他比例去你们adx平台，查一下视频维度下，那个尺寸的eCPM/Bid rate最高，然后根据数据去定义请求宽高。
A3：最好有明确宽高要求，可以不唯一，但要有最低限制
Q：那16:9的横版视频，用哪个尺寸比较常见呢？480*320吗？
A3：1280*720 现在手机分辨率都很高了
A2：320*480给插屏用海外填充挺好的，16:9的1280*720清晰度肯定够了。你可以填个值测测填充率和ecpm；然后按照比例调一下，调到比较好的水平，清晰度也说得过去就行啊。
Q：第三世界的低端安卓机（那种中国卖800元人民币以下的）能到 1280*720px 吗？VAST把wrapper放client（SDK）上还是sever上做，我们仍然悬而未决……之前鬼佬建议放client（SDK）做，说这样更快，但我们感觉是放sever上更快啊……现在鬼佬们在休假，也拉不到人电话会议
A2：放server上有安全感算理由吗
Q：怎么理解呢？我们client（SDK）也是自己的啊……虽然手机是用户的
A2：比如万一出错啥的修复快…我喜欢把东西能放server的不放sdk。SDK得发版挺麻烦的，不过SDK理应会快。
Q：SDK理应会快？为啥？每次从用户手机上无线网络请求再返回……怎么会比我们server更快呢？
A4：SDK更快，因为不经过sever，放到sever就相当于sever为中转站才能到用户手里。SDK就是客户端层面的，你可以看看放server的速度符不符合要求
A2：主要是因为放在SDK解析，服务器压力小。从哥们的描述看他们请求应该是是SDK to SDK Server to ADX Server to RTB上游，response相反路径。不知道有没有SDK Server这一层，如果有的话无非是服务器解析还是SDK解析，个人意见是服务器解析，处理灵活。放SDK解析的好处是，解放服务器压力，请求频繁时处理足够快。
Q：我们的路径是自己的client（自己的SDK）→server→ADX→RTB 这样
A5：你说的adx是外部的公有adx吧？话说，你们自己的server部分做adx竞价吗？
A2：他们自己有RTB系统，他们自己的SDK Server发auction request给他们自己的ADX Server，ADXserver做竞价服务，返回vast广告给SDK server。他的问题是此时SDK server要解析vast吗，还是原封不动给SDK，SDK解析。理解正确吗？
我的建议是Server解析，理由是这样的：1.处理灵活，出问题不需发版；2.如果SDK解析，日后要增加非RTB源非Vast格式对接广告主的话，需要另外开发一套SDK to Server的交互协议，或者Server要做一次Vast封装再给SDK，非常麻烦。不如统一接口协议，server做好解析工作。
Q：server是自己的，ADX是外部的…
A2：哦哦还以为自己家里一站式
A4：自己的server做竞价吗？
Q：做。
对了，16:9 常见的是 1280x720p,
1、那在这个宽高比下，最小多少，能基本满足清晰度呢？
2、4:3下，常见的尺寸是多少呢？最小多少能基本满足清晰度呢？
A2：问一下大家有没有视频积分墙的，是怎么减小提前缓存的视频占用内存的体积的。
A5：减少缓存个数，降低视频大小，及时清理旧缓存
Q：视频广告播放打点字段，全部去重（只统计重播数量，但重播时的操作都不统计，因为重播又不多收客户钱），这样合适吗？
也就是说，上表里，除了“重播”统计一下数量，其他字段，都只看首播时的情况
A1：重播怎么定义的？
Q：用户手动重播，广告播完了，ta手动点一下，又开始播……这种人虽然少，但应该还是有的
A1：从逻辑上讲，重播看到完成四分之三，那总体指标就应该是四分之三嘛，不然多亏
播放完成四分之一
播放完成一半
播放完成四分之三
播放全部完成
点击
成功&失败
这是核心指标，只要某个用户达到一次就算1，而不只是算首播的
作为广告主，关心的是某个视频创意的核心指标，不会关心是首播还是重播的；作为DSP/ADX，关心的是某次视频曝光的核心指标，也不会关心是首播还是重播的。但是不知道DSP/ADX的结果返回时间限制。具体这方面的产品设计没做过，只是我浅见哈
A2：其实可以这样，在广告播放过程中不上报任何事件，所有上报积攒，用户关闭广告时，除了rewind事件，其他的去重，再打包上报所有事件就可以把核心指标只上报一次了。
A1：同意楼上
A3：去重和各种数据处理，还是后端做好，放客户端，会隐藏很多问题
Q：rewind事件怎么理解呀？比如哪些常见问题呢？
A2：rewind是vast标准事件的重放。但我在实际中没遇到过这个事件..可能很多广告主不在乎
Q：我vast都忘得差不多了 主要自己技术底子薄，短时记住的，很快就忘了……
A2：之前统计的vast打点列表，没考虑回放。
Q：最后几个为啥划了呢？
A2：我感觉统计的太多了，问了下我们一个大广告主，说后面几个不报行不。大广告主说没事，前面那些报了就行，后面的他们也没怎么分析，然后我就给技术说不用报了，后期再做..
Q：
现在像微博百度头条这些大媒体在发送bid request，应该都是同时发给直投平台和外部DSP吧，只是内部发送的字段信息会多些DMP的用户信息？
应该是先直投，之后才到RTB吧……
A：如果定位外部DSP只是填充，可能是先后。如果要让整体竞价环境更加激烈，提升ecpm，得平等竞价吧
Q：我现在要定关于“码率（bitrate）”划分逻辑。同一条广告，三方很可能会给我们三条视频，分别是“高、中、低”码率（bitrate）。码率（bitrate）越高，视频清晰度越高，文件越大，要占用用户更大的带宽。同时也要考虑手机配置的高低，按照手机配置的高低来分配码率，也更合理。请问你们设定的划分逻辑细节是怎么样的呢？
A1：根据用户使用场景，是否WiFi条件、网速和设备啥的。http://mobile.51cto.com/ahot-580908.htm看这部分的差网络处理
欢迎各位加入商业PM大本营微信群，曾经或现在是商业产品经理请点击公众号下方【联系我】加我微信进群，其余岗位暂不开放~~~
