一、前言

1.1 行业背景

移动互联网发展进入瓶颈期，各大APP的用户增长的流量红利结束，面临如何实现存量掘金的问题。
当用户群体的规模不再增长时，对用户的使用频次和时长的提升就显得尤为重要，特别是对于淘宝这种流量消耗性的APP，我们对于流量来源的焦虑从来没有停止过。在之前，淘宝普遍采用的是大量的外投媒体广告，实现端外的用户引流，需要花费大量的资金成本，且随着电商竞争的白热化，ROI的提升也越加困难。
而外部的环境也在悄然变化，由于国内手机总出货总体下滑，且用户换机周期变长，国内厂商开始寻求多元商业化，硬件媒体化，围绕内容生态、APP增长服务布局，一方面希望打通APP服务提高手机生态的易用性/用户依赖，另一方面希望通过内容广告生态打造硬件收入外的第二支柱；各家厂商逐步推出大量免费/付费的桌面触达产品，比如widget组件、负一屏卡片、系统搜索、系统建议、桌面小组件、快捷方式等，围绕着 厂商渠道的触达生态 逐渐形成。
借助 厂商渠道触达生态，我们开始打造全新的、体系化的 **厂商桌面触达 **方式，基于整合淘内业务的数据，通过厂商渠道及时触达用户，来吸引用户下载/使用 淘宝。实现在外投媒体广告、PUSH/短信方式之外，找到新的引流来源，提升手淘的DAU和用户粘性。

1.2 渠道分析

我们基于渠道自身展现形式和功能特性，对渠道做如下分类，并在我们关注的4个重要维度上对渠道做打分：
  • 内容表现力：渠道的内容表现的丰富程度，这对于后续的业务运营、用户体验和转化效果起到很大的作用；
  • 内容及时性：渠道的内容数据更新及时性，部分业务会对及时性有强诉求，比如物流、秒杀等
  • 引导成本：渠道在触达用户前需要的引导安装成本，部分渠道需要用户开通权限或者主动添加到桌面才能使用，较高的引导成本是阻碍渠道起量的重要因素
  • 转化效果：综合内容的表现力、及时性和可运营空间，基于手淘的经验，粗略评价每个渠道的曝光转化率
  • 【桌面小组件】的典型效果：
  • 【搜索推荐】的典型效果：
  • 【其他渠道】的典型效果：

1.3 平台定位

基于上述行业背景、渠道和竞品分析，我们决定打造属于自己的的厂商桌面触达体系。
核心目标：联合厂商生态开拓手淘外延新阵地，面向 体验和效率 沉淀端云一体的厂商触达运营体系，带来 手淘DAU和访问频次增量 。

1.4 成果展示

再展开讲设计和思考之前，先抛一下我们的成果。经过近一年的建设，通过贴合厂商挖掘渠道，链接业务透出内容，沉淀基建提高效率等方式，我们实现了 唤端UV、首唤UV、DAU独占 的高速增长。
【业务侧】，我们实现了 唤端UV相比财年初增长了2倍以上，达到x00W+，其中 首唤占比达到xx%+；按照商务采购价，预计一年可以为公司节省x亿资金；另外，根据用增内部严格的AB口径对比，厂商生态已经是手淘DAU增量的第一大来源（10月、11月分析）。
【技术侧】，我们从0到1沉淀了厂商生态体验平台，作为链接厂商和手淘的基建底座，已经有6个可运营渠道，2个不可运营渠道，以及下游链接30+业务，具备渠道/业务快速接入、通用运营和体验管控能力，显著提高了业务外延、渠道扩展、业务运营的效率。

二、问题与挑战

