什么是QR码付款小程序？
美团扫描QR码小程序是面向C端消费者的离线获取服务。它受美团小程序委托。在实际情况中，用户首先使用微信扫描商家的QR码，然后将QR码调整为小程序进行支付，进入支付页面并输入金额以完成带有已支付商户商品的产品。
提高QR码付款小程序的付款转换率。这里提到的付款转换率是指在整个业务流程中成功支付了扫描代码费用的用户百分比。在支付转换率和二维码支付业务方面，百分比越高，二维码支付业务的收入就越高，带来的收入就成比例。
这部分转化率损失的影响被认为包括两个部分：
扫描代码以进入小程序链接（外部链接）
在付款链接（内部链接）中输入小程序
扫描代码并输入小程序的链接后，微信将完成诸如小程序基本信息获取和资源准备（代码下载或更新）的准备工作。如果准备失败或时间过长，将导致用户手动离开。 微信控制的链接的这一部分称为外部链接；从输入小程序到支付链接，将呈现页面，数据请求等，如果呈现时间长，则数据请求时间也容易引起用户手动离开，并且数据请求失败也将导致用户终止使用过程并离开。由我们自己控制的链接的这一部分称为内部链接。
如何提高外部链接的转换率？
对于小程序开发人员，将QR码扫描到小程序是一个黑匣子，我们在这里不知道详细信息。在扫描代码付款小程序中，我试图与微信中的学生进行梳理，发现扫描代码付款小程序在外部链接中的丢失率更高。查询数据发现，大多数用户手动单击右上角的退出。从业务的角度来看，使用扫描代码付款的用户可以认为用户对付款的需求很高。导致用户手动单击注销的部分原因可能是由于等待时间较长，并且此链接中的时间影响是更多的资源准备工作是下载或更新小程序代码的行为。
影响下载和更新时间的可能因素是：
网络
代码包
用户网络不在我们的控制范围内，只能尝试从代码包开始。那时不使用子软件包，则主软件包的大小约为3M，这意味着新用户和未缓存的小程序用户在初次使用时都需要等待下载大约3M的软件包用它。在这种情况下，尽管用户失去了小程序脱机缓存程序包的好处，但是却失去了大多数新用户的体验。因此进行了一些优化：
添加子包加载机制。当用户使用QR码付款服务时，他们会按需加载它们，以优化小程序首次启动时的下载时间。
减小主包装和子包装的尺寸。根据空主程序包的概念进行优化。子程序包加载机制之后，主程序包无法最小化，仍然会影响首次下载时间。一方面，在原始的3M包装中，图像尺寸占尺寸的50％。我们分发了CDN中包含的所有二进制和Base64映像。另一方面，可移动业务的一部分已分配给其他分包合同。
完成这些操作后，扫描代码支付分包从原来的3M包减少到361k（主包300k +分包61)），外部链接的转换率也提高了3％。转换率虽然有所提高，但前环节的转换率仍然损失了一部分，理论上继续减少300k的主包可以有效提高，但是由于业务的性质，不能继续降低微信小程序提出了独立转包的概念：使用独立的子包时，用户无需下载主包，通过独立的子包加载，在下载和更新阶段仅需加载61k的子包大小。目前，此功能仍处于内部测试阶段，并且还提供了扫描代码小程序作为第一批内部测试用户，其优化效果将在su中共享。惯常做法。
如何提高内部链接的转换率？
输入小程序付款是一个业务流程。尽管可以控制此链接中转换率的损失，但我们已经进行了一些数据监视以找到一种方法：
核心业务流程监控。核心业务流程是指在用户输入小程序之后影响最终付款的中间流程。中间流程的损失直接影响整个业务转换率的损失，因此必须对其进行监视。核心业务流程监控需要可以监控的特定指标。分解了输入小程序和付款的关键操作，从扫描代码到查看页面的用户，然后单击付款，初始化订单并成功付款。拆除这些关键操作后，请拆除可控制链接每一步的技术指标。在从入口到出口的每个步骤中，制定关键指标（扫描代码加载转换率，点击意愿等，请参见下图），形成自上而下的渠道，并输出多个可量化的指标来监控业务流程。对于这部分可量化的指标，可以通过长期观察和分析来提高转化率。
异常监视。页面的任何异常都可能导致支付页面的呈现失败，并且无法正常进行支付。我们监视了页面的接口异常和微信 API异常。接口异常可以直接在API的故障功能（wx.request）中捕获，以报告给监视。对于接口超时，您只能通过全局app.json（默认值为60s，时间太长，并且用户体验较差）来全局设置它们，我们尝试在小程序中设置全局5s请求超时，但是在实际应用中，所有方案都需要设置统一的超时时间。最后，我们分别封装了接口请求超时。 微信 API异常可以通过微信的某些故障进行监视。
性能监控。 小程序内部转换链接着重于输入小程序后的白屏时间和交互时间。内部白屏时间从onLoad开始，到onReady页面结束；内部互动时间从onLoad到kjnpl0o09o0到页面数据请求结束后可点击支付时间的结束。
在日常监视中，还发现了一些问题，例如接口调用超时，接口调用失败，这些问题将导致页面流终止。针对这些问题，我们进行了一些优化：
接口合并。付款页面上有大量的外部网络链接接口请求，任何接口的故障都会引起问题。组合接口可以减少出现问题的可能性，并提高中间过程的转换率。
添加重试机制。如果出现接口异常，则将直接导致页面被阻止。如果重试成功，则可以提高转换率。整个过程中有两种重试类型：
自己的界面请求异常
小程序 API调用异常
对于这两种类型的异常，当接口超时或调用失败时将重试。为了避免服务器流量的急剧增加和在极端情况下峰值倍数的增加，在预先获得全局配置时，将根据“重试次数”控制页面上的重试次数，并且每次重试需要在一段时间后由用户手动触发。当超过重试次数时，该过程终止。
如何监视内部和外部链接？
如前所述，对于小程序开发人员来说，扫描到小程序的链接是一个黑匣子，并且开发人员无法在此处了解详细信息，因此就监视外部链接而言，开发人员似乎几乎没有什么可以做的做。但是，我不知道是否有细心的学生发现微信会在每次扫描后将scancode_time字段附加到查询参数。实际上，此字段代表用户使用扫描微信时服务器记录的时间，因此基于对该字段的考虑，已做出以下尝试来实时监视以下两个参数值：
付款页面的白屏时间（用户看到第一个屏幕时的客户端时间-用户微信扫描服务器时间+服务器客户端差异时间）
付款页面的用户交互时间（页面加载完成时间-用户微信扫描服务器时间+服务器客户端差异时间）
提示：由于客户端的时间戳是获取本地移动电话系统的时间，因此可能有所不同。因此，为了确保报告的准确性，每次onLoad都会占用服务器时间，并记录客户端时间和服务器时间之间的时差，并参考该时间计算出服务器的所有后续时间。差异（网络 100-200ms级的传输延迟可以暂时忽略）
但是，由于QR码支付小程序的特殊应用场景是确保用户进行快速可靠的支付，由于外部链接的可控性不高，我们可以考虑在内部业务流程中进行监视和统计吗？更详细地说，您是否可以跟踪可能影响付款的每个链接的数据？在这个方向上，与传统的PV和UV统计数据不同，业务报告的分类如下：
根据报告的场景划分：实时监控部分和统计部分
根据报告的类型：错误类型，事件类型（正常生命周期事件），度量标准类型（自定义事件类型，尺寸可以自定义），自定义速度测量类型（延迟趋势和分布）
基于对上述解决方案的探索，团队基本上设法控制了可能影响支付链接的某些业务指标。因此，下一步，可以对每个潜在的优化点进行进一步的思考和考虑，并及时进行策略的优化和更新。
摘要
通过探索QR码付款小程序，我们积累了宝贵的优化经验，但是我们需要进一步探索可以优化的方面。