解决方案:如何建立起一套有效的APP监控体系

　　解决方案:如何建立起一套有效的APP监控体系

　　介绍：

　　手机APP有其独特的运行环境和使用场景。 与后端服务相比，手机APP的质量也需要做到可见可控。 手机APP是近几年才兴起的一种新的产品形态。 如何保证手机APP的质量是一个新的挑战和课题。 今天，我们将重点介绍如何在APP端发现、定位、止损，以及如何建立有效的监控体系，为APP的稳定应用保驾护航。 分为“终端问题概述、终端质量监控方案、终端监控能力建设”三章。

　　1 面问题概述

　　应用客户端产品上线前，会经过全面严格的测试后，才会上线应用商店。 然而，过去产品发布后的质量更多地依赖于用户的反馈。 对于大型APP产品，测试人员无法覆盖所有手机型号和ROM。 在这种情况下，如何知道用户手中的产品质量好坏？ 这时候就需要一个全面的质量监控方案来建立一个坚实的监控体系。 这样就可以第一时间召回线上产品的APP质量问题，快速修复。

　　1.1 常见问题

　　1.适配问题

　　在客户端测试过程中，测试工程师会覆盖目前主流厂商的机型和ROM，以及市场上使用人数较多的android/ios版本。 不过毕竟不能覆盖市面上所有的机型和ROM，尤其是android系统的手机。 因此，用户下载APP后，经常反映手机页面丑陋，部分文字甚至重叠，控件位置显示不正确。

　　举个实际问题，在上线时，收到用户反馈，部分页面卡顿，容易导致误点击。 用户使用的机型是比较主流的*敏*感*词*顿。 暂停。 研发人员针对卡顿问题进行了适配。 这样的案例证明，需要保持对主流手机和ROM更新的高品质敏感度，时刻关注厂商升级。 快速响应，适时适配主流机型和ROM。

　　2.用户体验问题

　　通常，产品经理在设计产品功能时，不一定会考虑周全。 他们往往抱着试错的心态设计产品，希望通过用户的反馈了解产品的质量和用户进一步的需求。 一不小心，往往是在取悦部分用户的同时，伤害了部分用户。 举一个实际的例子，对于某个搜索产品，产品经理增加了夜间浏览模式的功能，让用户在夜间浏览时有更好的视觉体验。 为方便用户设置夜间模式，产品设置在晚上20:00后自动弹出浮层，询问用户是否设置夜间模式，一键设置，方便用户开启夜间模式。 但是，产品经理忽略了一个重要的问题。 用户晚上开启夜间模式后，第二天早上如何轻松切换回白天模式？ 而且产品早上也没有设置浮层做一键切换。 这样一来，很多用户在白天也开启了夜间模式，体验非常糟糕。 问题在于虽然有切换回day模式的功能，但是入口比较隐蔽，用户很难找到。 从这个问题可以看出，产品体验是设计出来的，需要在用户的实际应用中进行检验。

　　3、交通问题

　　目前中国的4G资费与欧美日韩相比还是比较高的。 同时，免费公共wifi覆盖率不高，用户非常关注非wifi下的移动流量消耗。 那么，一款移动APP产品如何用最少的流量提供更多的功能呢？ 通过客户端缓存是一种常见的技术。 举一个实际的例子，以小说阅读为例。 小说目录一般会列出很多书籍供用户选择。 这些书籍一般由书名、资料封面图片和书籍介绍组成。 一个页面的数据是150kb，这个页面是小说书单的主入口，所有对小说的操作都必须从这个页面开始。 如果用户反复请求这个页面，不仅会造成流量的浪费，还会给服务器带来很大的请求压力。 为此，该页面的数据缓存在客户端本地。 如果用户在非wifi网络下不发送请求，如果用户在wifi网络环境下每隔一定时间向服务器请求数据，然后删除旧数据，并在本地写入新数据，这样用户就可以得到最新内容。 这样一来，不仅解决了流量问题，也解决了一些低端手机本地内存不足的问题。 从这个角度来说，在设计产品的时候，要站在用户的角度去考虑问题。 用户不一定能直观地感知到，但实际上增加了用户体验，减少了不必要的流量消耗。 你怎么会那么说？ 为什么不。

　　1.2 问题特征

　　上一节描述了三类常见问题。 有些问题比较容易复现和解决，有些问题比较难。 举几个例子：

