程序化广告的未来

前一阵看到一句话:Programmatic is eating the media world,意思就是程序化广告正在吞噬媒体的世界。 程序化广告这些年发展很快,人们都看到了程序化对传统媒体售卖方式吞噬,不少人却忽略了程序化广告本身也在剧烈变化之中,很可能再过5年后的程序化广告和现在又大不一样了。

下面畅想下程序化广告的未来:

  1. 媒体端的改变
    会有更多的传统媒体也开始用程序化来售卖广告。比如电视,广播,户外广告,楼宇广告,甚至高速路上的路边广告, 电影的片前广告都会程序化。 这些还都算传统媒体,将来一定会有针对程序化广告的媒体创新, 会有不少崭新的广告媒体出现。
  2. 广告形式的改变
    将来的广告应该不只是一个文字,图片,视频,他应该是交互的,不只是用户与广告的交互,应该是用户之间,用户与广告间,多方的互动。
  3. 广告购买方式的改变
    将来市场应该会有越来越多小的广告主。比如我们附近的小餐厅,可以花几百块钱, 在某个广告购买平台上开账号,在方圆500米以内投放各种媒体广告。
  4. 广告业态的变化
    第三点提到会有越来越多的小广告主, 他们会是各地小广告公司的服务对象。 地方的小广告公司将摆脱地域的限制,可以为广告主在线上直接购买全国,乃至世界范围的优质广告资源。现在不少DSP养着不小的销售队伍,私以为这应该不是未来的方向。 未来大大小小的广告公司会承担这些销售工作, DSP则需要回归初心,专心搭建高效的媒体购买平台。
  5. 统一的媒体采购平台
    将来应该会出现,能采购各种媒体流量的平台,也就是媒体采购的淘宝。甚至是程序化广告业的各种服务,都可以在这里实现一站购买。 这不表示DSP的消亡,众多DSP会是这个市场上媒体购买服务的卖家。
  6. 媒体的价值会更透明
    随着程序化广告的推进,数据的越来越透明,不同的媒体是什么样的受众,适合什么样的人群,价值几何,也都会越来越透明。
  7. 线上线下数据打通
    打通已有客户及线上潜在客户的数据, 用线下数据指导线上的广告投放,反过来用线上数据再指导线下的活动。这个市场会有超越传统CRM概念的系统出现,可能会产生远超SalesForce的巨头。

上面这些展望都是蜻蜓点水,没有展开,每个点展开了都要长篇大论。谁要是感兴趣欢迎一起讨论。

也谈Header Bidding

前几天看到曾宪超和北冥一起合写的《Header Bidding:程序化交易的一股泥石流》(下面简称泥文),受益匪浅。下面有自己的一些思考及疑问,提出来供大家一起讨论。

  1. Ad Exchange在进行RTB竞价时,给DSP的时间很有限,大多在100 – 300ms范围。而在客户端竞价时,这个时间范围相对会较宽,这样能参加竞价的将不只是DSP,Adx也可以直接参与竞价,这对提高填充和收益也是会有帮助的。
  2. 泥文中提到HB会引起高延时。这个有些疑问,用JS的异步调用,可以做到近似并行的效果,请求10个买家和请求1家的时间差异应该不会太大。 而且HB模式减少了ADX的中间环节,照道理总时长应该能得到缩短才对。
  3. 除了有自己adx的大媒体外,其实还有很多没有自有广告系统的中小媒体,对这些媒体来说HB能带给他们的好处是实实在在的。泥文不看好HB在国内的将来是基于大媒体的角度出发,难道中小媒体中也会没有市场么?
  4. HB在移动端App的变现上优势更明显
    现在很多App的变现是通过聚合,通过瀑布模式调用各广告提供方来提高填充和收益。这有如下2个弊端

    1. 延时非常长,因为要串行调用多个广告提供方,有时获得一个填充甚至需要10秒以上。
      而HB方式是并行向广告买家发起竞价请求,能大幅节约时间。
    2. 瀑布方式的调用明显没有竞价的收益更好。瀑布模式只能根据历史ecpm,填充率,点击率等信息决定具体的调用次序,来尽量最大化收益。
      而HB的竞价模式能保证每次的请求都得到了收益的最大化。

现在移动端流量已经超过桌面端,HB相对于聚合的巨大优势是很有可能会让它成为改变广告市场的重要因素。 泥文提到欧美市场有公司因为没能及时拥抱HB而造成暴跌,中国会不会也发生这一幕呢?

库不齐沙漠徒步小结

