接手活动运营岗快一年,我习惯用施工日志的格式写周报。每场活动就是一个项目,立项是图纸,上线是浇筑,数据复盘是强度测试。下面把去年几场活动的底账摊开说,好的坏的都照实写。
先讲双十一那场会员储值卡。预热期我们做了短信召回,发给近30天有访问但没消费的人,50万条。活动上线两小时,后台报警:领券接口响应从80ms飙到4.5秒,支付成功率从68%掉到22%。用户反馈点“立即领取”白屏。技术排查发现短信短链带了个参数source=sms,前端根据这个参数播动画,动画脚本里有个死循环,低端安卓机直接卡死。更坑的是,测试全用的ios,老机型压根没跑。
我干了三件事。第一,切掉所有带该参数的入口,短信跳转落地页换成无动画基础版,12分钟。第二,正在跑的其他三个投放渠道紧急下线,查有没有同样问题。第三,拉数据按机型、系统版本、webview版本分组。结果触目惊心:android 9以下、webview版本低于72的设备,失败率83%。这类设备占短信渠道流量的17%,但贡献了35%的投诉量。修复后重新上线,同类设备失败率压到4%以下。但活动整体只卖了预期目标的63%。
后来我跟开发吵了一架。我说你们为什么不在真机云测平台跑一遍?他们说测试用例里没写。吵完我直接改sop:在验收标准第3.2条后加一项——所有带动态参数的活动入口,必须单独跑兼容性测试,覆盖用户占比前20的机型。执行人签完字才能上线。这条现在排在避坑清单第13位。
再说周年庆拼团。目标不是拉新,是唤醒沉睡超90天的老用户。设计了一个三人团,团长必须是沉睡用户,团员不限新老。实物礼品成本控制每人8元。上线第一天,开团127个,成团率19%。大部分团开起来凑不够人。我拉出团长行为轨迹:他们收到短信进活动页、开团、分享到微信。从分享到第一个团员加入平均间隔4小时,超6小时未成团的占71%。用户耐心撑不过半天。
第一次改动:把分享文案从官方宣传语改成“帮我点一下,就差你了”,倒计时从24小时压到6小时。成团率涨到30%,还不够。我又跑了一次数据,把每个团从开团到成团的时间轴切成15分钟一段。发现两个峰值:开团后前15分钟,以及最后1小时。中间段几乎没人。这说明什么?团长分享完就忘了,需要提醒。
于是加自动提醒:开团后1小时未成团,系统给团长发服务号模板消息,附带“换一批好友”的快捷引导,点一下直接调起通讯录









