作者：黄昭 阿里 ICBU 买家增长技术团队

近几年用户增长领域 APP 推广发展迅猛，而唤端就是其中的重要技术。通过唤端拉新/促活不仅能能够将三方流量规模做大，同时二方流量也能有效利用，给网站不断带来商机，本文将为大家详细介绍阿里国际站在唤端技术的探索与演进。

一、背景

1.1 前言

近几年用户增长领域 APP 推广发展迅猛，背后有两个深层的原因。一是外部整体互联网的用户规模接近天花板，各大平台进入抢占用户碎片化时间的阶段，能够尽可能的获取用户并引到站内 APP 就更容易留存；另一个是内部业务发展的诉求，追 DAU 保 MAU。而唤端就是其中的重要技术，通过唤端拉新/促活不仅能能够将三方流量规模做大，同时二方流量也能有效利用，给网站源源不断地带来商机。



因此唤端至关重要，所以集团各 BU 相继在此发力。但因场景和目标差异在策略及演进上有所不同，大致可以分为两类。

• 国内业务：以淘系为首的体系。其中以手淘最早投入唤端体系建设，以二方 APP 拉起，外部 BU 接入配置化和自适应为核心发展方向，目前已到平台三化阶段【Starlink"接入/扩展/兼容性" + 海关平台"配置/数据/调试" + 智能化"自适应/弹窗/场景还原" 】其他淘特、闲鱼、阿里拍卖或多或少都基于此进行设计和改造，这里的业务特点是繁多（二方 APP 多、场景多、环节多、过程复杂），但同属国内业务在一定程度上可以抽象共用。

• 海外业务：目前规模较大的三个 BU 为 AE、Lazada 和 ICBU (International Core Business Unit)，前两个是跨境 C 类商业业务，后者为跨境 B 类。这里的业务特点是类型差异大、方向不同，故国内业务二方互相拉活优势难以利用。此间 AE 重点发展预装和通用引流，在唤端上则全链路弹窗覆盖和建设质量保障体系；而 ICBU 和 Lazada 都以数据驱动上追求小而美在全链路优化、承接性能优化、数据追踪链路可视化投入打磨。此外 ICBU 规模稍小，又有相较不菲的 M 端流量，所以将自身 M 站唤端+外投唤端作为发展重点探索。



接下来本文将结合过往经验，以增长的视角来详细介绍对海外唤端技术发展的探索与理解。

1.2 纵向场景【唤端引流】

简单来说，唤端引流的流程是指将 APP 外部的流量（付费采买/M 站流量/EDM 流量等类型的流量）在二方三方场景（H5/APP）中通过唤端的方式引导到端内并分流到对应的业务场的过程，通过这种方式来帮助端内的业务增长。

特色背景

1）引流方式差异：不同于国内业务，海外跨境 B 类业务在三方流量上围绕 Google/Facebook 为主获取 SEO/PPC/SNS 流量，从联盟引流获取众多中小站点流量为辅的方式，同时在二方上无法依靠国内集团 APP 间互相拉活，只能依靠自有 M 站和 EDM，所以在唤端技术上需要结合渠道的支持能力和自身二方协同考虑。

2）端型定位差异：ICBU 国际站的 M 站端型流量占据全站流量规模的一半，有独立端型发展的业务诉求，并不能像淘系一样，所有 H5 流量都导向 APP 端，需要平衡双端的价值（B 类用户的频率低，易流失）。

业务分类

以一张用户唤端流程图，来说明唤端的业务分类（广义的唤端不仅有唤起，也包括无端下的装机）。

1）站外直接唤起：用户一跳直接从站外源头渠道唤起到 APP，不会经过 M 站，到 APP 端路径最短；

2）站外直接装机：用户一跳直接从站外源头渠道跳到应用市场，进行下载安装激活，直接拉新场景；

3）站内主动唤端：也称显式唤端，通过到 M 站后展示组件（角标和蒙层）的形式，触发唤端流程；

4）站内被动唤端：也称隐式唤端，没有形态，而是隐藏在用户的动线里面触发（如 List->Detail 无感）无需用户决策。

1.3 横向场景【唤端归因】