2.1 挑战现状

  • 流量问题：新渠道对接成本高、旧渠道缺少可持续运营，导致流量增长困难
    • 对比：支付宝各渠道情况，深度运营 & 结合定位特色（工具属性占70%+）；淘宝优势在于业务内容丰富度，是特定渠道上是有机会超过支付宝的；
  • 效率问题：渠道复杂、厂商特性各异、各领域业务重复对接，导致业务外延效率低
    • 对比：支付宝，有统一的厂商触达平台，提供完善的基建，简化业务对接的成本
  • 体验问题：渠道独立且相互难感知、低质内容引流频发，导致用户体验有恶化趋势
    • 举例：有多起用户投诉反馈，有厂商付费资源位强制出现在桌面且无法关闭，而用户投诉的主体都是淘宝
    • 举例：端外环境用户隐私保护意识更强，且系统后台环境更为复杂，需要在 用户体验（打扰度、及时性）、业务诉求、端侧性能（功耗、卡顿）之间取得平衡

2.2 应对策略

  • 解决【流量增长困难】：
    • 【增量扩展】挖掘增量矩阵，以桌面小组件为主要渠道，丰富触达产品矩阵，多渠道能力挖掘与建设并进（搜索、悬浮窗、日历、语音助手、鸿蒙FA native卡片、负一屏等）
    • 【存量提质】能投放&好运营，建设可视化运营投放平台，实现【运营配置->素材投放->数据回流】闭环SOP，提升业务运营效率，提供人群、实验、策略、算法等运营干预能力，通过持续迭代提升流量转化效率
  • 解决【业务外延效率低】：
    • 【服务端】统一数据通道，平台侧收敛各产品触达链路的复杂性，对外抹平各家厂商差异（桌面定制化、桌面版本碎片化、权限各异），对内简化下游业务场景接入成本等，实现高时效、可扩展、易接入的厂商触达通道；
    • 【客户端】内容动态化，端侧通过远程配置、动态布局、模板搭投突破发版限制，提升现有渠道业务落地效率；
  • 保障【用户产品体验】：
    • 【客户端】通过低功耗技术、交互体验创新、实时性保障用户体验
    • 【服务端】通过 同质内容降频、刷新间隔控制、低质内容过滤 保障用户体验

三、平台设计

3.1 整体架构

结合上面的应对策略，我们先对业务实体、开发功能做如下的模型定义：
  • 【业务模型】定义：
    • 应用：客户端APP，支持中台横向输出
    • 渠道：厂商的一个系统特性/能力，单个应用可以支持接入多个渠道
    • 业务：同一个应用下，创建的业务身份
    • 活动：在具体应用+具体渠道下，由具体业务创建的触发用户的配置，主要包括时机、场景、内容、人群等
    • 素材：主要指活动中的触达内容，对内容的优化、沉淀和交互创新，有助于我们提升流量质量和用户体验
  • 【开发模型】定义：
    • 策略库：是指对活动配置中，基于业务诉求采用的投放策略，主要是对时机、场景、内容、人群的调优组合
    • 实验库：在不同的活动策略中，进行AB实验和效果回收对比的能力
    • 素材库：对优质素材内容的度量、沉淀、对比，以及同类活动素材推荐
再在这个基础上，实现 业务供给 -> 运营投放 -> 效果回收 -> 策略调整 的运营SOP，平台重点围绕着【渠道&业务快速接入】、【通用运营能力】、【体验统一管控】、【稳定性保障】五个点进行建设，下面将展开讲讲。

3.2 渠道&业务快速接入

【对外】：根据渠道的【数据请求模式】进行归类，提供【统一数据通道】，端侧实现屏蔽用户终端操作系统类型、系统版本、机型、权限等环境的复杂性、差异性；
  • 厂商直接请求型：由厂商系统侧直接发起请求，数据直接返回给厂商后，由厂商系统负责展示，典型的例如智慧识屏、小米图搜等
  • APP数据拉取型：由APP侧直接发起请求，数据直接返回给APP后，由APP/厂商系统负责展示，典型的例如WIDGET、锁屏组件、iOS搜索等
  • APP数据推送型：由云端识别到触达时机，主动推送数据给客户端，由APP/厂商系统负责展示，典型的例如悬浮窗、live activity更新等