　　场景一：用户反映在WIFI网络下无法发起搜索，搜索结果异常。 在WIFI环境下，无法重现用户反映的问题。 这时候往往归咎于网络的不稳定。 但是，用户当时可能确实遇到了问题。 这种无法稳定复现的问题，往往归结为偶发问题。

　　场景二：用户反馈为什么离线下载的小说有时还需要联网。 由于用户的线下小说是连载小说，当用户阅读完线下内容后，假设此时小说有更新，产品经理将产品设计为联网发送在线请求继续阅读为了让用户继续阅读。 与用户的认知相反。 但是，如果用户看完了线下部分，看到书还没看完，用户也会关心为什么没有新的内容。 类似的问题归结为长尾问题，需要通过不断优化产品策略来解决。

　　APP运行在用户手机上，连接后台服务。 许多质量问题也有其独特性。 因此，需要采用不同的手段来实现问题的发现、定位和修复。

　　1.3 挑战

　　对于上面提到的问题，你可能会问：如何发现这些问题，如何判断是否立即修复这些问题，哪些问题是长尾问题？ 这就是下面要介绍的召回线上issue的方法和issue影响的评估。 用户反馈是召回问题的一种方式，但这种被动召回方式不足以满足在线问题快速召回的要求，因此构建完善的监控系统非常必要。

　　1. 监测挑战

　　对于客户端产品，一旦发布，就很难有效控制产品质量。 为此，产品经理和数据分析师经常在产品发布前提出监控统计需求，研发工程师开发设计监控统计代码，将用户行为、产品崩溃等核心质量信息以日志的形式上传在服务器端，这些用户产生的数据为后续分析产品和质量问题提供了原创数据基础。

　　2、影响判断

　　利用客户端上传的用户日志和客户端崩溃信息进行统计分析。 结合在线提问，可以进行影响评估。 影响评估主要分为三类，包括严重问题、特定场景反复出现的问题和不影响主要功能的问题。

　　1）严重问题一般是需要发小版本修复的问题

　　2）具体场景的复现问题小版本一般不会修复，但下个版本肯定会修复

　　3）不影响主要功能的问题将根据下一版本的时间安排进行修复或删除

　　2端质量监控解决方案

　　由于APP载体种类繁多，产品质量问题的表现形式多种多样。 我们以最常见的APP为例，总结如下：

　　- APP产品依赖的后端服务问题

　　- 来自APP产品本身的问题，包括稳定性问题，表现为：应用崩溃（crash）、ANR（APPlication Not Responding）、网络错误、请求响应时间过长、用户交互不流畅、机型、ROM适配不够兼容性引起的问题。

　　- 从APP与后台服务的链路问题来看，通常是：网络问题导致的丢包、TCP重传等。

　　对于APP质量监控，可以从问题发现、问题定位、问题止损三个方向布局完善的监控体系。

　　2.1 问题发现

　　由于APP受用户机型、手机ROM、网络环境、用户操作路径等差异影响较大，QA无法保证在测试阶段会暴露所有问题。 这就需要我们建立线上问题发现系统，及时召回已经投递到线上的移动产品。 一个完整的在线问题发现系统，通常需要基于产品的核心业务，抽象出核心指标，实现指标的量化； 制定质量标准，实时监控报警。

　　根据我们的经验，APP应用的质量指标包括但不限于：安装成功率、崩溃率、ANR率、网络错误率、请求响应时间等，质量指标与具体的应用功能密切相关。 从理论上提取指标后，如何量化是最关键也是最难的一步。 量化需要一种有效的方法来获取问题信息。 日志埋葬是一种很常见的方法，另外一种方式，用户反馈，同样重要，尽管它经常被开发者忽略。

　　2.1.1 用户反馈：海纳百川

　　一款应用想要在应用市场中分得一杯羹，并长期留住用户，需要依赖良好的应用功能和产品体验。 用户反馈代表了市场对本应用的满意度，可以直接反映用户的判断和诉求。 也是本APP迭代改进的第一手资料。 前期我们可以通过市场调研等方式获取反馈，但是受限于人力和时间成本，在用户量巨大的时候我们很难复用这种方式，或者市场调研只能抽样但不能完全覆盖。

　　

