1. 数据采集面临的安全与隐私挑战
不管是第三方分析工具，还是企业的***方分析系统，在分析用户行为时，通常都会选择在客户端(一般是安卓、iOS 和 Web 端)采集用户的行为，然后经过打包、压缩等一系列处理步骤，发送给服务端，再进行存储和分析。由于客户端是在用户自己的网络环境下运行的，客户端与服务端之间的数据传输，是需要通过公网的，因此，也会带来一系列数据采集上的安全与隐私的问题。
这些问题包括：
数据采集的完整性问题：因为在客户端采集数据，为了保证尽量不影响用户体验，所以在采集数据时，一般不会同步发送数据，而是在本地先做缓存，然后再整体压缩、打包并在网络好时一起通过公网进行传输。如果客户端一直网络不好，传输失败时，则会累计在本地，而本地缓存会有限额，或者缓存数据全部发送完毕前，App 就被卸载则都会丢掉部分数据。在 Web 端使用 JS 传输数据时，虽然是同步发送，不过由于公网传输的网络问题，一般也会有 3% 到 7% 的数据丢失，并且基本难以避免。
数据采集的隐私性问题：第三方可能会在传输过程中截获传输的数据，从而拿到传输的这些用户行为数据。这些用户数据都是体现用户在客户端的一些具体的用户行为，蕴含着用户的隐私。
数据采集的准确性问题：第三方可能会在传输过程中伪造数据，从而让后台的分析结果不准确。这种伪造可能是直接调用传输的 API，可能是在多个模拟器上运行 App，甚至可能是直接人工作在真实设备上操作 App，都会导致传输到服务端的数据不准确。
在这三大类问题中，第二类问题由于涉及到用户隐私，所以一般会认为非常严重;***类问题会影响最终分析结果的准确性，也应该尽量着力解决;而第三类问题，对于恶意第三方来说相当于是一个“损人不利己”的事情，对于很多并不出名的创业公司来讲一般也不会被人恶意针对，所以相对而言并没有那么严重。
2. 常见解决方案分析
2.1 使用 HTTPS 作为传输协议
HTTPS 是一种网络安全传输协议，它经由超文本传输协议(HTTP)进行通信，但利用SSL/TLS来对数据包进行加密。HTTPS开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性。
简单来说，不考虑太多技术细节，在有 HTTPS 作加密的情况下，可以认为，除了服务端与客户端，在中间的传输环节，是拿不到也无法修改传输的内容的，因此，采用 HTTPS 作为传输协议，可以很好地防止数据被窃取，神策分析(Sensors Analytics)也提供了采用 HTTPS 传输数据的方案。
由于依然是在客户端采集数据，依然是通过网络传输数据，所以采用 HTTPS 作为传输协议并不能解决数据完整性的问题。
同时，HTTPS 也不能阻止数据的伪造，伪造者在客户端是可以直接抓包拿到传输的内容的，从中获取传输 API 与传输协议后，就可以直接调用 API 通过 HTTPS 传输伪造的数据了，更别说通过模拟器运行 App 或者直接用机器运行 App 来伪造数据了。
2.2 传输内容加密
如前面所描述的那样，HTTPS 是在传输环节进行传输协议加密的，并不能阻止恶意第三方在客户端抓包获取数据，从而获取传输的内容与传输协议。因此，自然可以考虑更进一步，不仅仅通过传输协议加密，对于传输的内容也进行加密。
这样做的好处，是可以阻止恶意第三方拿到传输协议，从而没有办法通过直接调用 API 的方式来进行数据伪造，但是，对于模拟器运行 App 或者直接用机器运行 App 来伪造数据的手段，依然是无能为力。同时，对传输内容进行加密，也不能改变是在客户端采集数据，以及通过公网传输数据的本质，所以并不能解决数据完整性的问题。
与此同时，由于需要对传输内容进行加密，所以数据采集的代码和传输协议都不再能够开源了，否则就很容易被恶意第三方破解加密方案。对于公司内部的***方数据采集方案，并没有问题，但是，如果是第三方分析工具，它的代码如果不开源，一些对于安全与隐私比较敏感的客户，可能就不敢集成了。同时，由于传输协议不开源，也大大降低了系统的开放性。正因为这些原因，神策分析还是选择了优先保证 SDK 和传输协议的开放性，以打消客户集成 SDK 时的顾虑，所以并没有采用传输内容加密的方案。
2.3 后端采集
在后端采集数据，例如采集后端的日志，其实就是将数据采集的传输与加密交给了产品本身，认为产品本身的后端数据是可信的。而后端采集数据到分析系统中则是通过内网进行传输，这个阶段不存在安全和隐私性问题。同时，内网传输基本不会因为网络原因丢失数据，所以传输的数据可以非常真实地反应用户行为在系统中的真实体现。
因此，基于后端采集的上述优势，神策分析目前提供了 Java、PHP、Python、Ruby 等后端语言的 SDK，以及 LogAgent、BatchImporter、FormatImporter 等导入工具，支持在后端采集。
当然，对于模拟器运行 App 或者直接用机器运行 App 来伪造用户行为，由于后端拿到的就是伪造后的数据，所以对于这种伪造行为，依然是无能为力。
2.4 采集后再 antispam
对于之前提到的模拟器运行 App 或者直接用机器运行 App 来伪造用户行为这一类技术手段，只能依托于在采集数据后，再进行 antisapm 清洗数据。这些清洗有很多不同的策略，比较常见的有：
基于统计信息进行清洗：例如，把那些流量明显大于平均值的设备或者 IP 的用户行为过滤掉，把那些行为频率明显超过正常人限度的用户行为过滤掉等;
基于用户行为特征进行清洗：主要是用到一些机器学习的手段，通过对整体的用户行为进行训练，然后找到那些行为特征明显异于常人的用户;
基于设备真实性进行清洗：目前有一些第三方供应商提供了类似的方案，通过识别一个设备是一个真实的设备，还是一个模拟器，来解决虚拟机造假问题。
神策分析后面将会提供类似的 antispam 方案，并且将识别出来的用户作弊概率直接作为一个用户的 profile，以供使用者来选择使用。
3. 一些题外话
其实，除了数据采集这个环节以外，很多互联网产品，都会面临着网络传输中的“安全”与“隐私”这两类问题，而且也都会有所取舍与折衷。
我们以百度，这样一个典型的互联网产品为例，来看看它的网页端是如何选择来解决这些问题。
首先，百度选择了全站采用 HTTPS 进行加密，主要目的其实是为了避免第三方(如运营商等)篡改返回给用户的网页在其中加入第三方的广告，当然，这一做法，也客观保证了用户的操作不被第三方窃取;
其次，对于通过 Spider 等非人工的访问方式来抓取搜索结果的行为，则并没有在访问时就进行封禁等处理，而是在进行统计时再进行复杂的流量清洗等 antispam 手段，以获得准确的流量，这主要是为了在保持用户体验，避免因为误封禁而影响正常用户的访问，同时，也可以在后处理时可以加入复杂的策略保证***的清洗效果;
第三，对于使用某些非法手段来对广告点击进行造假的行为，由于涉及到经济隐私，相比抓取搜索结果危害要更大，所以虽然都是采用后处理 antispam 的方式，但是时效性会更好，一般是会先做完 antispam，然后再扣费，从而避免作弊点击导致广告费用扣光，影响点击。广告点击的 antispam 是百度的核心策略与竞争优势，也是投入很多成本进行研发与维护的领域。