刚刚和公司的小伙伴们一起在库不齐沙漠度过了开心的两天, 徒步穿越了库不齐沙漠。 全司分成了7个组, 组之间展开了激烈的竞争。 我们第七组(队名『蓝色闪电』)第一天成绩不理想,排名倒数。 第二天则以较大优势获得第一。 能在一天时间内实现大逆转, 我们自己也是颇感意外,因为主要竞争对手第四组只有一个女生,还是个有户外经验的女汉子, 其他也都是年轻猛男。 而我们组,则近一半是没有户外经验的女生, 其他男生有户外经验的也较少。后来居然成为了第一,还优势相当大。回来路上想了半天原因,记录如下:
  1. 正确的战略
    第一天成绩不佳后,我们第二天早晨就根据前一天的观察,总结经验,确立了要保持自己的节奏,保持紧凑队形的策略。在整个过程中节奏和队形保持的非常好,第一名到最后一名的距离也就10分钟左右的路程。
  2. 战术执行
    确定了策略后, 我们将策略细化到了很多的执行细节里:

    1. 第二天早晨出发前,男生们就已经帮女生大量减负,大部分女生只背一瓶水
    2. 每到一个休息点,大家集合整齐再一起出发
    3. 我们发现先出发的队伍在沙漠里更容易保持队形,所以在休息点时我们非常注意距离前进方向较近的地方休息,教练一动我们就立刻跟着出发。
    4. 对一些同学登山杖的用法进行了调整,收到了较好的效果
  3. 抓住机会超越对手
    在最后一程,我们组拖后的三个人,和前面组员间,隔着主要竞争对手:四组的7-8个人。 当时我组三人非常累,但四组的人也是很疲惫的感觉。 我们三个抓住翻过一个沙坡后一段较平坦的路的机会, 一起咬牙加速, 终于超越了四组的主力部队,在爬下一个沙坡前抢占了有利位置,一举拉大了与四组的差距。 —— 竞争的时候一旦机会出现,一定要立刻抓住,你觉得难,别人也难。狭路相逢,勇者胜。
  4. 团队
    最重要的原因是,我们七组是个特别棒的团队,互相之间不断的肯定与鼓励。每个人的努力与坚持,又激励着队伍中的其他人奋勇前行。
后记:得第一的感觉确实很兴奋,但这种兴奋很快就过去了。而和同伴们一起同心协力,穿过茫茫沙海,冲向终点的整个过程,则成为了特别温暖的美好记忆,相信每个蓝色闪电的组员都将把这两天永远珍藏。
库不齐沙漠 - 蓝色闪电

发起个珠海IT人的交流聚会

缘起

刚来珠海的时候,就痛感珠海IT业交流太少。后来在Dell工作的时候,曾经组织过公司范围内的Programming Club, 组织些分享交流活动。后来找到Zoom.Quiet 组织的GDG活动,也参加过开源中国组织的活动,活动都不错,但感觉还不够,没有把大家联系起来。年初看了一本《城市的胜利》, 里头提到,城市中一些文化或技术上的发展,需要把相关的人才聚集到一起,产生高频次的交流 。看到这段很给我触动,珠海的IT业间的交流频次太低了。 于是想发起一个珠海IT人员的交流组织,让大家比较方便的交流,分享,讨论。

主题

开始也想过是否要确定一个技术主题,但想来想去不希望限制大家。 只要是大家感兴趣的技术,大家都可以讨论分享。甚至非技术的,比如创业之类大家也可以一起讨论。发起前对这个组织要做什么,有如下几个想法:
  1. 大家之间互相交流分享,互相帮助,让大家共同成长
  2. 追踪世界前沿技术
  3. 推动珠海IT业界技术水平的提高
  4. 对接技术人员的群体,与创业企业,为双方创造机会
    曾遇到几个珠海创业公司抱怨珠海找不到优秀的技术人员,但又遇到不少技术好手抱怨珠海缺乏机会,纷纷去北上广深去追求理想。需要有人去为双方搭起沟通及建立互信的渠道,大家可以一起来做这件事。
这些算是抛砖引玉。到时大家再讨论。

名字

开头想过不少名字, 后来看到个英语新闻,谈到珠江三角洲Pearl River Delta。 看到最后的Delta想起自己当年酷爱的游戏:Delta Force(三角洲特种兵)。提出这个名字后,另一个朋友也觉得不错,就定下它了。 希望大家能成为珠江三角洲的IT特种兵,成为IT界的战神:)。

组织机制