【对内】：抽象【内容投放模式】，提供多种业务接入模式，支持下游业务快速、按需对接
  • 资源投放型：基于纯运营配置实现内容更新，典型的例如ICON快捷列表的4个运营坑位，就是由运营手动配置调整
  • 业务对接型：基于下游业务供给实现内容更新，典型的例如淘金币widget的数据
  • 混合型：上述两种模式的混合，一部分来自运营手动配置，一部分来自下游业务供给，典型的例如iOS系统搜索，2000+搜索词组是多方数据混合的产物

3.2.1 统一数据通道

厂商端外触达入口多种多样，包括系统widget，各厂商widget， 悬浮窗，日历，搜索等；不同触达方式对用户可能透出不同的业务数据，有各自的数据刷新链路、刷新频次，且存在内容、厂商、系统、设备上的各方面差异性，业务侧去解决这些碎片化的兼容问题，成本巨大；因此，我们实现了【统一数据协议】、【刷新间隔控制】和【聚合请求模式】，将所有渠道收敛到一起，抹平掉所有渠道差异，并对齐到某一时间统一调度，既能保持请求量的有序可控，也能降低业务的接入成本。

3.2.2 下游高效对接

提供可插拔的对接模式，满足【资源投放型】、【业务对接型】、【混合型】等不同类型内容的业务投放诉求，业务可以按需接入我们提供的多层能力，最大程度的降低下游业务的重复实现成本。
自身投放平台，可以满足运营各类灵活配置的诉求，统一投放引擎提供多种业务策略调度，对于有自建配置能力的业务，可以选择对接到投放引擎层，并配合自身的业务运营系统使用。对于不想自建运营系统的业务，可以在提供下游业务数据对接后，在厂商平台完成运营配置。

3.3 通用运营能力

3.3.1 投放SOP抽象

由于各渠道的所需的数据内容差异很大，比如 widget 是带界面的UI展示且界面由业务定制，而 ICON快捷列表是标准的数据列表格式，只需给出标题、图标和唤端链接即可。因此，需要需要抽象一套通用的运营能力，将通用的投放能力、运营策略、数据度量下沉一层，而各渠道的差异内容作为content配置字段，交由各渠道自己配置，从而实现 渠道的快速扩展和快速运营。
素材代表着活动的UI展示和交互，类比于HTML、CSS，对于 锁屏组件、WIDGET、LIVE ACTIVITY 等具备动态化渲染能力的渠道上，我们可以通过素材搭建实现丰富的表现力。
业务供给代表着下游的数据供给，比如淘金币待领取数据、购物车降价信息、物流状态更新等，这些业务数据需要和素材绑定，最终呈现为用户看到的动态界面。
素材+业务供给形成了触达用户的最终内容，定投维度则表示我们可以将多份内容定向的投放给更匹配的用户，目前我们具备的维度有人群、厂商品牌、系统类型、APP版本、机型、生效时间、曝光疲劳度、优先级等
在基于通用的状态驱动流程 + 数据回收流程，将每个活动都规范化实现配置投放、数据回收、策略优化的闭环流程。

3.3.1 素材搭建

部分渠道的界面是具备较大的调整空间，因此我们通过客户端动态化的方案来满足各业务不同的界面展示诉求，这极大的提升了我们的研发效率和渠道运营能力。举例来说，下面的WIDGET就是通过动态化搭建的方式产出的界面：

3.4 体验统一管控

3.4.1 端侧功耗优化

内容的及时性会极大的影响用户的体感，例如热门直播的开播信息如果更新不及时，可能导致用户错过直播，导致较大舆情；而频繁的更新，又会导致手淘在后台频繁拉起主进程，频繁请求数据，带来后台功耗与联网问题，极易被厂商安全软件感知引起用户投诉，且服务端的水位压力也增长明显。
因此，借助【统一数据通道】的建设，我们增加一层刷新间隔控制，通过渠道级别、接口级别两层刷新间隔的控制，实现云管端的间隔控制；且端侧也通过【轻量级桌面独立进程】，通过轻量级的进程实现数据更新。
两者结合，实现尽量减少用户手机上数据更新导致的功耗问题。