不同于唤端引流的正向流程，归因本质是逆向的追本溯源过程。通过利用接收到的信息（设备信息、感知信息、内容信息）追溯到源头，做到互联网营销里面的可定向，可追溯。

试想下假设没有归因能力，就只能通过粗放的评估方法进行数据分析，效果衡量，带着固有的认知与局限，优化的方向和结果大多会差强人意，比如粗放式的评估就会面临以下常见问题：

1. 我们知道用户点了这家渠道的广告，但是点了后安装没安装？

2. 这次的下载/唤起量到底是哪家渠道带来的？下次又该买哪家？

3. 除了引流之外，这个后期转化应该算谁的？怎么算更科学更合理？



因此唤端归因能力在不断指导整体优化有重要作用，但这里需要解决以下各种问题来实现目标。

• 渠道场景繁多：海外跨境场景对接的渠道众多，不光有媒体 Facebook 和 Google、众多联盟，还有手机厂商（OPPO，小米）和平台（华为，苹果）技术方案没有直接的银弹；

• 链路存在断层：很多环节存在断层（如用户跳转到应用市场，安装打开 APP）且每个环节都可能存在中断离开；

• 隐私法规政策：近两年从系统平台和法规政策逐步开始提出最大程度的保护用户在使用 APP 过程中的个人信息，对整个广告行业带来影响深远，依赖此的广大媒体渠道和广告主需要拥抱应对。

特色背景

1）应用场景：需要面向众多的渠道背景下具备全集的支撑方案，同时随着增长数据驱动文化的建立，对源头归因数据的诉求众多，在全域归因实时性和采集信息质量上有了更高的要求；

2）成本约束：在 ROI 上有比较高的要求。在可以直接依靠第三方付费平台来实现的方案，考虑到成本和引入后长期架构的不稳定性及政策调整的不可控环节，需要更多的自研突破来实现，同时对降本增效的模式需要投入更多。

业务分类

1）唤端归因：不同场景的归因，包括新用户装机、老用户唤起、从 M 站跨端到 APP 等等的归因，归因到的内容最基础是 Channel 渠道，往上是投放结构（Account、Campaign、AdSet）和站外偏好信息（Category、Product）以及历史入端信息（Time、Content）；

2）场景还原：目的都是提升用户的入端体验，保证 APP 打开后与 M 站/站外渠道广告 看到内容的一致性；包括装机、唤起、回退还原。

二、以增长视角看唤端技术

2.1 价值定位

用户增长方法论很多，涉及领域也较多，这里就不进行展开，而是先从能力构建维度来抽象唤端技术，可以发现几个关键词（通道、载体、追踪、推广），可以看出并非单一而是多维的，是一个兼具纵向和横向的领域，包含流量唤端通道、追踪管控、推动增长的业务



此外技术在做的增长很多时候在做通过数据驱动增长（成功率/转化率/打开率..）不断的降低漏斗，更多的是存量价值带动增长，而对于横向环节增长还有一个关键点是增长策略的挖掘（什么策略能有增量价值带动增长）。没有策略的结合，单独的技术提效带来的增长很快会到达天花板。绝大部分的业务在初期都是完成功能、优化链路，但在后续发展过程中必须是持续沉淀形成策略驱动。

2.2 三个核心诉求

2.2.1 唤端通道能力建设

通道能力的建设是满足唤端业务诉求的基础要求，能够在常规环境下或者借助载体完成唤端，并实现追踪：

• 可唤端：在站内外各类流量来源多场景下完成唤端引流进站功能；

• 可触达：通过弹框/页面等载体形态的方式出现，触达用户唤端进站；

• 可追踪：满足对唤端流量具体到每个用户明细的追踪，完成对多个来源多个场景的实时归因能力。

2.2.2 唤端效率与体验保障

在满足基础诉求后，因唤端流程长、业务场景众多且涉及多团队（前端、客户端、服务端）因此效率和体验上还需要高标准实现，并进行质量保障：

• 唤端效率与体验：需要数据结合分析来摸盘量化整体链路（清楚看到诸如组件曝光率、点击 CTR、应用市场到站率、唤端效率、站外唤起覆盖率、场景还原成功率及耗时、AB 转化率等指标）即是可数字化量化；