　　综上所述，只有提供一个入口，让所有的用户反馈都像江河一样流入大海，汇聚一处，才能获取不同地域、不同网络、不同机型、不同场景的用户反馈，然后聚类并分析它，改进我们的产品。

　　用户反馈的一般方法没有太多新意。 市面上很多手机应用都会在应用设置页面附上用户反馈入口，如图2.1，百度云和爱奇艺视频的用户反馈界面。

　　我们要明白，在如今快节奏的生活中，如果一个用户愿意提交反馈，这个问题对他/她来说一定是个大问题，他/她是一个比较忠诚的用户，同时有希望这个应用程序，希望开发人员可以改进它。 所以一旦这个产品开始提供更稳定或者功能更丰富的收费服务来尝试变现，那么这部分用户将是最大的潜在群体。

　　一个普通的用户反馈页面就是细微处见真情的最好例子。 这两个页面的设计告诉我们用户反馈的重要原则：

　　下面介绍几个常用的用户反馈平台：

　　1）美茶，基于HTML5开发，只需要在支持H5的IOS/Android浏览器中打开，无需安装任何软件程序，代码植入，一步到位，简化沟通流程。

　　2）Udesk：支持Android、IOS、APIcloud三大平台，可对用户反馈数据进行统计分析并展示结果。

　　3）Freshdesk，一家致力于中小企业网站在线客服技术支持的网站，为中小企业网站提供在线服务质量和用户体验。

　　除了在应用中直接反馈，还可以创建用户群（QQ、微信或其他企业级IM），第一时间发现严重问题，直接与用户沟通，协助复现，捕捉问题现场信息。 问题定位和解决至关重要。

　　2.1.2 埋木点：调马奋战

　　在移动应用程序设计之初，开发人员通常会考虑功能、架构和开发周期等问题。 这类问题通常会直接影响到应用的发布周期，但人们往往会忽略一个重要的过程，那就是日志埋点。

　　你为什么要埋它

　　毕竟通过用户反馈发现问题有一定的延迟性，甚至有些线上的问题也会屏蔽用户反馈，比如：持续频繁的崩溃，用户反馈模块本身的bug。 为了更快、更及时地暴露问题，我们需要主动获取用户操作的关键信息。

　　埋在哪里

　　原木埋点的原理：好的埋点可以达到一人在手，万人不开的效果。 我们需要的所有信息都以日志的形式打印出来，选择性或全部上传到应用的后台服务，用于支持问题发现或服务改进。

　　受限于APP应用的运行环境，我们不可能到处埋点。 在多年的软件开发和维护过程中，笔者也看到过因日志添加不当导致程序崩溃的问题。

　　根据我们自己的经验，我们总结了以下关于原木掩埋的建议：

　　1）目标驱动埋点：一个移动应用，开发者或用户想知道的服务指标，必须通过日志埋点来解决；

　　2）常用的日志框架：第一版应用在日志框架上花费的时间直接影响后续版本的开发效率。 通用性和稳定性是这个框架必须要考虑的问题。

　　3）日志上传：对于已经获取到的埋点日志，我们要考虑其对用户流量和交互流畅度的影响——毕竟它的上传使用的是用户网络，尤其是付费移动网络下。 . 有以下方法可供参考： 日志压缩和私有协议，使用样本上传而不是全程监控； 如果日志对时效性要求不高，可以考虑打包整体上传而不是实时上传，甚至一天上传一次。 这些都需要提前部署到框架中。

　　4) 日志安全：用户日志可能收录用户个人信息、用户行为和隐私。 一旦信息泄露，可能给用户造成经济和安全损失，严重影响用户对应用的信任。 因此，日志安全是重中之重。 目前有效的方法主要包括加密和使用安全协议。 与加密算法更容易被破解的风险相比，安全协议提供了更严格的保护。 目前广泛使用的安全协议主要有https、spdy等。

　　2.问题定位

　　线上问题的快速定位和解决，可以直接缩短用户体验受损的时间。 通常有以下定位思路：

　　1）日志分析法

　　遇到问题，我们可能首先想到的就是查看日志。 用户日志是最直接的信息来源和定位问题的方法。 日志分析可以分为两种方法：一种是从统计的角度分析大量的问题日志，归纳聚类，通过其独特的特征发现潜在的问题； 报告问题的用户可以查询自己一段时间内所有的操作过程和结果，通过上下文推测问题的原因，也可以辅助离线复现。

