简介《淘宝用户增长的51个技术策略》是一份来自阿里巴巴淘系技术部高嘉峻的实战分享PDF面向产品、运营及用户增长相关技术人员系统梳理了数据驱动增长的核心框架与落地方法。内容从用户增长公式切入拆解MAU构成随后逐一讲解智能投放、矩阵优势、拉承一体、长周期运营、平台提效以及数据为王共51个策略涵盖CPX/oCPX投放、离在线人群服务、抖音信息流个性化、小程序矩阵、完整拉承链路等具体实践并配有图表与流程说明适合需要搭建增长体系或优化现有策略的中高级从业者参考。资源包共1个PDF文件总大小9.32MB文件结构清晰。目前已有154人学习浏览对于希望快速理解淘宝用户增长技术策略的读者这份资料能提供高密度的方法论沉淀与可借鉴的执行思路。1. 用户增长不只是拉新先看懂那个公式做移动开发十年后转去做用户增长我第一件事不是追热点渠道而是把 PPT 首页那张MAtU MNU MNUt-1 * r MA(活跃)Ut-1 * (1 - λ)抄在本子上。原因很简单当时外部都在讲“拉新预算怎么分”但真正决定月活大盘的是新增、召回、留存三件事同时做功。新增帮盘子扩容召回把沉默用户拖回来留存和唤醒让活跃基数越来越大。这三块对应到技术侧就是智能投放、矩阵触达、长周期运营和平台承接连成一体的系统设计。伯灵这篇分享在开头就说“技术策略不具备参考意义但执行经验有用”我读下来的体会是策略每家不一样但那套数据驱动、链路打通的执行框架放在任何产品身上都成立。2. 智能投放oCPX 出价、人群服务和素材命中率的三角结构2.1 先看懂 CPX 到 oCPX出价目标从“动作”变成“结果”智能投放这一章技术上最核心的是那一串流程图用户访问、竞标请求、竞标反馈、素材推荐、流量分发、用户触达、效果反馈最后再回到模型优化。这个闭环里有一个容易被忽略的转变——从 CPX 到 oCPX 的进化。CPX 时代广告主买的是曝光、点击、下载这种“动作”比如 CPC 按点击付费只要点了一下钱就花了后面用户有没有变成活跃用户和投放系统没关系。oCPX 不一样它把出价目标后移到转化行为上系统按“获取一个有价值的用户”来出价而不是按“获取一次点击”来出价。流程上分三段广告主上报转化目标比如“完成注册”或“完成首购”投放系统根据实时竞价RTB、程序化直购PD或优先购买PDB拿到流量再用用户识别和人群画像判断这个流量是否值得出价成交后用 Action 系统把点击、激活、次留数据回传进入模型迭代。# 简化版 oCPX 出价决策 def cal_bid(user, campaign, pv_price): # user: 实时请求携带的识别信息 # campaign: 广告计划的转化目标、预算、目标成本 # pv_price: 当前流量的市场底价 if user.is_black(): return 0, blacklist # 黑名单直接放弃 p_convert campaign.model.predict(user) # 模型预估转化概率 # 目标成本是获取一个有效转化的期望花费 bid_price p_convert * campaign.target_cpa * campaign.bid_ratio if bid_price pv_price * 0.8: # 低于底价 20% 以上放弃 return 0, price_too_low if bid_price campaign.max_bid: # 不超过计划级出价上限 bid_price campaign.max_bid return bid_price, ok参数说明p_convert是模型预估的转化概率target_cpa是广告主能接受的平均获客成本bid_ratio是放大系数。为什么有这个系数因为模型预估通常偏保守尤其是新广告计划冷启动阶段实际转化率可能比预估高放一个系数可以避免因为预估偏低而错失流量。这个写法是伪代码不是生产实现但把出价决策的骨架讲清楚了先判断要不要再算报多少价。2.2 离在线人群服务流量筛选的两级响应投放引擎拿到一次流量请求第一件事是判断“值不值得买”。判断靠的是人群服务。这里有一个性能上的矛盾RTB 实时竞价要求毫秒级响应但在线全量计算用户画像是不现实的。所以人群服务的标准做法是分成离线和在线两层。离线层用 Spark 或 Hive 批处理把用户行为数据加工成标签更新频率通常是小时级或天级覆盖活跃用户、流失用户、潜在用户等宽泛分层在线层用 Redis 或本地缓存存高频判断结果比如黑白名单、近期是否已触达等强时效约束。// 人群服务请求示例简化 { request_id: 8f3a2c91-7b2e-4f6a-9c0d-1e2f3a4b5c6d, user_id: u_1029384756, scene: rtb_bidding, ad_plan: plan_20240517_001, online_tags: [high_value, seen_3d_ago], offline_tags: [age_25_30, city_tier_1, purchase_3m] }这里online_tags是实时从用户本次会话或近期行为中提取的标签offline_tags来自离线画像。投放引擎拿到这两组标签后再叠加广告计划的目标人群条件做交集判断。为什么一定要两层因为离线标签全量但慢在线标签快但覆盖窄组合使用才能既保响应速度又保判断准确度。2.3 素材个性化服务海量素材解决“千人一面”流量筛选解决了“给谁看”的问题素材服务解决的是“看什么”。这个服务把货品、权益、品牌、模板、文案拆成独立模块按用户档案在线组合成一条投放素材再走审核、打标、输出流程。// 素材组装规则伪代码 素材 模板[scene] 文案[user_group] 权益[user_level] if user.last_order_days 15: 素材 权益(召回礼包) 文案(好久不见有一份专属补贴) elif user.is_new: 素材 权益(新人专享) 文案(首单立减今天注册今天用)投放到抖音视频信息流时这条链路的效果提升非常明显。原文里给出的数据是“曝光点击率平均提升 1-2 倍最高可提升 5 倍以上”。这个数字的实现依赖两个前提一是域外用户档案要足够细二是素材组合的响应时间要够快否则一条曝光请求来了素材还在组装流量就浪费了。这也解释了为什么投放系统需要一个专门面向外部流量场景的“素材服务”而不是让运营手动配图。2.4 投放效果衰减时的排查顺序智能投放上线后常见问题是曝光量很大但点击率持续走低。我一般按这个顺序排查先查流量筛选是否过窄——人群条件叠加太多匹配量变小广告系统为了花完预算会降低出价导致拿到的流量质量变差再查素材命中率——同一批素材投放超过一定曝光量后疲劳度上升点击率自然衰减需要观察素材维度的生命周期最后查 Action 回传——转化数据回传延迟或丢失会导致模型优化方向偏掉。3. 矩阵优势与拉承一体二方触达和完整拉承链路3.1 增长矩阵让用户在一个体系内多点触达矩阵优势这章的核心观点是不要只依赖外部投放体系内的产品节点之间要互相渗透。用户在淘宝 App、支付宝小程序、UC、高德等不同产品里都登录过淘宝账号这些节点之间天然存在信任关系。相对于外部渠道二方触达成本更低用户不反感转化的质量往往更高。这里有个很关键的概念切换“小程序是极简的 App而不是扩展的界面列表”。也就是说矩阵里的每个节点不是简单放一个活动页而是按 App 视角去做产品级合作——登录态打通、核心动线可走通、下单链路无断裂。我理解这套逻辑的关键是把外部流量接进来之后先解决身份识别再谈转化。所以二方触达的技术底座和智能投放一样都需要用户数据总线在前面做支撑。3.2 小程序作为矩阵节点的性能边界选小程序做矩阵节点而不是 H5 或 Native是从开发成本和性能稳定性之间找平衡。几个方案的对比如下方案开发成本跨端能力性能体验运营灵活性H5低强一般强RN中中较好中小程序中低强较好强Native App高弱最好弱小程序能在 App 内生态以较低成本获得类原生的体验同时自带跨端能力是矩阵触达比较合适的技术载体。但要注意的是小程序承载的核心不是“展示”而是“承接”——把用户从触达场景带到登录和首购链路所以小程序的埋点、参数透传、登录态设计都要按 App 的标准来做而不是按 H5 标准做。3.3 拉承一体把漏斗从曝光一直管到 15 日复购拉承一体这一章原文给了一条很有意思的链路曝光 → 点击 → 承接页 → 页面点击 → 下载/安装/唤起 → 注册/登录 → 首购 → 次日复购 → 7日三单 → 15日。这条链路的每一段都对应一个转化率指标只有把每一层的衰减控制住拉新预算才不会浪费。其中最容易断的两层一是曝光到点击依赖素材质量和投放精准度二是下载到登录依赖承接页加载速度和登录链路设计。-- 拉承链路漏斗分析示例 WITH events AS ( SELECT user_id, event_time, event_name -- 曝光/点击/下载/登录/首购/次日复购 FROM behavior_log WHERE dt 2024-06-01 ) SELECT count(DISTINCT CASE WHEN event_namead_impression THEN user_id END) AS imp_uv, count(DISTINCT CASE WHEN event_namead_click THEN user_id END) AS click_uv, count(DISTINCT CASE WHEN event_nameapp_launch THEN user_id END) AS launch_uv, count(DISTINCT CASE WHEN event_namelogin_success THEN user_id END) AS login_uv, count(DISTINCT CASE WHEN event_namefirst_order THEN user_id END) AS first_order_uv, round(click_uv / imp_uv, 4) AS ctr, round(login_uv / launch_uv, 4) AS login_rate FROM events这段 SQL 把曝光、点击、启动、登录、首购五层数据一次性算出来ctr和login_rate就是拉承链路中最值得盯的两个指标。如果点击率正常但登录率偏低问题大概率出在承接页体验或唤起参数丢失上而不是渠道质量问题。3.4 承接页与唤起参数App Link 和 Smart Banner 的分工链路里“连接器”这个角色原文给了两个具体实现App LinkNative和 Smart BannerJS。这两个东西的分工值得展开。App Link 是 Native 层面的方案用户在 Web 环境点击一个 URI系统直接唤起 App 并定位到指定页面。它的体验最好但依赖系统和 App 的配置正确性。Smart Banner 是 JS 方案Web 页面上展示一条智能横幅根据设备类型识别是否安装过 App给出“打开 App”或“立即下载”的按钮。这套机制的参数透传是整个拉承链路的隐形关键。# 唤起参数示例 https://tb.cn/redirect? targetitem_detail item_id728394 channel_idmatrix_miniapp campaign_idug_20240601 plan_idrecall_15d scenematrix_node_b # 目标端解析后 # targetitem_detail - 落地到商品详情页 # channel_id - 归因渠道用于回溯流量来源 # plan_id - 用于后续策略分析召回计划效果这些参数如果丢失或错位后续做渠道归因和方法分析时会全部失真。上线前我把这个参数协议和客户端、H5、小程序三端对了一遍确认每个场景至少包含channel_id、campaign_id、scene三个字段才放量。4. 长周期运营与用户数据总线把留存做出确定性4.1 增长公式里的留存变量在哪里回到开头的公式MAtU MNU MNUt-1 * r MA(活跃)Ut-1 * (1 - λ)。r是上月新用户在本月继续活跃的比例λ是本月活跃用户在下月流失的比例。运营动作和公式的对应关系是公式变量对应动作典型场景MNU新增智能投放 矩阵拉新外部渠道投放、小程序矩阵入口MNU t-1 * r新用户长周期运营次日复购、7日三单、15日养成MAU t-1 * (1-λ)沉默召回流失预警、召回触达、唤醒活动这个视角把留存从“结果指标”拆成了“分阶段动作”算下r和λ的具体数值就能判断当前增长瓶颈到底出在新增、新用户成长还是老用户流失上。4.2 用户数据总线二方触达和三方投放共用一套底座智能投放和矩阵优势两条线都有一个共同动作用户识别。无论是二方产品触达还是三方投放触达流量进来后先经过用户识别判断是老用户还是新用户再进入人群系统做分层。行为数据和漏斗分析结果回灌到用户数据总线形成增量用户画像。没有这个底座每个触达场景都要重建一套用户识别逻辑成本高且口径不统一。我见过的问题是同一个用户前一天点击了广告但没安装第二天在矩阵小程序里又看到同一个权益两次触达的频控没有打通用户会觉得平台一直在“追”着他推。正确的做法是所有触达场景的 request 都带同一套用户识别 ID比如经过设备指纹或手机号映射用户数据总线按这个 ID 汇总各个场景的行为序列并输出总触达次数供各场景执行频控。-- 用户触达频率检查 SELECT user_id, COUNT(DISTINCT scene) AS touch_scenes, COUNT(*) AS touch_times, MAX(event_time) AS last_touch_time FROM touch_log WHERE user_id u_1029384756 AND event_time DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY user_id如果touch_times超过阈值例如 5 次后续各场景触达时就要降权或直接跳过。这里的关键不只是“频率限制”而是让所有场景共用同一份计数而不是各算各的。4.3 长周期运营按时间窗口设计用户动作原文提到的“次日复购、7日三单、15日”是三个明确的时间刻度。落到用户运营上就是针对不同生命周期的用户给不同的动作新用户首单完成后第二天是否回来直接决定了七日留存的下限。所以很多团队会把“首日权益”设计成需要次日回来才能领取或者用“第二天有额外补贴”的方式拉住复访。7 日三单的设计目的是让用户在一个自然周内深度参与形成习惯。15 日则是一个完整的消费周期连续两次都在 15 日周期内完成购买行为基本稳定了。这套逻辑落地离不开自动化的运营配置工具——什么时候触发、用哪个触达通道、展示什么权益、频控限制多少都要可以在平台上配置而不是靠运营每天手动拉数据、手动发短信。4.4 策略 1数据为王的真正含义“数据为王”不是做一张大屏每天看数字而是把数据嵌入决策流。人群分层要数据出价要数据素材推荐要数据触达频控要数据。没有数据前面五个策略全部没有抓手。做技术的人最容易犯的错是把报表做得很漂亮但没有嵌入到业务动作中。数据有没有用不看报表看有没有产生动作。5. 平台提效连接器、智能分流和效果验证5.1 连接器是触达和承接之间的胶水平台提效这章解决的是流量拉到门口之后靠什么把用户接进来。连接器的两个具体实现App Link 和 Smart Banner已经在前文讲完了。还有一个动作叫“承接”——新用户从广告落地页点进来看到的第一个页面是固定的落地页还是根据用户来源动态拼接的承接页差别很大。我一般会在承接页 URL 里带scene参数服务端根据这个参数决定渲染什么内容scenead_toutiao新人引导 首单权益弹层scenematrix_miniapp会员登录提醒 上一环节未完成的权益scenepush_recall直接展示召回礼包领取页。// 智能分流伪代码 func routing(user, scene): if user.is_member(): return member_home // 会员产品承接 if user.is_new(): return new_user_guide // 新人首页弹层 if user.is_recalled(): return recall_benefit // 召回礼包页面 return default_home这套路由逻辑要放在服务端而不是客户端否则新版本上线前老版本用户的行为无法控制。5.2 灰度验证分流效果怎么测才可信流量分流做了改动后验证方法上有一个容易踩的坑只看整体转化率而不做同层对比。正确做法是同一时间段内同一个人群包切两批随机流量A 组走新分流逻辑B 组走旧逻辑观察核心指标差异。灰度放量的比例建议从 5% 开始观察 1-2 个完整自然日后如果登录率或首购率没有明显回退再逐步放大到 20%、50%、100%。这个节奏比一次性全量上线稳妥得多因为分流逻辑一旦影响了登录率全量事故要回滚的成本很高。5.3 上线前花十分钟核对这几件事最后补一个我自己的检查清单每次做触达策略改动时都过一遍唤起参数channel_id是否有默认值兜底App Link 是否配置了降级路径——唤起失败要自动跳转应用市场频控是全局统一计数跨场景生效实验分桶是否有冲突——同一用户不要同时进入多个 A/B 实验的桶。把这四项核对完再放量基本能把唤起失败和频控失效这两类问题挡在上线之前。本文还有配套的精品资源点击获取
从智能投放到拉承一体：用户增长技术策略与落地实践
简介《淘宝用户增长的51个技术策略》是一份来自阿里巴巴淘系技术部高嘉峻的实战分享PDF面向产品、运营及用户增长相关技术人员系统梳理了数据驱动增长的核心框架与落地方法。内容从用户增长公式切入拆解MAU构成随后逐一讲解智能投放、矩阵优势、拉承一体、长周期运营、平台提效以及数据为王共51个策略涵盖CPX/oCPX投放、离在线人群服务、抖音信息流个性化、小程序矩阵、完整拉承链路等具体实践并配有图表与流程说明适合需要搭建增长体系或优化现有策略的中高级从业者参考。资源包共1个PDF文件总大小9.32MB文件结构清晰。目前已有154人学习浏览对于希望快速理解淘宝用户增长技术策略的读者这份资料能提供高密度的方法论沉淀与可借鉴的执行思路。1. 用户增长不只是拉新先看懂那个公式做移动开发十年后转去做用户增长我第一件事不是追热点渠道而是把 PPT 首页那张MAtU MNU MNUt-1 * r MA(活跃)Ut-1 * (1 - λ)抄在本子上。原因很简单当时外部都在讲“拉新预算怎么分”但真正决定月活大盘的是新增、召回、留存三件事同时做功。新增帮盘子扩容召回把沉默用户拖回来留存和唤醒让活跃基数越来越大。这三块对应到技术侧就是智能投放、矩阵触达、长周期运营和平台承接连成一体的系统设计。伯灵这篇分享在开头就说“技术策略不具备参考意义但执行经验有用”我读下来的体会是策略每家不一样但那套数据驱动、链路打通的执行框架放在任何产品身上都成立。2. 智能投放oCPX 出价、人群服务和素材命中率的三角结构2.1 先看懂 CPX 到 oCPX出价目标从“动作”变成“结果”智能投放这一章技术上最核心的是那一串流程图用户访问、竞标请求、竞标反馈、素材推荐、流量分发、用户触达、效果反馈最后再回到模型优化。这个闭环里有一个容易被忽略的转变——从 CPX 到 oCPX 的进化。CPX 时代广告主买的是曝光、点击、下载这种“动作”比如 CPC 按点击付费只要点了一下钱就花了后面用户有没有变成活跃用户和投放系统没关系。oCPX 不一样它把出价目标后移到转化行为上系统按“获取一个有价值的用户”来出价而不是按“获取一次点击”来出价。流程上分三段广告主上报转化目标比如“完成注册”或“完成首购”投放系统根据实时竞价RTB、程序化直购PD或优先购买PDB拿到流量再用用户识别和人群画像判断这个流量是否值得出价成交后用 Action 系统把点击、激活、次留数据回传进入模型迭代。# 简化版 oCPX 出价决策 def cal_bid(user, campaign, pv_price): # user: 实时请求携带的识别信息 # campaign: 广告计划的转化目标、预算、目标成本 # pv_price: 当前流量的市场底价 if user.is_black(): return 0, blacklist # 黑名单直接放弃 p_convert campaign.model.predict(user) # 模型预估转化概率 # 目标成本是获取一个有效转化的期望花费 bid_price p_convert * campaign.target_cpa * campaign.bid_ratio if bid_price pv_price * 0.8: # 低于底价 20% 以上放弃 return 0, price_too_low if bid_price campaign.max_bid: # 不超过计划级出价上限 bid_price campaign.max_bid return bid_price, ok参数说明p_convert是模型预估的转化概率target_cpa是广告主能接受的平均获客成本bid_ratio是放大系数。为什么有这个系数因为模型预估通常偏保守尤其是新广告计划冷启动阶段实际转化率可能比预估高放一个系数可以避免因为预估偏低而错失流量。这个写法是伪代码不是生产实现但把出价决策的骨架讲清楚了先判断要不要再算报多少价。2.2 离在线人群服务流量筛选的两级响应投放引擎拿到一次流量请求第一件事是判断“值不值得买”。判断靠的是人群服务。这里有一个性能上的矛盾RTB 实时竞价要求毫秒级响应但在线全量计算用户画像是不现实的。所以人群服务的标准做法是分成离线和在线两层。离线层用 Spark 或 Hive 批处理把用户行为数据加工成标签更新频率通常是小时级或天级覆盖活跃用户、流失用户、潜在用户等宽泛分层在线层用 Redis 或本地缓存存高频判断结果比如黑白名单、近期是否已触达等强时效约束。// 人群服务请求示例简化 { request_id: 8f3a2c91-7b2e-4f6a-9c0d-1e2f3a4b5c6d, user_id: u_1029384756, scene: rtb_bidding, ad_plan: plan_20240517_001, online_tags: [high_value, seen_3d_ago], offline_tags: [age_25_30, city_tier_1, purchase_3m] }这里online_tags是实时从用户本次会话或近期行为中提取的标签offline_tags来自离线画像。投放引擎拿到这两组标签后再叠加广告计划的目标人群条件做交集判断。为什么一定要两层因为离线标签全量但慢在线标签快但覆盖窄组合使用才能既保响应速度又保判断准确度。2.3 素材个性化服务海量素材解决“千人一面”流量筛选解决了“给谁看”的问题素材服务解决的是“看什么”。这个服务把货品、权益、品牌、模板、文案拆成独立模块按用户档案在线组合成一条投放素材再走审核、打标、输出流程。// 素材组装规则伪代码 素材 模板[scene] 文案[user_group] 权益[user_level] if user.last_order_days 15: 素材 权益(召回礼包) 文案(好久不见有一份专属补贴) elif user.is_new: 素材 权益(新人专享) 文案(首单立减今天注册今天用)投放到抖音视频信息流时这条链路的效果提升非常明显。原文里给出的数据是“曝光点击率平均提升 1-2 倍最高可提升 5 倍以上”。这个数字的实现依赖两个前提一是域外用户档案要足够细二是素材组合的响应时间要够快否则一条曝光请求来了素材还在组装流量就浪费了。这也解释了为什么投放系统需要一个专门面向外部流量场景的“素材服务”而不是让运营手动配图。2.4 投放效果衰减时的排查顺序智能投放上线后常见问题是曝光量很大但点击率持续走低。我一般按这个顺序排查先查流量筛选是否过窄——人群条件叠加太多匹配量变小广告系统为了花完预算会降低出价导致拿到的流量质量变差再查素材命中率——同一批素材投放超过一定曝光量后疲劳度上升点击率自然衰减需要观察素材维度的生命周期最后查 Action 回传——转化数据回传延迟或丢失会导致模型优化方向偏掉。3. 矩阵优势与拉承一体二方触达和完整拉承链路3.1 增长矩阵让用户在一个体系内多点触达矩阵优势这章的核心观点是不要只依赖外部投放体系内的产品节点之间要互相渗透。用户在淘宝 App、支付宝小程序、UC、高德等不同产品里都登录过淘宝账号这些节点之间天然存在信任关系。相对于外部渠道二方触达成本更低用户不反感转化的质量往往更高。这里有个很关键的概念切换“小程序是极简的 App而不是扩展的界面列表”。也就是说矩阵里的每个节点不是简单放一个活动页而是按 App 视角去做产品级合作——登录态打通、核心动线可走通、下单链路无断裂。我理解这套逻辑的关键是把外部流量接进来之后先解决身份识别再谈转化。所以二方触达的技术底座和智能投放一样都需要用户数据总线在前面做支撑。3.2 小程序作为矩阵节点的性能边界选小程序做矩阵节点而不是 H5 或 Native是从开发成本和性能稳定性之间找平衡。几个方案的对比如下方案开发成本跨端能力性能体验运营灵活性H5低强一般强RN中中较好中小程序中低强较好强Native App高弱最好弱小程序能在 App 内生态以较低成本获得类原生的体验同时自带跨端能力是矩阵触达比较合适的技术载体。但要注意的是小程序承载的核心不是“展示”而是“承接”——把用户从触达场景带到登录和首购链路所以小程序的埋点、参数透传、登录态设计都要按 App 的标准来做而不是按 H5 标准做。3.3 拉承一体把漏斗从曝光一直管到 15 日复购拉承一体这一章原文给了一条很有意思的链路曝光 → 点击 → 承接页 → 页面点击 → 下载/安装/唤起 → 注册/登录 → 首购 → 次日复购 → 7日三单 → 15日。这条链路的每一段都对应一个转化率指标只有把每一层的衰减控制住拉新预算才不会浪费。其中最容易断的两层一是曝光到点击依赖素材质量和投放精准度二是下载到登录依赖承接页加载速度和登录链路设计。-- 拉承链路漏斗分析示例 WITH events AS ( SELECT user_id, event_time, event_name -- 曝光/点击/下载/登录/首购/次日复购 FROM behavior_log WHERE dt 2024-06-01 ) SELECT count(DISTINCT CASE WHEN event_namead_impression THEN user_id END) AS imp_uv, count(DISTINCT CASE WHEN event_namead_click THEN user_id END) AS click_uv, count(DISTINCT CASE WHEN event_nameapp_launch THEN user_id END) AS launch_uv, count(DISTINCT CASE WHEN event_namelogin_success THEN user_id END) AS login_uv, count(DISTINCT CASE WHEN event_namefirst_order THEN user_id END) AS first_order_uv, round(click_uv / imp_uv, 4) AS ctr, round(login_uv / launch_uv, 4) AS login_rate FROM events这段 SQL 把曝光、点击、启动、登录、首购五层数据一次性算出来ctr和login_rate就是拉承链路中最值得盯的两个指标。如果点击率正常但登录率偏低问题大概率出在承接页体验或唤起参数丢失上而不是渠道质量问题。3.4 承接页与唤起参数App Link 和 Smart Banner 的分工链路里“连接器”这个角色原文给了两个具体实现App LinkNative和 Smart BannerJS。这两个东西的分工值得展开。App Link 是 Native 层面的方案用户在 Web 环境点击一个 URI系统直接唤起 App 并定位到指定页面。它的体验最好但依赖系统和 App 的配置正确性。Smart Banner 是 JS 方案Web 页面上展示一条智能横幅根据设备类型识别是否安装过 App给出“打开 App”或“立即下载”的按钮。这套机制的参数透传是整个拉承链路的隐形关键。# 唤起参数示例 https://tb.cn/redirect? targetitem_detail item_id728394 channel_idmatrix_miniapp campaign_idug_20240601 plan_idrecall_15d scenematrix_node_b # 目标端解析后 # targetitem_detail - 落地到商品详情页 # channel_id - 归因渠道用于回溯流量来源 # plan_id - 用于后续策略分析召回计划效果这些参数如果丢失或错位后续做渠道归因和方法分析时会全部失真。上线前我把这个参数协议和客户端、H5、小程序三端对了一遍确认每个场景至少包含channel_id、campaign_id、scene三个字段才放量。4. 长周期运营与用户数据总线把留存做出确定性4.1 增长公式里的留存变量在哪里回到开头的公式MAtU MNU MNUt-1 * r MA(活跃)Ut-1 * (1 - λ)。r是上月新用户在本月继续活跃的比例λ是本月活跃用户在下月流失的比例。运营动作和公式的对应关系是公式变量对应动作典型场景MNU新增智能投放 矩阵拉新外部渠道投放、小程序矩阵入口MNU t-1 * r新用户长周期运营次日复购、7日三单、15日养成MAU t-1 * (1-λ)沉默召回流失预警、召回触达、唤醒活动这个视角把留存从“结果指标”拆成了“分阶段动作”算下r和λ的具体数值就能判断当前增长瓶颈到底出在新增、新用户成长还是老用户流失上。4.2 用户数据总线二方触达和三方投放共用一套底座智能投放和矩阵优势两条线都有一个共同动作用户识别。无论是二方产品触达还是三方投放触达流量进来后先经过用户识别判断是老用户还是新用户再进入人群系统做分层。行为数据和漏斗分析结果回灌到用户数据总线形成增量用户画像。没有这个底座每个触达场景都要重建一套用户识别逻辑成本高且口径不统一。我见过的问题是同一个用户前一天点击了广告但没安装第二天在矩阵小程序里又看到同一个权益两次触达的频控没有打通用户会觉得平台一直在“追”着他推。正确的做法是所有触达场景的 request 都带同一套用户识别 ID比如经过设备指纹或手机号映射用户数据总线按这个 ID 汇总各个场景的行为序列并输出总触达次数供各场景执行频控。-- 用户触达频率检查 SELECT user_id, COUNT(DISTINCT scene) AS touch_scenes, COUNT(*) AS touch_times, MAX(event_time) AS last_touch_time FROM touch_log WHERE user_id u_1029384756 AND event_time DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY user_id如果touch_times超过阈值例如 5 次后续各场景触达时就要降权或直接跳过。这里的关键不只是“频率限制”而是让所有场景共用同一份计数而不是各算各的。4.3 长周期运营按时间窗口设计用户动作原文提到的“次日复购、7日三单、15日”是三个明确的时间刻度。落到用户运营上就是针对不同生命周期的用户给不同的动作新用户首单完成后第二天是否回来直接决定了七日留存的下限。所以很多团队会把“首日权益”设计成需要次日回来才能领取或者用“第二天有额外补贴”的方式拉住复访。7 日三单的设计目的是让用户在一个自然周内深度参与形成习惯。15 日则是一个完整的消费周期连续两次都在 15 日周期内完成购买行为基本稳定了。这套逻辑落地离不开自动化的运营配置工具——什么时候触发、用哪个触达通道、展示什么权益、频控限制多少都要可以在平台上配置而不是靠运营每天手动拉数据、手动发短信。4.4 策略 1数据为王的真正含义“数据为王”不是做一张大屏每天看数字而是把数据嵌入决策流。人群分层要数据出价要数据素材推荐要数据触达频控要数据。没有数据前面五个策略全部没有抓手。做技术的人最容易犯的错是把报表做得很漂亮但没有嵌入到业务动作中。数据有没有用不看报表看有没有产生动作。5. 平台提效连接器、智能分流和效果验证5.1 连接器是触达和承接之间的胶水平台提效这章解决的是流量拉到门口之后靠什么把用户接进来。连接器的两个具体实现App Link 和 Smart Banner已经在前文讲完了。还有一个动作叫“承接”——新用户从广告落地页点进来看到的第一个页面是固定的落地页还是根据用户来源动态拼接的承接页差别很大。我一般会在承接页 URL 里带scene参数服务端根据这个参数决定渲染什么内容scenead_toutiao新人引导 首单权益弹层scenematrix_miniapp会员登录提醒 上一环节未完成的权益scenepush_recall直接展示召回礼包领取页。// 智能分流伪代码 func routing(user, scene): if user.is_member(): return member_home // 会员产品承接 if user.is_new(): return new_user_guide // 新人首页弹层 if user.is_recalled(): return recall_benefit // 召回礼包页面 return default_home这套路由逻辑要放在服务端而不是客户端否则新版本上线前老版本用户的行为无法控制。5.2 灰度验证分流效果怎么测才可信流量分流做了改动后验证方法上有一个容易踩的坑只看整体转化率而不做同层对比。正确做法是同一时间段内同一个人群包切两批随机流量A 组走新分流逻辑B 组走旧逻辑观察核心指标差异。灰度放量的比例建议从 5% 开始观察 1-2 个完整自然日后如果登录率或首购率没有明显回退再逐步放大到 20%、50%、100%。这个节奏比一次性全量上线稳妥得多因为分流逻辑一旦影响了登录率全量事故要回滚的成本很高。5.3 上线前花十分钟核对这几件事最后补一个我自己的检查清单每次做触达策略改动时都过一遍唤起参数channel_id是否有默认值兜底App Link 是否配置了降级路径——唤起失败要自动跳转应用市场频控是全局统一计数跨场景生效实验分桶是否有冲突——同一用户不要同时进入多个 A/B 实验的桶。把这四项核对完再放量基本能把唤起失败和频控失效这两类问题挡在上线之前。本文还有配套的精品资源点击获取