• 唤端域质量保障：不同渠道、端型、浏览器下的体验差异也比较大，且技术存在腐化可能，需要通过监控和真机巡检的方式自动化验证及保障。

2.2.3 唤端能力沉淀策略化

随时业务不断发展变化，技术上需要打磨沉淀及突破，抽象形成核心能力，体系化的建设来完善唤端通道并做稳定性保障；业务上需求搭建策略体系满足业务多样化诉求，最大化的带动助力业务，最后还需要数据衡量分析评估价值及定位问题。

2.3 阶段历程及技术策略

流量唤端技术体系的阶段历程是随着 Aliaba.com 国际站业务发展来建立的。每个阶段是以 MVP 最小闭环的模式来跑起来，在逐步实现业务目标增长的同时，沉淀核心技术能力，并完善增长另一关键的策略能力建设，总结来说就是：

唤端推动增长首先要解决的问题是，构建「支撑型唤端技术架构」通过「最小满足」的方式给网站成功引流；

其次，流量唤端是一个比较复杂的体系，所以第二要保障的是「足够高效/智能的系统能力」把链路极致优化，体验良好；

最后，作为不断发展变化的电商赛道，共同性的「能力沉淀」「策略运营」「中心搭建」驱动增长，也是必不可少。

三、B 类唤端技术发展演进

3.1 支撑型唤端架构

3.1.1 多渠道追踪及成本评估能力

关键问题：站外链路因为涉及平台众多，存在大量问题会导致过程信息丢失，无法追踪。例如装机，应用市场环节就是个明显的断层，站外的信息因此无法直接传递到站内；并且因为全球化团队的流量来源众多，方案标准不一，所以较难快速规模化。

解决方案：分两个赛道来做，最终实现多渠道追踪及全数据关联达到渠道成本的可评估。

• 首先媒体流量上通过 Server to Server 对接（渠道若有 API）和纳入业内三方付费归因产品 Appsflyer（渠道若无 API）快速补充核心能力；

• 同时联盟流量上通过自建站内点击系统 ClickServer 扶持接入，打通内外链路，实现多渠道追踪并将粒度做到用户明细维度。

3.1.2 M->APP 跨端功能及归因

关键问题：WAP 端的 UV 规模大但留存差，APP 的留存好但入端成本比较高。双端协同可实现价值更大化，但数据链路部分涉及 M 端、APP 端还有站外投放，都需要全部打通，才能清晰量化价值（避免单端视角下出现左右倒右手的增长）此外协同本身需要有载体来实现。

解决方案：

• 可跨端：在 M 端基于唤端的基础技术开发搭建引流组件和中间页面，吸引用户操作，渐进式让用户跨端到 APP 实现留存；

• 可归因：通过预埋 pageid 和 cna 并基于归因体系，打通 cookieid 和 utdid 的映射关系，进而联通两个端（M 端和 APP 端）不断延展关联三个领域（投放、引流及承接）落地跨端实时还原保障用户体验不中断；

最终满足在数据链路和流程功能上都实现跨端的诉求。

3.2 高效智能唤端系统

前面介绍到"阶段一"完成了架构的快速搭建，可以看出体系是较为复杂，而这随之而来的就是很难衡量好坏。

而通过简单的数据观察（M 站流量规模，跨端装机 APP DAU，不到 1%）及功能体验（跨端部分机型无响应，浮层弹框组件无序、曝光覆盖一半用户干扰大）等现象确认存在问题。但这个分析比较初级，并不能指引方向做进一步分析。

因此以数据驱动模式来体系化推进全链路分析通过公式定义和数据量化整体链路，拆解定义两类共三个问题。具体来说

1）跨端端侧链路，漏斗大存在严重断层

• 跨端效率问题，应用市场跳转装机和唤起 APP 总跨端效率低

• 装机还原问题，到 APP 后跳转装机还原页的成功率不到 50%

2）引流组件问题，组件曝光率高，但用户点击 CTR 低，曝光混乱、强干扰、效果差