　　当然，并不是所有的问题都可以通过用户日志来定位。 例如，日志不完整，或者日志提供的信息不足以准确定位问题。 我应该怎么办？ 然后我们需要能够重现这个问题。

　　2）问题复现法

　　根据用户对问题的描述和已有的用户日志，尝试离线复现。 重现时需要注意用户的机型、平台、网络类型、是否设置代理，甚至用户所在的地理位置（不同地区运营商网络可能差异很大）等，结合应用程序提供的服务的逻辑， 推测问题可能的原因并最大限度地提高再次发生的可能性。

　　3）推测验证法

　　当然，APP的问题很大程度上取决于当时的问题环境，包括机型、平台、网络情况、手机安装的应用等，这些都给线下复现带来了很大困难。 但是现有的问题日志不足以准确定位。 遇到这种情况，可以通过问题的描述和已有的日志来推测可能的问题原因，并对隐藏点进行监控。 通过分层发布模式，当问题再次出现时，验证哪个猜测是根本原因。

　　4）上下游合作分析

　　有些功能需要多方合作。 当这些模块出现问题的时候，大家一起努力，可能离解决问题又近了一步。

　　3.问题止损

　　线上问题无时无刻不在影响着用户体验，需要及时止损。 问题止损不仅是定位问题的根源，实现彻底的解决，还包括在问题没有彻底解决之前，如何将对用户的不利影响降到最低。

　　对于APP产品，不能像后台服务那样通过紧急下线/在线补丁解决问题，只能靠应用的发布，用户的升级和转化也是一个比较漫长的过程。 在这种困境中，云控和热修复给我们带来了曙光。 下面主要介绍云开关控制的思路。

　　对于对APP影响/风险较大的功能模块，提前设置开关。 出现问题时，可通过云端下达关机指令，及时止损。 云控制是一个概念，其实现因业务和功能而异。 受限于自身经验，我们无法提供通用的多平台解决方案，但道路越简单越好。 提醒开发者：从代码设计开始，从应用、系统、服务三个维度考虑容灾。

　　

　　一个简单的例子：我们可以把功能开关放在一个独立的Web Server中，APP使用轮询或者更精确的动态策略来访问这个静态文件。 当服务的某个环节出现问题时，您只需通过修改文件、关闭相关功能或将相应服务指向备用地址等方式，即可快速止损。

　　另一种方法与上述方案类似，只是实现时不使用访问云端文件，而是服务器直接向所有APP应用发送指令，启动和停止某些功能，甚至调整某些内部模块的逻辑。 这种方式比较直接，但是对APP代码的开发提出了相当高的要求：

　　1）模块之间的代码耦合度要极低，以便逻辑可以动态调整；

　　2）如果云控仅用于意外止损，则所有受影响的应用必须保持后台在线或前台运行。 但是，对于目前市场份额最大的手机/移动操作系统，我们可以通过推送通知的方式，尽可能让用户激活应用，从而获得下发云指令的机会；

　　我们建议开发者综合考虑应用的代码风格、业务类型、风险类型来选择止损方案。 以上两种方案都不是最优方案。 在实际开发过程中，可能需要集成多个方案来满足高可用服务标准。

　　同时，业界也出现了一些成熟的解决方案。 例如iOS平台的APP动态更新服务JSPatch()就是一个专注于该领域的平台，开发者可以尝试借鉴。

　　3 监控系统建设

　　3.1 质量标准

　　一、质量标准是什么：

　　质量标准是产品生产、检验和质量评价的技术依据。 产品质量特性一般用数量表示，如强度、硬度、化学成分等； 所谓标准，是指衡量某一事物或某项工作所必须达到的层次、规模和规定。 规定产品质量特性应符合的技术要求称为“产品质量标准”。 ——（百度百科）

　　客户端是直接与用户打交道的产品，其用户体验是衡量一个客户端的重要一环。 用户体验包括视觉、友好性、易用性等方面。 但是，它的视野等方面是很难量化衡量的。 但产品的核心功能是通过一些数据的衡量来衡量产品的易用性。 因此，产品质量标准应运而生。

　　在服务类产品中，SLA（Service-Level Agreement）常被作为衡量产品服务水平的量化指标。 根据业务的需求，对业务的业务和服务指标进行量化标准，用量化的标准去衡量和驱动产品的服务越来越好。 例如，APP产品的崩溃率是衡量APP稳定性的数据指标。 通过对崩溃率统计数据的测量和分析，保证APP各发布版本的健壮性。