3.4.2 负反馈监控

去年是我们厂商桌面渠道的起量阶段，多渠道之间的内容冲突、重复，以及对用户的打扰度还不高，但我们也提前开始关注这方面内容。主要通过两方面的数据观测：
  • 通用舆情：观察桌面渠道相关的舆情数据
  • 渠道指标：每个渠道我们都在逐步定义他们相关的负向指标，用于观察用户的留存、反感情况。
  • 例如，WIDGET渠道，我们和用增产品、用增BI定义用户留存情况观察，用于度量渠道内容的优质程度；
对于负反馈监控，我们也在逐步的完善中，端外渠道相比于端内的难点在于，很多渠道无法拿到客户端埋点，行为是控制在系统侧的，只能通过服务端请求、唤端追踪的方式间接度量效果。
对于低质内容、用户打扰度高的渠道，我们会不断完善流量控制及预警策略，以此来保障端外用户的整体体验，避免被用户视为流氓软件。

3.5 稳定性保障

我们云端的流量分发机制是从 接口 -> 渠道 -> 业务 -> 配置 -> 下游供给 的分发流程，在聚合请求模式下，会形成层层分发的效果。在每一层我们都有相应的限流保护，尽量将大的异常流量波动控制在前置链路处理，不影响到耗时的下游，要求所有渠道下的业务，在发布活动配置时都必须配置兜底配置，保障端侧用户体验和内容正确性。

3.5.1 业务监控

我们在服务内部，将请求的处理数据格式化后全部保存到SLS日志，然后基于实时处理链路，产出渠道级、业务级、活动级的请求成功率、失败率、请求量以及一些技术维度的数据，并配置成sunfire监控，以及沉淀到ODPS表供给给下游使用。

3.5.2 限流保护

在限流上我们使用多层限流机制，入口链路限流尽可能大，业务限流尽可能精准，并在限流时走降级容灾链路，展示兜底配置内容：
  • 入口限流：Aserver限流、Sentinel入口限流、Noah限流
  • 业务限流：渠道级限流、业务级限流、下游服务限流
并且业务限流，可以接受switch动态配置，因为业务还在高效迭代，流量的变化非常快（相比财年初，我们的流量增长了20倍以上），因此通过switch动态配置业务限流，在发生实时预警时，可以便捷的调整限流分配，保障机器资源和容量的动态分配。

3.5.3 降级容灾

所有渠道下的业务，在配置线上活动时，都必须配置兜底活动；该活动内容会在线上部分限流场景、下游服务异常、命中活动配置异常时启用，高效快速的返回用户基本可用数据，保障异常场景下的用户体验。

四、未来展望

【业务维度】，向 复杂场景业务解决方案 迈进，通过打通端内外资源位，给业务提供全域触达的方案，提高业务转化效果，减少业务对接成本；
  • 端外 -> 端内：主打拉承一体，端外触达（厂商渠道、PUSH），端内承接（POP、固定坑位）
    • 举例：iOS search 投放关键词，用户在系统上搜索点击入端后，可以发放特定渠道权益
  • 端内 -> 端外：主打业务外延，基于用户端内的行为、操作，添加端外触达能力
    • 举例：端内用户进入 淘金币，弹出POP引导添加淘金币 widget；
    • 举例：端内用户搜索浏览行为，可以将感兴趣的商品信息直接写入系统搜索，带来新的流量增量；
【技术维度】，我们将围绕厂商生态和用户体验，持续完成新渠道扩张和现渠道深挖，建设内容承接策略和体验管控方案，打造多渠道/保体验/高转化的端云一体的厂商触达引擎
  • 客户端：挖掘厂商/系统更多特性，与厂商深度合作，结合低功耗、保活等核心技术，带来更多触达增量
  • 平台侧：丰富内容供给，完善承接策略、体验管控，提升流量转化效率并保障用户体验，实现可持续的发展
继续阅读
阅读原文