3.2.1 高效唤端能力

关键问题：流程复杂和技术链路冗余

• 唤醒链路上，安卓站内唤醒兼容性差，导致出现无反应，又有中间页面，动线长体验不友好；

• 装机链路上，跳转应用市场漏斗大，导致用户流失；

• 还原链路上，通信节点众多、实时性差，用户 5~10s 才出现装机还原页。

解决方案：

• 唤醒兼容方案 Link 技术融合：安卓失败是因为 APP Link 的兼容性(要求版本 6.0 以上)问题，寻找向下的低版本兼容方案，调研后发现应用在 APP 间的唤醒技术 Deep Link 淘系验证兼容性好，可以借鉴在 WAP 跨端 APP 场景，对不支持/低端机型提供 Deep Link 唤醒方式。并实现两种技术融合，解决 Deep Link 原本未装机情况下无反应的问题，保持和 APP Link 一致体验；

• 装机跨端能力前置 &异步化：装机应用市场到站漏斗大是因为中间页有流失，且存在卡死，因此去除中间页。同时系统间多次 302 网络不稳定下通信会断开，客户端降低后端依赖逻辑前置沉淀 SDK，后端全链路内部反向代理，最多出现一次 302；

• 启动初始化提前 &直连通信：首先请求合并精简（将上报和获取两次请求合并，中间环节不必要逻辑都去除，通过缩减链路提升整体可靠性，保障还原成功率）其次调整上报时机，搭建端侧回调能力（参考业内规范，沉淀 SDK，客户端异步初始化，回调注册，失败重试，内部归因完成后推送还原页 URL 到端侧进行跳转）复杂逻辑分离简单化实现，降低维护成本；更早上报更快跳转，保障了体验。

最终效果：

• 通过优化跨端效率提升一倍和国内场景平齐（总跨端 DAU 增长超过一半）；

• 通过优化装机还原成功率接近 100%，页面秒现（10s->1s）推开到 Google 渠道全年营收提升。

3.2.2 智能跨端管控能力

关键问题：拆解数据后发现，站外直接唤端占比少；而站内跨端无智能化管控，百万曝光散乱无序，精细化程度低。

解决方案：

• 扩大已装机用户的隐式唤醒：通过数据分析完善 APP Link 映射，探索站外唤端模式，付费免费主流流量全生效站外直接唤醒；站内流量生效 List-Detail 无感唤醒；

• 降低未装机用户整体曝光率：曝光管控博采众长引入人工干预和算法推荐方案，支持页面级别开关曝光的人工配置；同时历史数据经过建模回流产出规则+算法模型进行推荐；

• 降低未装机用户蒙层点击取消率：算法模型因强制蒙层点击行为不确定性而预测不准，通过数据建模生成宽泛流量特征黑名单规则，根据 CTR 为 0 筛选出覆盖 UV 在 1k 以上的规则黑名单，应用实现强制蒙层不展示效果，结合无扰角标，降低蒙层点击取消率提升 CTR。

最终效果：通过站内无感唤醒铺开+规则及模型推荐实现组件曝光率减少一半以上，CTR 环比提升显著；将站外直接唤起优先的优化全面落地，其占比提升到接近 100%，整体唤端 DAU 增长超过两倍。

3.3 唤端能力策略中心

首先无论是引流还是归因，本身都属于“唤端”体系中的一环，一个纵向的流程一个横向的支撑，而随着 MVP 的体系架构建立，以及通过数据驱动模式全链路优化后，在系统能力层面达到比较高的水位，但对于整体体系，抽象后还有三大不足：

缺失体系化的观测及保障：因为任何事物都非一成不变的，而唤端体系庞大，很多时候关注的都是局部、表面的，会因为视角局限看不到整体变化，特别是在业务变化和技术发展的当下，所以通过技术方式构建完整的数据观测盘点及稳定性保障体系，至关重要。

能力沉淀创新及可开放不足：技术的底座就是核心能力是否强大，是否做到具备未来的可拓展和先进性，特别是在一些共性能力上的打磨，例如能否支持快速接入和对外推广，有没有一些创新，解决一些外部 BU 遇到的难点，能力上的升级要做到对标全球业内。