　　2、质量标准应如何制定：

　　质量标准的目的是通过业务数据的量化和度量来保证服务质量，通过质量标准的度量来促进业务质量越来越好。 那么我们应该如何制定质量标准呢？

　　根据百度云的经验，质量标准的制定大致可以概括为：一个核心，三个阶段：

　　一核：始终以产品线的业务发展为核心

　　三个阶段：早期、中期和晚期

　　为什么质量标准的制定要围绕发展来制定。 比如百度钱包。 钱包在起步阶段，其核心业务指标是开发用户。 那么用户的登录、日活等指标就是钱包最核心的指标。 当时钱包还没有APP端。 有崩溃率等标准。 当钱包发展到一定阶段，绑定卡用户成为钱包的另一个核心指标。 那么帮卡率就成为了业务的核心发展指标。 相应的核心质量标准也应该成为卡绑定的成功率。 因此，质量标准的制定必须着眼于企业的发展。

　　在业务发展的不同阶段制定和采用的质量标准也不同。 按照由粗到细的标准，量化难度由易到难逐步发展。

　　初始阶段：在业务发展初期或业务发展到一定阶段后，通过需求或用户反馈采集产品线在发展过程中需要保障的top功能。 这一核心功能是产品生存的支柱，也就是说，需要我们的质量标准来衡量我们核心业务的交付情况。 比如客户的死机情况，就是每个产品线必须要保证的最基本的质量防线。 崩溃率的高低决定了用户的留存。 因此，所有的产品线都应该以崩溃率作为最基本的质量标准。 并且对于不同的产品线，他们有自己的核心业务指标，比如手百，断链是最核心的与用户体验相关的指标； 下载成功率是百度云用户体验最核心的指标； 定位和路线的准确度是地图的核心用户体验指标。 这些是最初建立质量标准时与每种产品最相关的说明。

　　中期阶段：在中期阶段，在初始阶段的质量指标确立之后，指标的数据获取和指标的计算公式经过测试（特别是同行角色认可）之后，它进入成熟阶段。 中期阶段的目标是建立多个完整的子服务质量闭环。 客户端呈现给用户的服务能力和用户体验是各个业务的综合能力体验，这与客户端自身的业务、服务端的服务能力、中间网络的抖动密不可分。 因此，一个服务单元要实现完整的质量闭环，必须能够覆盖到整个业务链条上的每一个质量节点。 比如百度云的下载业务，一个完整的下载，从层级来看，大致可以分为三个层次： 1、APP自身的下载逻辑，主要涉及下载重试、并发、容错等 2 .中间业务层，主要是下载过程中的下载分发、防盗链、PASS验证、CDN回源等。 3、底层数据抓取，主要是碎片化数据的文件重组、跨机房抓取等。因此，要完成整个下载的质量闭环，必须覆盖整个质量闭环的关键节点。 每个关键节点都会规定对应节点的标准，每个节点的质量变化都会反映到终端的质量数据中。

　　高级阶段：高级阶段是在中间阶段相对成熟之后，各个业务复杂的子业务可以通过服务单元中的核心节点数据来评估质量。 在高级阶段，每个细节的标准都非常全面。 凡是影响产品体验和客户端运行质量的，都可以通过数据分析得到。 中期阶段，有了各个垂直业务的数据，以及垂直链条上关键节点的数据，就可以清楚地知道垂直业务的好坏。 对于更复杂的业务，每个质量节点影响的不仅仅是一个垂直业务。 在高级阶段，通过详细的子业务和子业务之间的关系的连接和描述，形成一个链接的质量网络。

　　3.质量标准的用处：

　　制定质量标准的主要目的是通过质量标准的驱动来提高服务质量。 质量标准按覆盖范围主要分为两类：一类是通用的，比如崩溃率； 另一个与自己的业务密切相关。

　　1）质量标准的主要用途：衡量企业的好坏。 通过量化手段，衡量业务的服务和APP的运行质量。

　　2）发现业务缺陷：通过对服务单元质量数据的度量，发现业务质量薄弱环节，为问题发现和业务优化提供数据支持。

　　3）业务贡献：通过对优质数据的分析整合，为产品策略提供数据支持和判断。

　　3.2 能力指标

