|
作者：黄昭 阿里ICBU买家增长技术团队
近几年用户增长行业APP推广发展迅猛，而唤端便是其中的重要技术。经过唤端拉新/促活不仅能能够将三方流量规模做大，同期二方流量亦能有效利用，给网站持续带来商机，本文将为大众仔细介绍阿里国际站在唤端技术的探索与演进。
1、背景
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 横向场景【唤端归因】
区别于唤端引流的正向流程，归因本质是逆向的追本溯源过程。经过利用接收到的信息（设备信息、感知信息、内容信息）追溯到源头，做到互联网营销里面的可定向，可追溯。
试想下假设无归因能力，就只能经过粗放的评定办法进行数据分析，效果衡量，带着固有的认知与局限，优化的方向和结果大多会差强人意，例如粗放式的评定就会面临以下平常问题： 咱们晓得用户点了这家途径的宣传，然则点了后安装没安装？这次的下载/唤起量到底是哪家途径带来的？下次又该买哪家？除了引流之外，这个后期转化应该算谁的？怎么算更科学更恰当？因此呢唤端归因能力在持续指点整体优化有重要功效，但这儿必须处理以下各样问题来实现目的。 途径场景繁多：海外跨境场景对接的途径众多，不但有媒介Facebook和Google、众多联盟，还有手机厂商（OPPO，小米）和平台（华为，苹果）技术方法无直接的银弹；链路存在断层：非常多环节存在断层（如用户转到应用市场，安装打开APP）且每一个环节都可能存在中断离开；隐私法规政策：近两年从系统平台和法规政策逐步起始提出最大程度的守护用户在运用APP过程中的个人信息，对全部宣传行业带来影响深远，依赖此的广大媒介途径和宣传主必须拥抱应对。
特殊背景
1）应用场景：必须面向众多的途径背景下具备全集的支撑方法，同期随着增长数据驱动文化的创立，对源头归因数据的诉求众多，在全域归因实时性和采集信息质量上有了更高的需求；
2）成本约束：在ROI上有比较高的需求。在能够直接依靠第三方付费平台来实现的方法，思虑到成本和引入后长时间架构的不稳定性及政策调节的不可控环节，必须更加多的自研突破来实现，同期对降本增效的模式必须投入更加多。
业务归类
1）唤端归因：区别场景的归因，包含新用户装机、老用户唤起、从M站跨端到APP等等的归因，归因到的内容最基本是Channel途径，往上是投放结构（Account、Campaign、AdSet）和站外偏好信息（Category、Product）以及历史入端信息（Time、Content）；
2）场景还原：目的都是提高用户的入端体验，保准APP打开后与M站/站外途径宣传 看到内容的一致性；包含装机、唤起、回退还原。
2、以增长视角看唤端技术
2.1 价值定位
用户增长办法论非常多，触及行业亦较多，这儿就不进行展开，而是先从能力构建维度来抽象唤端技术，能够发掘几个关键词（通道、载体、跟踪、推广），能够看出并非单一而是多维的，是一个兼具纵向和横向的行业，包括流量唤端通道、跟踪管控、推动增长的业务
另外技术在做的增长非常多时候在做经过数据驱动增长（成功率/转化率/打开率..）持续的降低漏斗，更加多的是存量价值带动增长，而针对横向环节增长还有一个关键点是增长策略的挖掘（什么策略能有增量价值带动增长）。无策略的结合，单独的技术提效带来的增长火速会到达天花板。绝大部分的业务在初期都是完成功能、优化链路，但在后续发展过程中必要是连续沉淀形成策略驱动。
2.2 三个核心诉求
2.2.1 唤端通道能力建设
通道能力的建设是满足唤端业务诉求的基本需求，能够在常规环境下或借助载体完成唤端，并实现跟踪： 可唤端：在站内外各类流量源自多场景下完成唤端引流进站功能；可触达：经过弹框/页面等载体形态的方式显现，触达用户唤端进站；可跟踪：满足对唤端流量详细到每一个用户明细的跟踪，完成对多个源自多个场景的实时归因能力。
2.2.2 唤端效率与体验保证
在满足基本诉求后，因唤端流程长、业务场景众多且触及多团队（前端、客户端、服务端）因此呢效率和体验上还必须高标准实现，并进行质量保证： 唤端效率与体验：必须数据结合分析来摸盘量化整体链路（清楚看到诸如组件揭发率、点击CTR、应用市场到站率、唤端效率、站外唤起覆盖率、场景还原成功率及耗时、AB转化率等指标）即是可数字化量化；唤端域质量保证：区别途径、端型、浏览器下的体验差异亦比很强，且技术存在腐化可能，必须经过监控和真机巡检的方式自动化验证及保证。2.2.3 唤端能力沉淀策略化
随时业务持续发展变化，技术上必须打磨沉淀及突破，抽象形成核心能力，体系化的建设来完善唤端通道并做稳定性保证；业务上需求搭建策略体系满足业务多样化诉求，最大化的带动助力业务，最后还必须数据衡量分析评定价值及定位问题。
2.3 周期历程及技术策略
流量唤端技术体系的周期历程是随着Aliaba.com国际站业务发展来创立的。每一个周期是以MVP最小闭环的模式来跑起来，在逐步实现业务目的增长的同期，沉淀核心技术能力，并完善增长另一关键的策略能力建设，总结来讲便是：
唤端推动增长首要要处理的问题是，构建「支撑型唤端技术架构」经过「最小满足」的方式给网站成功引流；
其次，流量唤端是一个比较繁杂的体系，因此第二要保证的是「足够有效/智能的系统能力」把链路极致优化，体验良好；
最后，做为持续发展变化的电商赛道，一起性的「能力沉淀」「策略运营」「中心搭建」驱动增长，亦是必不可少。
3、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 唤端能力及策略中心
怎样将能力沉淀并做好开放支撑是走向国际化赋能的第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。装机卸载打通：一对一创立装机-卸载完整映射关系，在离线和实时层面创立数据表及流，用于全站所有业务场景，卸载系统性分析。
4、总结
国际站用户增长技术团队，在唤端技术建设上是一个较为清晰的过程，并无一起始就搭建全的体系和功能堆叠，而是基于业务发展的诉求持续实现满足->逐步完善的演进：
如周期一时期：在当时的规模诉求下，最为紧要的是实现唤端的引流和归因支撑流量入端，因此呢快速搭建支撑型的架构。不仅支撑媒介、联盟流量快速充盈APP端规模，同期从0-1挖出了M->APP跨端增长业务；
而到了周期二：技术的价值不仅表现在支撑业务，能够向前一步，经过数据驱动的模式清晰衡量繁杂的体系和链路，追求小而美链路极致优化，这个周期做了较都数据研发、分析沉淀及内外调研，唤端DAU增长超过一半、AB增长明显；而后找到在唤端效率和揭发管控智能化兼备的演进方向，优化唤起同期降低揭发率提高用户体验，唤端DAU增长超过两倍、AB增长超过一倍；
再到了周期三：深水区，链路的漏斗优化无空间，必须在降本增效、策略驱动、创新上进行突破。为了实现这个目的，起始进行能力沉淀和策略中心建设，并且影响业务决策将唤端做为一个重点方向进行全局覆盖和增投，结合差异化策略及横向业务赋能带来了唤端DAU及AB增长超过一半；而后在核心归因技术上全面自研，同期离端卸载完成跟踪，实现出唤端跟踪闭环。
下一周期规划已初步清晰，将在唤端引流、归因、策略中心层面持续进行完善，并将能力横向全域输出，推动更加多业务及场景实现增长。
仰望天空，脚踏实地；将继续探索创新，期待将来做的更好。
| 
发表于 2024-8-1 16:27:14