管理及策略可控性不够：互联网思维告诉我们早期要最小化 MVP，但对于一个承载完整出入端业务流量的唤端体系，需要的是结合业务发展诉求提供可管理可控制可分析能力，不然只是一个横向的体系，留在功能层面，会陷入将承载零碎需求集合不断实现的漩涡，无法反向推广。

3.3.1 唤端能力及策略中心

如何将能力沉淀并做好开放支撑是走向国际化赋能的第一步，因此从保障、能力、配置、策略多个体系完善优化，最终形成了如下体系：

能力体系：

• 开放接入能力：前端/客户端/服务端三团队完成独立 SDK 的打造，基本具备直接接入能力，这里以 JS SDK 为例，新 SDK 拆分了不必要的逻辑大幅瘦身（123k->10k），并对整体流程引入生命周期钩子能力支持业务逻辑自定义和降级处理；同时服务端和客户端也进行了改造，服务端对外一个接口一次通信下发，客户端抽离执行逻辑 SDK 化；

• 唤端追踪能力：集成了和业内 Appsflyer 对标的通信机制/更优的卸载追踪，唤端各类场景实时归因能力，同时实现秒级还原（服务端 RT 控制在 30ms 内）支持跨端多跳还原，会话追踪（每个 Session 归因存储）；

• 唤端引流能力：支持已装机探测（基于 Chrome API），全套唤起基础技术（Deep Link、Universal Links、App Links）融合，并且点击全异步化（弱网断网可继续跳转应用市场）及机型识别。

配置体系：

• 开放接入配置：APP 及 H5 页面的 SDK 引入，协议对接及声明开启；

• 唤端归因配置：支持归因窗口、结果回传配置，并提供 Appsflyer 测试渠道的入驻映射（无需开发）及还原规则配置，按照规则填充信息即可实现装机还原；

• 唤端引流配置：对站外唤端场景提供 AppLinks 映射配置，无需发版可支持新 URL 唤起功能，对组件的出现提供规则（渠道、国家、计划）配置，对布点文案及疲劳度配置。

策略体系：满足不用业务场景诉求差异化唤端，例如选择 Max 唤起引导，则全程开启自动模式，最大化唤端用户到 APP。

载体维度：一部分在站外唤端结合渠道能力提供能力，另一部分为站内的组件及功能承载，都基于 Alibaba OneLink 协议实现。

保障体系：

• 检测规范 &能力：沉淀一套国际电商 APP 通用的规范和全面的检测能力标准，并基于该标准结合业务唤端场景以及唤端 APP 配置文件建设了标准唤醒场景检测、全局配置检测及辅助失败场景定位的自动化能力。

• 标准检测过程：用户通过测试平台进行检测方案配置并触发真机检测，真机引擎依据配置的唤醒页 URL、目标 APP、站内/站外、已装包/未装包、APP 冷热启动等信息进行唤端预处理，依据唤醒标准在唤醒结果的容器层、承接页、还原页、唤端协议等方面进行唤端判断，在唤醒失败的情况下进行系统诊断，最终做整体唤醒结果报告。

• 线上巡检及监控：测试平台根据业务场景并结合海外环境多机型、多网络、多版本进行用例膨胀，开展自动化真机线上巡检，监控真机唤端成功率。同时实现核心指标和执行流程打点全监控，分钟级异常群推送报警。

数据体系：分层设计，构建事实和汇总层数据，同时将应用市场数据回流到站内，提供分析，各分支链路基本实现完善补足。

3.3.2 唤端全渠道场景实时归因

能力背景：唤端归因一直面临着外部的环境约束限制 + 内部数据多维的诉求，而这两者本身就是相斥的，并且在政策趋严和 ICBU 数据驱动文化强化的变化下，越来越难以满足

此前部分依赖三方 Appslfyer 归因，但后来在面临 Facebook 用户隐私限制（不给广告主提供明细数据）以及 IOS 14.5+归因方式的变化由 Apple 来制定下，未来归因能力逐渐走向以操作系统为核心，其次以附着在之上的媒体平台，最后广告主和三方归因来实现，不像此前能力层由三方控制，未来和三方角色类似，完全可以替代，并且在成本和可控性上带来明显收益。

