产品经理的能力模型中，有一项是“数据分析”能力，在日常工作中，也会有意识地培养“数据思维”，而建立“数据思维”的第一步就是“数据采集”。
“数据采集”需要产品经理或者数据分析师，在APP发版前，提供非常详细的代码埋点文档（PS：现在可视化埋点技术也比较成熟，可作为代码埋点的有效补充），本文将分享下，仅接入了统计平台的SDK，而没有进行代码埋点的情况下，SDK可以收集到哪些信息。
市面上主流的2个APP统计平台为友盟和TalkingData（以下简称TD），本文以友盟和TD为例，在只接入这2家的SDK接入，SDK可以收集到哪些数据，并上报到各自的数据分析平台，形成可视化操作页面。
（顺便提下，比较优秀的APP统计平台还有：growingIO、神策数据、MTA、百度统计、诸葛IO）
一、不埋点，也可以统计得到用户数
在APP的数据指标中，首先想到和用户数相关的指标为：新增、活跃和累计。
先简单介绍下这3个指标的定义：
新增用户：第1次启动应用的用户（以设备号作为判断标准），卸载后重新安装，不会重新计算。
活跃用户：当日活跃用户指当日启动过应用的用户（去重）。
累计用户：指截止到当前，启动过应用的所有独立用户（以设备号的判断作为标准）。
以上3个指标，友盟和TD均采用设备号作为唯一标识。
友盟的设备号为UMID，定义如下：
新增用户以UMID作为唯一设备识别，UMID是基于友盟+自己的设备ID生产算法，在APP的生命周期保持稳定性和唯一性。
TD的设备号为TDID，定义如下：
TalkingData根据TDID来标识一台设备的，TDID是基于SDK获取的设备信息以及常量参数并结合TD的加密方案生成一台设备的标识，以便持久化来保持设备的唯一性。
PS：友盟的UMID和TD的TDID，都是1个称谓而已。
用户数，是以当前手机的设备号为依据，因此不需要埋点就可以收集得到。
抛出1个问题：用户数，准确么？
答案是：不准确。
简单介绍一下，不管友盟还是TD，都是采集手机的设备号作为主要参数，生成对应的UMID和TDID。在少数情况下，手机的设备号会发生变化，随之带来的就是用户数的不准确，比如：这里最让人抓狂的iPhone机型。
iPhone曾经可使用的设备号包括：UDID、MAC地址、openUDID、IDFA、IDFV、UUID。目前可使用的设备号，仅剩IDFA、IDFV和UUID了，而这个标识。在某些情况下，可能读取不到，或者会发生变化。
已有的老用户的设备号发生变化，系统会生产新的UMID或TDID，导致老用户被系统识别为1个新用户，新增用户+1，累计用户+1。
二、不埋点，也可以收集得到收集的系统信息
先给大家示意一小段SDK报过来的数据：
{
“devId”: “xxx0f2cb6f863e32b4944246e57913xxx”,
“productId”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”,
“AppProfile”: {
“appPackageName”: “xxx.xxxx.xxx”,
“appVersionName”: “APP名称”,
“appVersionCode”: “5.4.3”,
“startTime”: “1537085493000”,
“sdkVersion”: “SDKversion_ios_V1.2.7”,
“partnerId”: “Appstore”,
“isCracked”: true,
“installationTime”: “1499306536000”,
“purchaseTime”: “0”,
“appStoreID”: “0”
}
第1行中的 devId，即为加工后的设备号，友盟称为UMID，TD称为TDID。用于唯一标识1台设备。
第2行中的productId，即为APPID，用户标识1个APP；比如今日头条iOS端接入了友盟的SDK，那么友盟在系统上给今日头条iOS这个APP分配1个专属APPID。
示例数据其他各行的数据，依次为：APP的包名、APP名称、APP版本号、APP启动时间（1537085493000为Unix时间戳，转成北京时间为：2018/9/16 16:11:33）、渠道号（这里的渠道号，是工程师在打包的时候，为了区分渠道来源，“写死”在安装包中的信息。比如：上传到应用宝应用市场的包，渠道号可以命名为“yingyongbao”，也可命名为“yyb123”），APP包是否被破解，APP启动时间，APP的购买时间。
除了以上数据外，SDK还会上报的数据有：
机型（如：iPhone 6s puls）、操作系统的版本号（如：iOS 11.4.1）、屏幕分辨率，当前手机的名称（如：张三的iPhone，李四的安卓华为P20手机），是否越狱，设备号（Android上报IMEI，iOS上报IDFA或者IDFV）。
经纬度，地区（CN、中国），电信运营商（如：中国移动、中国联通、中国电信、中国香港移动……），网络类型（如：2G、3G、4G、wifi、离线），wifi名称（如：CMCC、隔壁老王的wifi）；
不知道你注意到了没有，手机连过的wifi名称，SDK是可以收集得到的，方不方？
三、写在后面，用户隐私的考虑
说明下，在APP数据收集这个链条中，有3个角色：用户、APP开发商、SDK统计平台。
SDK统计平台收集了这么多信息，或者说APP开发商借助SDK，收集了这么多信息，对用户来说，是不是侵犯了用户隐私？
现实是，APP开发商知道张三在APP里的一举一动，知道你每个行为的含义（比如：在2018年9月18日购买了1台iPhone x，支付方式为支付宝，在购买页面犹豫了2秒）。而，SDK统计平台，也知道用户的一举一动。
一般情况下，它不知道这个用户是谁，更不知道这些动作的含义，就酱紫。
四、附，系统平台设备号的生成方法
友盟的设备号称为UMID，TD的设备号称为TDID。
在这里，补充描述系统平台设备号的计算方法，我们自命名为DeviceID。
（1）Android平台
统计SDK可直接读取到Android设备的IMEI号，用该IMEI号，即可生成DeviceID。
XXID可以通过以下公式获取：
DeviceID=x1+MD5（android_imei_mac）
（2）IOS平台
UDID：
UDID（设备唯一标识符，Unique Device Identifier），之前一直是设备唯一标识的神器，各大应用和统计SDK均通过获取UDID标识设备。不过，2013年5月1日后，读取UDID的应用，将被拒绝上架，相当于把这条路封死了。
MAC地址：
IOS7.0以前的设备，可读取MAC地址，通过该MAC地址，即可生成DeID。
DeviceID可以通过以下公式获取：
DeviceID=x2+MD5（ios_mac）
IOS7.0及以后的设备，MAC地址返回的是一个固定值，因此对于IOS7.0及以后的设备，将无法通过MAC地址来标识设备的唯一性。
openUDID：
openUDID，是通过第一个带有OpenUDID SDK包的App生成的，在下列2种情况下，openUDID会重新生成：
用户卸载了全部带有OpenUDID SDK包的App后，并重新启动设备后，openUDID将会重新生成；
用户更新了iOS系统，或者选择了恢复出厂设置是，openUDID将会重新生成。
考虑到90%以上的用户在IOS系统更新后，均会重新生成openUDID，采用openUDID方法标识用户唯一性也慢慢被弃用。
IDFA&IDFV：
IDFA（广告标识符，Advertising Identifier），是苹果公司提供的用于追踪用户的广告ID，同一手机的不同APP对应着相同的IDFA，IDFA可通过以下步骤重置：设置-隐私-广告-还原广告标识符。
如DeviceID可以通过以下公式获取：
DeviceID=x2+MD5（IDFA）
因为IDFA会存在取不到的情况，因此需要选用其他的ID作为DeviceID。在取不到IDFA的情况下，我们选用IDFV。
IDFV（Vindor标示符，IdentifierForVendor），一般用于追踪用户在应用内的行为，每个设备在所属同一个Vender的应用里值是相同的。如果用户删掉了该vender的所有APP，IDFV将会被重置。
DeviceID可以通过以下公式获取：
DeviceID=x2+MD5（IDFV）
UUID：
UUID（通用唯一标识码，Universally Unique Identifier），通用唯一识别码，每次生成均不一样；第1次生成后UUID后，需要保存到钥匙串（keyChain）中；应用被删除再重装时，仍然可以从钥匙串得取到UUID；在一台设备上，同一个开发者账号的所有APP，可获取到相同的UDID；刷机或者重新安装系统后，UUID将重新生成。
DeviceID可以通过以下公式获取：
DeviceID=x2+MD5（UUID）
综上可知，iOS的DeviceID的获取方法可以概括为：IOS7.0以前的设备，DeviceID=x2+MD5（ios_mac）
IOS7.0及以后的设备，DeviceID=x2+MD5(IDFA/IDFV/UUID)，即先取IDFA的值，取不到IDFA时去取IDFV的值，再取不到时IDFA时，则生成UUID。
备注：这里用x1和x2这个前缀，是用来区分Android和iOS的设备号；如：可以用数字“1”来作为Android的前缀，用数字“2”作为iOS的前缀；后面在进行数据分析时，看到1开头的，就知道这是Android的设备了。
本文由 @十三先 原创发布转载请注明出处。
网友评论