　　1、数据采集能力：

　　Basic data is the cornerstone of the establishment of quality standards, and data acquisition is an indicator of the maturity of a product line. Generally, APP data acquisition methods mainly fall into two categories: 1. General third-party statistical platforms: For example, mtj and some third-party data statistical platforms provide SDKs to report statistics on APP running status and other indicators, and give Generate a graphical analysis report. 2. Data reporting of its own business: capture and report through business burying point or self-written SDK. It is more flexible for self-burying or self-writing SDK. However, corresponding human and machine resources need to be invested.

　　2. Data analysis ability:

　　On the basis of data acquisition, data analysis is the only way to transform data into quality data and quality standards. The process of data analysis is discrete business data, which becomes useful data for business by dividing and statistically aggregating according to the aspects of business sorting. The ability to analyze business data is concentrated in two aspects: 1. Data computing ability. For the calculation of discrete data, a large amount of data calculation is required to complete. A set of efficient and smooth running computing framework is the prerequisite for big data computing. 2. The business sorting ability requires a relatively fine-grained understanding of business understanding and upstream and downstream connection. 3. The ability to analyze business data. For the statistical data, it can correspond to the performance of the business, and can predict the quality of the platform business through the change of the data.

　　3. Closed loop of quality data:

　　The closed loop of quality data is a relatively long-term process. After data acquisition and data analysis, unreasonable or relatively weak points in the business can be found, and the business can be adjusted and optimized by formulating a reasonable optimization plan. Then it goes back and forth to achieve a closed loop of quality data.

　　3.3 Data Utilization

　　Data analysis is the core of the entire monitoring, and it is also the most difficult task. Data analysis is combined with business logic, and after calculation and statistics are performed through basic data, the analysis corresponds to business logic. Through the change of data, to explain the change of business and the degree of good or bad.

　　Data visualization is an effect display of data monitoring. Good data display can ensure that users can better analyze the changes of data and the direct internal connection of data. The importance of data visualization is also self-evident. It is like the lubricating oil of the engine, which can make the entire monitoring system run more efficiently and smoothly.

　　解决方案:如何做出高效的独立站外链？

　　外链建设是独立站SEO的重要策略之一。 怎样做独立的网站外链才能增加网站流量，提高转化率呢？

　　如何做一个高效的独立站外链？

　　(1) 高质量的反向链接

　　使用SEO工具寻找域名评分高、流量大、页面权限高的网站，必须具备发布外链的条件，发布带有产品信息或关键词的内容，以获得反向链接。 网站的权限越高，链接权限越大，但也不一定要选择高权限的链接。 事实上，中低权限会使反向链接配置文件更加自然。

　　(2) 博客链接

　　博客是高价值版块，大部分有博客内容的网站比没有博客版块的网站点击率更高。

　　

　　博客外链应该寻找相关性高、能为博主提供价值的网站。 可以和博主协商选题方向、价格等，达成一致后撰写内容，发表在他们的博客上，增加独立网站的访问量。 注意：有效的外部链接必须遵循相关性、权威性和多样性的原则。

　　(3) 推荐链接

　　推荐链接建立强大的链接。 通常，在另一个网站的首页上获得链接位置对于提高独立站的排名具有显着的作用。

　　找到与你的产品和服务高度相关的网站，向他们解释你的内容在他们网站上的作用，并提议张贴链接。 影响越大，发表的机会就越大。

　　(4) 权威性

　　建立外链的目的是让其他网站帮你背书，让搜索引擎更加信任你的独立网站，所以尽量选择权威的网站，越权威独立网站的排名越有可能提高。

　　

　　(5) 相关性

　　相关性主要从页面开始，不仅要考虑产品和服务本身，还要了解目标受众，思考什么样的页面与他们高度相关，他们的价值取向是什么，应该使用什么关键词，如何搜索关键词。

　　另一个关键点是主题。 你可以尝试从不同的角度寻找合适的主题，但要尽量贴近网站的主题和内容。

　　(6) 多样性

　　网站链接的质量高于数量。 从优质网站获取外链，使得独立站更有可能被谷歌搜索引擎看重。

　　多样性不仅是指链接源域名的多样性，还包括页面类型的多样性，如博客、新闻网站、论坛等，以及链接位置的多样性，将链接放置在页面的不同位置，对于例如，侧边栏、文章、页面底部等。