10来年前参加的阳光志愿者给了很大启发。阳光是主席选举制,每个主席和领导层都是任职半年,一般不连任。由主席和领导层来一起决定组织事务。组织成立不到一年,创始人就退出,十来年过去,当年创始的元老基本都忙着生孩子养孩子很少参加活动,都属基本退出的状态,但这个组织一直发展的很好。 后来思考其中的原因,就是这个组织的机制比较好。后来的Toastmaster 俱乐部也给了很多类似的启发。
希望成立的这个交流组织,能摆脱对个别人的依赖,能自发的成长。具体怎么做大家讨论着来,还没确定前,我先来牵头。

工具

 交流的工具里QQ和微信群感觉太口水化, 而论坛则没有跟上移动互联网的时代,效率低。工作中用Slack体验很不错,国内访问有时不太稳定,但优点太多, 就先用它了。组名deltaforce-cn, 链接是 https://deltaforce-cn.slack.com/。 Slack的桌面,iOS和Android客户端都有,用网页版的也行。

活动形式

想线上,线下相结合, 先每个季度组织一次线下活动,让大家能互相认识下。 当然如果有人想在上面发起自己的交流活动,也很欢迎。任何能促进大家交流的事情,都乐观其成。 其他非技术活动只要大家乐意也可以组织,我自己就很想凑一帮程序员去踢足球,或远足,骑车。

报名参加

任何对技术交流感兴趣的IT从业人员都欢迎参加, 请向cuiyingjie+gmail.com 发申请,内容需要包括:

  1. 自己登陆slack的email地址
  2. 想分享什么内容
  3. 如果有Github账号, blog地址更佳

欢迎大家来一起交流。

 

RTB广告平台价格结算机制

RTB广告平台价格结算机制有多种,常见的有GFP, GSP, VCG等。 已经有很多人写过很好的文章介绍这些机制的优劣,就不重复了,想了解的请参看如下文章:

  1. 互联网广告拍卖机制设计
  2. 谈谈广告平台的竞价原理:GFP,GSP,VCG

下面谈谈其他相关问题。

  1. GSP的变体
    GSP有不少变体,其中常用的有UWR和QWR。

    1. UWR – Unweighted reserve price
      指定一个最低门槛价格,也就是底价,该价格对所有竞价者都相同,竞价者的竞价必须大于等于底价。Google,Baidu, 玉米AdExchange用的都是这种方法。
    2. QWR – Quality reserve price
      也是指定一个底价,但这个底价对不同竞价者是存在差异的,根据他们的广告质量(点击率,转化率等)指定不同底价,从而最大化媒体方的收益。
  2. 底价
    制定底价的方法也有多种。

    1. 双底价
      最早就是一个底价。 现在出现了两个底价的模式:一个是软底价(soft floor price),一个是硬底价(hard floor price), 硬底价低于软底价。 竞价者的出价必须高过或等于硬底价。 当出价高于软底价时, 结算方法为GSP,就是价高者得,而结算价格为第二高位出价加1分。 当出价低于软底价,而高过硬底价时, 结算方法转为GFP,也是价高者得,结算价格就是出价。
    2. 动态底价(dynamic floor price)
      根据流量的不同特征,不同的时段,给予不同的底价, 从而最大化媒体收益。
  3. 纳什均衡
    设计出价机制时很重要是尽量让系统得到纳什均衡,纳什均衡的定义是在非合作类博弈中,如果参与者当前选择的策略形成了“纳什均衡”,那么对于任何一位参与者来说,单方更改自己的策略不会带来任何好处。
    GFP模式就不可能达到纳什均衡,他会鼓励竞价者不断的调整自己的出价。

RTB是一个很好的游戏规则,能优化资源使用效率,实现买家卖家的双赢。而在RTB这个大规则下还有很多的小规则,例如上面谈的结算机制,底价设定方法。这些小规则的设计和选择很重要,决定了广告交易平台以后的走向。

本人正带队开发玉米AdExchange,有感兴趣计算广告技术方面的朋友欢迎交流。

纪念麦教主