技术策略：

• 归因底层全面自研：实现 Facebook/Goolge/Tiktok/联盟归因...覆盖全渠道，IOS 端型下 SKAN 及 ASA 广告归因；

• 归因深层能力建设：完成实时层面 Organic 归因，并进行 Session 上报的全部追踪归因存储；

• 建立 OneLink 标准：将唤起和装机进行统一设计，接入层沉淀 OneLink 标准（满足不同场景功能诉求的长链、直链及短链）规范化并推动统一，基于 OneLink 将此前唤端优化经验能力有效输出；

• 归因架构大幅升级：点对点通信层重构（归因上报信息统一并精简，场景识别前置到端侧，服务端进行场景+渠道的逐步归因，只一次通信下发，从源头处减少幂等/规避等逻辑）；建设次级归因链路并与主归因拆分隔离（RT 30ms 以内）；优化归因侧反作弊策略及 S2S 发送逻辑，体系合理简化。异常及重复上报率降到 5%以内，下游 S2S 发送重复率降到 1%以内。

3.3.3 安卓卸载离端实时追踪

能力背景：跨境 B 类电商 APP 用户在唤端后留存上都明显弱于 C 类电商，而留存本身是跟频次和心智都相关，此前难点是一直无法清楚知晓用户流失是完全卸载了还是访问低频，因此需要拿到明细的离端卸载数据进行分析清晰化，此外结合入端数据，唤端体系可构建闭环。

而从上图可以看出，卸载过程中本身是文件态的删除，卸载的感知很难，此前还有 APP 自身创建子进程轮询系统文件(系统 log, 安装包目录)状态，但安卓 5.0 后子进程会被杀死，不再适用。而当下实现方案都是基于从外部(其他 APP 及操作系统)感知，由于 AlibabaAPP 面向海外买家，均无法直接使用。

技术策略：国内体系无法实现海外卸载明细归因，基于操作系统底层能力从 0-1 建立 Android 侧实时卸载追踪能力。

• 卸载实时追踪：通过上行反馈方式，对 Alibaba.com APP 用户卸载后可实时归因至 Who When Where，Why ing。

• 装机卸载打通：一对一建立装机-卸载完整映射关系，在离线和实时层面建立数据表及流，用于全站所有业务场景，卸载系统性分析。

四、总结

国际站用户增长技术团队，在唤端技术建设上是一个较为清晰的过程，并没有一开始就搭建全的体系和功能堆叠，而是基于业务发展的诉求不断实现满足->逐步完善的演进：



如阶段一时期：在当时的规模诉求下，最为紧要的是实现唤端的引流和归因支撑流量入端，因此快速搭建支撑型的架构。不仅支撑媒体、联盟流量快速充盈 APP 端规模，同时从 0-1 挖出了 M->APP 跨端增长业务；

而到了阶段二：技术的价值不仅仅体现在支撑业务，可以向前一步，通过数据驱动的模式清晰衡量复杂的体系和链路，追求小而美链路极致优化，这个阶段做了较多数据开发、分析沉淀及内外调研，唤端 DAU 增长超过一半、AB 增长显著；而后找到在唤端效率和曝光管控智能化兼备的演进方向，优化唤起同时降低曝光率提升用户体验，唤端 DAU 增长超过两倍、AB 增长超过一倍；

再到了阶段三：深水区，链路的漏斗优化没有空间，需要在降本增效、策略驱动、创新上进行突破。为了实现这个目标，开始进行能力沉淀和策略中心建设，并且影响业务决策将唤端作为一个重点方向进行全局覆盖和增投，结合差异化策略及横向业务赋能带来了唤端 DAU 及 AB 增长超过一半；而后在核心归因技术上全面自研，同时离端卸载完成追踪，实现出唤端追踪闭环。

下一阶段规划已初步清晰，将在唤端引流、归因、策略中心层面不断进行完善，并将能力横向全域输出，推动更多业务及场景实现增长。

仰望天空，脚踏实地；将继续探索创新，期待未来做的更好。