活跃用户数量偏少?让我们从代码上分析一下原因!
作者:互联网
最近有网友发现友盟的数据统计里面,活跃用户的数量有点不大对劲,跟启动次数相比,严重偏少。sdk的使用方式没啥好说的,就那么简单几步,应该不会是sdk设置的问题。于是就从友盟关于活跃用户的定义开始,着手分析这个问题。
活跃用户的定义:打开应用的用户即为活跃用户,不考虑用户的使用情况。
从上面的文章,了解到Umeng里面对用户的定义:友盟将一个独立的设备视为一个用户,然而每个独立的用户是通过UMID来进行唯一标识的。然而UMID又是神马鬼东西?简单来说就是友盟会在第一次安装的时候生成一个UMID,当ID生成以后友盟会尽量保证这个UMID不会发生变化。
在应用对应的存储目录下面,我们可以找到这个UMID的身影:
ngeIdentity.json这个文件来说,cat一下里面的内容,应该可以看到:
笔者发现公司里多台设备的UMID都居然是一个相同的UMID值,WTF!!!也同样是上面这串神秘的代码:528c8e6cd4a3c6598999a0e9df15ad32。
这个时候就需要查一下UMID的生成方式了,从上面那篇UMID方案解析的文章中,可以了解到Android系统中与UMID相关的几个ID:imei、mac地址、android_id。有了这些关键点,我们就可以开始去反编译友盟的sdk包并进行下一步的搜索了(这里反编译了友盟最新的jar包:umeng-analytics-v6.0.1.jar)。。。果然,使用上面这几个关键字,很快就搜索到了一些关键的代码:
段代码逻辑比较简单(由于笔者所调试系统<23,故省略了一部分代码),首先TelephonyManager.getDeviceId()获取imei,若取不到则调用u(context)函数获取下一个字符串,若再取不到,则获取android_id。其实这里可以猜测到,u()中返回的字符串应该就是mac地址,我们来看下函数u()的逻辑代码:
果然,函数u(context)就是返回wifi的mac地址的。那么,回到刚刚的那个问题,到底那串神秘的UMID是528c8e6cd4a3c6598999a0e9df15ad32根据啥来生成的?看着这格式有点像md5。然后把机器上的imei、mac地址、android_id都打印了出来:
突然发现公司设备上打印出来的mac地址都是00:00:00:00:00:00(因为木有wifi模块,只有ethernet模块,囧!!!),怒将其转为md5,正是上面的串代码。
可是,为啥当mac地址是00:00:00:00:00:00的时候,不去选择android_id呢?回去仔细看代码,发现友盟用的是坑爹的TextUtils.isEmpty()来判断mac地址的有效性,跪了,上面那串明明就是无效的mac地址好么?只能说代码写得不严谨。。。
至此,代码及原因分析完毕。当一些Android平板设备统一返回相同的mac地址,如00:00:00:00:00:00时(有可能是没有wifi模块;也有可能是山寨机出现这种情况的时候),友盟将会将其数据识别成同一用户,并且将会造成严重的MAC地址漂移。
作为比较,我们来看一下友盟的竞争对手shareinstall的渠道统计代码!
首先,我们开看看shareinstall的web集成步骤:
<!-- 建议直接引用下面的js链接,以便得到最及时的更新,我们将持续跟踪各种主流浏览器的变化,为您提供最好的服务-->
<script type="text/javascript" src="//www.shareinstall.com/js/page/shareinstall.min.js"></script>
<script type="text/javascript">
//错误处理:确保app始终能正常的安装
var timer = setTimeout(
function() {
var button = document.getElementById("downloadButton");
button.style.visibility = "visible";
button.onclick = function() {
var ua = navigator.userAgent;
if (ua.indexOf(" MicroMessenger/") > -1) {
//微信中显示遮罩提示在浏览器中打开或进入应用宝
var div = document.createElement("div");
div.innerHTML = "<div style="font-size:2rem;color:#fff;text-align:center;"
+"position:fixed;left:0;top:0;background:rgba(0,0,0,0.5);filter:alpha(opacity=50);"
+"width:100%;height:100%;z-index:10000;">点击右上角在浏览器中打开</div>";
document.body.appendChild(div);
} else {
if (ua.indexOf("Android") > -1) {
//直接下载apk
//window.location="apk地址";
} else if (ua.indexOf("iPhone") > -1 || ua.indexOf("iPad") > -1
|| ua.indexOf("iPod") > -1) {
//直接进入appstore
//window.location="appstore地址";
}
}
}
}, 5000);
//shareinstall初始化,初始化时将与shareinstall服务器交互,应尽可能早的调用
/*web页面向app传递的json数据(json string/js Object),应用被拉起或是首次安装时,通过相应的
android/ios api可以获取此数据*/
var data = ShareInstall.parseUrlParams();//shareinstall.js中提供的工具函数,解析url中的所有查询参数
new ShareInstall({
appKey : 'F6BKAREBHF22EB',
onready : function() {
//shareinstall已成功回调,清除定时器
clearTimeout(timer);
timer = null;
var m = this, button = document.getElementById("downloadButton");
button.style.visibility = "visible";
/*用户点击某个按钮时(假定按钮id为downloadButton),安装app*/
button.onclick = function() {
m.wakeupOrInstall();
}
}
}, data);
</script>
shareinstall提供完整的javascript api,方便Web开发者实现完全自主的设计。
再开看看shareinstall的代码配置(测试):
如果做测试,获取参数,则必须在Appdelegate.h加上如下测试代码。
#pragma mark 将oc数据类型转成NSString
-(NSString *)DataTOjsonString:(id)object
{
if (!object) {
return null;
}
NSString *jsonString = null;
NSError *error;
NSData *jsonData = [NSJSONSerialization dataWithJSONObject:object
options:NSJSONWritingPrettyPrinted
error:&error];
if (! jsonData) {
NSLog(@"Got an error: %@", error);
} else {
jsonString = [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding];
}
return jsonString;
}
使用Shareinstall 控制中心提供的渠道统计时,在App用户注册完成后调用,可以统计渠道注册量。
警告:必须在注册成功的时调用[ShareInstallSDK reportRegister] 方法,否则可能导致注册统计不准。
由上比较得知,shareinstall与友盟最大的优胜点就在于首先实现完全自主。这很大一部分是因为它们一开始实现目的就有差别。例如:友盟针对一项SDK下载,需要同时下载3个包,而shareinstall则可以一键完成;而在集成上,友盟面对不同的项目需要不同的操作,过程过于繁琐。而shareinstall通过 URL Scheme 和 Universal Links 实现在不同浏览器中拉起APP,应用集成造成的代码冗余少,集成简单。携参安装实现个性化,渠道统计更精确。
标签:00,用户数量,代码,mac,shareinstall,地址,友盟,UMID,偏少 来源: https://blog.51cto.com/14686870/2473773