惊闻共享届我很钦佩的麦教主6日因红斑狼疮不治,终年三十八。葬礼于周二下午两点 上海宝山殡仪馆举行。
麦教主其实不姓麦,他的在共享圈用的id是magic2003,后来他的麦吉减肥法在共享圈广为传播后大家就都叫他麦教主,原先的id倒没人记得了。
麦教主很热爱分享,他自己创造出来的麦吉减肥法无偿分享给共享圈的朋友数年。他还很爱琢磨翻墙技术,琢磨出来也不藏私,而是分享给大家。
当年从他分享的减肥法和他分享的翻墙技术里我都受益匪浅。尤其是他的麦吉减肥法,让自己学会了如何成为身体的主人,可以说他是少数对我人生产生过重大影响的人之一。
第一次见他的时候,发现一点都不像程序员,很有派头,吸烟用很雅致的一个烟嘴。
他的麦吉减肥法后来出了app,长时间是健康类排行第一,下面的图就是app中麦教主自己的照片。这个app大部分是五星好评,用过麦吉减肥法的都知道这些评论不是虚言。
在去北京出差的路上惊闻噩耗,在动车上敲下这些文字来纪念麦教主,祝他一路走好。

 

2016.5.15更新:

不少朋友都写了文字怀念麦教主(本名陶辰),才知道他远比我知道的更强大,很多事从来没听他提起过,遗憾没能和他学到更多。表格也写了文字,更全面些:https://www.xiaohui.com/weekly/magic2003.htm 。教主走好。

Python老兵的新征程

用Python已经有近9年了, 大多数时候都是用它来做些内部使用的小工具,写的都比较随意(唯一的正式项目经历,就是写一个用户评论搜索引擎,那个网站已经关闭了,当年的页面可在archive.org看到)。 做这些开发时,开发的方法思路其实和十来年前没啥差别,当然有了些更好的辅助工具,例如Git,Pycharm等, 但主要方法没啥大变化。 这周用Python做另一个正式项目,尝试采用了和以前都不一样的方法,通过这一个星期学习到了不少新东西。

  1. pyenv来管理python的不同版本,
    因为项目用了Python 3.5, 而系统是Python 2.7
  2. 用了Python 3.5的Type Hints
  3. PyScaffold初始化了项目
    以前也用Django来生成过web项目,但非web项目还是第一次用生成器生成。
  4. commitizen来写git commit message, 这样能够用cz-conventional-changelog自动生成change log
  5. pylintflake8做代码检查
  6. tox做测试
  7. 在Git pre commit hook中加入pylint,flake8,tox检查
  8. SQLAlchemy来做ORM, 用Alembic做数据库的版本升级管理
    以前都是直接写SQL -_-;,当然是参数化的。 这次先用phpMyAdmin直接在mysql上设计数据表,然后用sqlacodegen生成model代码,再用Alembic做版本管理。
  9. Travis做系统集成
  10. pip做依赖管理
    1. 用pip freeze > requirements.txt 来记录依赖
    2. 再用pip install -r requirements.txt来重建依赖环境
    3. 正在研究virtualenv以实现依赖的隔离
    4. 另:以前研究过Docker,遇到些问题没能搞定,有经验的还请指点一二
  11. Slack集成
    现在已经能从Slack里看到Github的提交,Pull request提醒,并能看到Travis持续进程测试结果。上线时还要实现从聊天频道里直接下指令部署。

感觉现在开发的思想,哲学都比起20年前,甚至比起10年前都有了根本的改变,我们正迎来程序开发上的工业革命,生为这个时代的程序员是何其的幸福啊 :)。

高效会议的12个准则

工作中经常开会,开出了些心得,总结出开高效会议的12个准则,分成会前,会中,会后:

  1. 会前
    1. 明确会议目标
      要明确如下几个问题,并提前让所有参会者知道。 如果很多参会者都不清楚会议的目标是什么,那注定是个失败的会议。

      1. 会议要讨论什么问题
      2. 会议要有什么样的产出
        是要形成决议,还是要有行动计划,还是仅仅是为了互相沟通
    2. 只邀请必须的人参会
      什么是必须的人,就是需要做出关键决定,必须提供实时关键意见的人。
      下列的人则尽量不要邀请, 而只要把会议纪要抄送给他们参考即可

      1. 只需要知道会议结果的人
      2. 只是提供一些资料的人
        可提前和他们询问相关信息,资料,而不需要邀请参会
    3. 提前发出邀请,最好是提前一天以上
      很多人在会议上发表意见以前需要有个思考,准备的过程,才能给出深思熟虑的意见。 如果是会议开始前1分钟把他拽过来, 往往给不出太多有价值的想法,降低会议效率和价值
    4. 制定会议议程,明确会议时间,会议主持人(默认为会议邀请的发出者)
      制定出会议讨论的时间表, 将整个会议目标拆解成一个个小步骤,确定总的会议时间,并在邀请参会人员时就要发送给他。
    5. 一些关键问题可提前沟通
      有些关键问题是和某个参会人员相关,而和其他人无关, 这类问题最好在参会前和该人员提前私下沟通,节约大家时间。
    6. 参会人员需要提前准备
      上面的几个建议都是给会议组织者的,这一条是给参会者的。 参会人员需要根据会议组织者发送过来的会议邀请中说的会议目标及详细议程,提前准备资料和自己要发表的意见。 如果没有重要意见可发表,可考虑向会议组织者提出不参加。如果会议中发现会议和自己关系不大,或者自己意见已充分表达,自己也不是关键决定人,可提前退出会议。
  2. 会中
    1. 遵守会议议程
      按照议程一步步来,会议主持人要控制好以下三点

      1. 遇到跑题要及时拽回来,可反复强调会议目的
      2. 控制每个议程的时间,限制每个人的发言时间
      3. 让大家都有发表意见的机会
    2. 会议记录
      用电脑或笔记本都可以,把大家提出的重要意见,决议记录下来。
      做会议记录有两个问题要避免

      1. 一是记录太少,甚至没有
      2. 记录太细,每个发言都详细记录。 其实只要记录主要意见,决议即可,要注意提取每个人说的话背后的主题思想。
    3. 会议要明确产出
      1. 如果是为了沟通,要把大家达成的共识记录下来
      2. 如果是要达成行动计划,那要明确行动目标,责任人,完成时间点,完成标准,及中间的检查时间点和标准。
  3. 会后
    1. 及时发出会议纪要给大家
      除了每个参会人员要发送外,其他相关人员也要抄送。 达成的共识,计划等等,都要在纪要里明确,如果发出后大家没有意见提出,则大家就要按照这个纪要来执行。很重要的会议要先发给关键人员审核,没问题后再发给大家。
    2. 跟踪会议结果
      要在以后的工作中检查共识有否贯彻。会议达成的行动计划有否得到很好地执行,如果没有要督促相关责任人。
    3. 每次会议后都要总结
      每次会议后会议主持人要总结,以改进以后的会议,可围绕下面这些点来总结:

      1. 会议是否达到了目的
      2. 是否遵守了上面这些准则
      3. 是否有些人不必邀请或漏掉了一些该邀请的人
      4. 是否高效
      5. 怎么能开得更好一点
  4. 其他
    1. 会议中一些意外情况的处理
      1. 需要做关键决定的人员未能参会
        建议这种情况下取消会议,和该人员再约下次会议时间。 避免大家说半天,结果什么决定都做不了。
      2. 在会议中就一些问题的讨论形成僵持局面
        1. 如果问题不重要,就立刻做决定,不要浪费时间
        2. 如果问题很重要,形成僵持往往意味着缺少相关资料来充分的证明双方意见的优劣。如果资料能找到,就建议停止会议,明确找资料的责任人及时间,找到资料后约下次开会时间。 如果没有这种资料,在确保双方意见充分表达后,即终止无谓争论,迅速做决定。
    2. 工具
      可用工具来提高会议的效率

      1. 会议记录在网上有模板可循,大家可参照
      2. 可用Trello,Teambition 之类的工具来在会议后跟踪决议的执行情况

工作中看到的反面教材:

  1. 会议开始前几分钟通知人开会,人坐到会议室都不知道会议主题是什么,更不知道议程和要有什么产出。 甚至开会开到一半把人来进来参会,结果人家压根不知道之前的讨论,听得一头雾水。
  2. 邀请了一大堆不需要的人参会,但其实他们只是需要了解情况即可,结果大多数人在会场枯坐,玩手机
  3. 没有发出议程,大家都不清楚会议的目标,大家漫无目的讨论
  4. 会前没有找关键人员就一些关键问题提前沟通, 结果会议进行时发现重大分歧,大家看着两人争来争去。
  5. 会议后没有发出会议纪要,过几天这会议讨论了什么,做了什么决定早被人忘到九霄云外了
  6. 会议最后达成的决议没有明确责任人,完成时间点,完成标准,检查点等, 也缺乏追踪。 结果事情也就不了了之。
  7. 需要做决定时,没人敢拍板,结果开了很长时间会议什么决议都没达成

 

后注:

  1. 会议是成本很高的活动,无论是时间成本,还是耽误其他工作造成的机会成本。会议是必须的,但需要的是高效的会议,低效的会议宁可没有
  2. 这个准则是对面对面在一个会议室的会议,远程会议又不同,我还在摸索中。
  3. 抛砖引玉, 欢迎大家讨论