因为用默认的shell不好，所以就用busybox的sh来代替，后来发现adb install无法安装程序。到了bin目录看了一下，发现几个好用的脚本。
 
 1.svc命令 这个脚本在/system/bin目录下，这个命令可以用来控制电源管理，wifi开关，数据开关(就是上网流量)
 
 2.svc power stayon [true|false|usb|ac] 这个是控制usb插入的时候屏幕是否常亮，这个有地方设置，就不多说了
 
 3.svc data disable这个命令可以关闭数据连接，就是上网流量，大家都知道控制上网的开关很多，但是大都是通过在apn上的接入点加后缀来实现的，但是这个命令不会更改apn的任何设置，直接在底层关闭数据连接。 应该是最彻底的，而且又不影响apn的设置。
 这个跟apndroid有什么区别，apndroid是在关闭上网数据的时候，已经在下载的连接可能不会被强制关闭(这个在apndroid自己的说明中也有提到)。比如你在下载一个10M的电影，下载了1M，不响下载了。用apndroid关闭连接，可能这个下载还会继续，不会马上停掉。
 但是用这个命令，绝对毫不留情的咔嚓掉。
 
 4.svc data enable 这个是打开上网数据连接，跟上一个命令是相反的。
 
 5 svc data prefer 这个命令是控制3g数据连接比wifi优先。我们都知道，正常情况下，有wifi的时候，不会用到3g连接。但是这个命令是相反，有3g的话先用3g流量，没有3g的时候采用wifi.我想大家不会这么傻吧，所以这个命令没什么用。
 
 6. svc wifi disable 关闭wifi 连接
 
 7 svc wifi enable 开启wifi连接
 
 8 svc wifi prefer 设置wifi优先，跟5是相反的。
 
 上面的命令都要在shell中执行，需要root。
 大家可以用gscript ，然后输入这些命令做成在快捷方式放在桌面，跟那些开关软件一样方便使用。
 
 
 
 
 转:http://android.linkphone.cn/play/201102/701.html

Flink WaterMark移动以及迟到数据分析
 
目录
 
Flink WaterMark移动以及迟到数据分析
 
设置参数
 
数据格式
 
秒级场景预演
 
上传第1条数据
 
上传第2条数据
 
上传第3条数据
 
上传第4条数据
 
上传第5条数据
 
上传第6条数据
 
上传第7条数据
 
上传第8条数据
 
上传第9条数据
 
上传第10条数据
 
上传第11条数据
 

将以此代码进行实验分析，不想看代码直接看下面章节即可（源码在此）
 
import com.fun.{UserAgg, UserProcessFunction, UserWindowFun}
import com.protocol.{UserBehavior, UserViewCount}
import com.tools.TimeGet
import org.apache.flink.streaming.api.TimeCharacteristic
import org.apache.flink.streaming.api.functions.timestamps.BoundedOutOfOrdernessTimestampExtractor
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.streaming.api.scala._
import org.apache.flink.streaming.api.windowing.time.Time
object UserBehaviorAnalysis {
  def main(args: Array[String]): Unit = {
    val env = StreamExecutionEnvironment.getExecutionEnvironment
    ()
    env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
    env.setParallelism(1)
    val dataStream = env.socketTextStream("127.0.0.1",9999).filter(data=>{
      data.split(",").size==5
    }).map(data => {
      val dataArray = data.split(",")
      println(TimeGet.getInstance.getTime(dataArray(4).trim.toLong * 1000))
      UserBehavior(dataArray(0).trim.toLong, dataArray(1).trim.toLong, dataArray(2).trim.toInt, dataArray(3).trim, dataArray(4).trim.toLong*1000)
    }).assignTimestampsAndWatermarks(new BoundedOutOfOrdernessTimestampExtractor[UserBehavior](Time.seconds(1)) {
      override def extractTimestamp(t: UserBehavior): Long = t.timestamp
    }).filter(user=>{
      user.behavior == "pv"
    })
    val tag = new OutputTag[UserBehavior]("latedata")
    val aggresult:DataStream[UserViewCount] = dataStream.keyBy(_.itemId).timeWindow(Time.seconds(10), Time.seconds(2)).allowedLateness(Time.seconds(3))
      .sideOutputLateData(tag).aggregate(new UserAgg(), new UserWindowFun())
    val result = aggresult.keyBy(_.window).process(new UserProcessFunction())
    dataStream.print("data")
    val lateDate = aggresult.getSideOutput(tag)
    lateDate.print("late")
    aggresult.print("agg")
    result.print("topN1")
    env.execute("test")

  }
}

import org.apache.flink.api.common.functions.AggregateFunction

class UserAgg extends AggregateFunction[UserBehavior,Long,Long]{
  override def createAccumulator(): Long = 0l

  override def add(in: UserBehavior, acc: Long): Long = acc+1

  override def getResult(acc: Long): Long = acc

  override def merge(acc: Long, acc1: Long): Long = acc+acc1
}

import org.apache.flink.api.common.state.{ListState, ListStateDescriptor, MapState, MapStateDescriptor}
import org.apache.flink.streaming.api.functions.{KeyedProcessFunction, ProcessFunction}
import org.apache.flink.util.Collector
import scala.collection.mutable.ListBuffer
class UserProcessFunction extends KeyedProcessFunction[Long,UserViewCount,String]{
  lazy val liststate: MapState[Long,Long] = getRuntimeContext.getMapState[Long,Long](new MapStateDescriptor[Long,Long]("item-list", classOf[Long],classOf[Long]))
  override def processElement(i: UserViewCount, context: KeyedProcessFunction[Long, UserViewCount, String]#Context, collector: Collector[String]): Unit = {
    liststate.put(i.itemId,i.cnt)

    context.timerService().registerEventTimeTimer(i.window+1)
    context.timerService().registerEventTimeTimer(i.window+3*1000l)
  }
  override def onTimer(timestamp: Long, ctx: KeyedProcessFunction[Long, UserViewCount, String]#OnTimerContext, out: Collector[String]): Unit = {
    if(timestamp==ctx.getCurrentKey+3*1000l){
      //等待窗口彻底关闭后再清除状态，等待延迟数据可以更新状态
      print("clear state==================")
      liststate.clear()
      return
    }
    val iter = liststate.iterator()
    val lst=ListBuffer[UserViewCount]()
    val builder = new StringBuilder()
    while (iter.hasNext){
      val value = iter.next()
      lst.append(UserViewCount(value.getKey,ctx.getCurrentKey,value.getValue))
      val counts = lst.sortBy(_.cnt)(Ordering.Long.reverse).take(3)
      for(i<-counts) {
        builder.append(i.itemId).append(" ").append(TimeGet.getInstance.getDate(i.window)).append(" ").append(i.cnt).append("\n")
      }
    }
    out.collect(builder.toString())
  }
}

import com.protocol.UserViewCount
import org.apache.flink.streaming.api.scala.function.{ProcessWindowFunction, WindowFunction}
import org.apache.flink.streaming.api.windowing.windows.TimeWindow
import org.apache.flink.util.Collector

class UserWindowFun extends WindowFunction[Long,UserViewCount,Long,TimeWindow]{

  override def apply(key: Long, window: TimeWindow, input: Iterable[Long], out: Collector[UserViewCount]): Unit = {
    print(TimeGet.getInstance.getTime(window.getStart) +"--------------------------------------------"+TimeGet.getInstance.getTime(window.getEnd)+"\n")
    out.collect(UserViewCount(key,window.getEnd,input.iterator.next()))
  }
}
import java.sql.Date
import java.text.SimpleDateFormat
import com.tools.TimeGet.simpleDateFormat

class TimeGet private() {
  def getTime(time:Long):String={

    val date1 = new Date(time)
    simpleDateFormat.format(date1)
  }
  def getDate(timeStamp:Long):String={
    simpleDateFormat.format(timeStamp)
  }
}
object TimeGet{
  val simpleDateFormat=new SimpleDateFormat("yyyy-MM-dd hh:mm:ss")

  private var s:TimeGet=null

  def getInstance={
    if (s==null){
      s=new TimeGet()
    }
    s
  }
}
 
设置参数
 
设置事件事件
 
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
 
watermark延迟1s
 
new BoundedOutOfOrdernessTimestampExtractor[UserBehavior](Time.seconds(1)
 
设置窗口size为10s，滑步长为2s
 
timeWindow(Time.seconds(10), Time.seconds(2)
 
如果数据迟到3S则直接丢弃
 
allowedLateness(Time.seconds(3)
 
数据格式
 
UserBehavior(543462,1715,1464116,pv,1511658000000)最后一个字段提取成EventTime
 
秒级场景预演
 
根据上面设置的参数以及数据格式，分别逐秒上传数据
 
上传第1条数据
 
543462,1715,1464116,pv,1511658000（EventTime: 2017-11-26 09:00:00）
 
建立第一个窗口【08:59:52-09:00:02）
 
建立第1个滑步[09:00:00-09:00:02)
 
此时窗口未关闭，未触发窗口相关计算操作
 
上传第2条数据
 
543462,1715,1464116,pv,1511658001（EventTime: 2017-11-26 09:00:01）
 
处于第1个滑步【09:00:00-09:00:02)
 
处于第1个窗口【08:59:52-09:00:02）
 
未触发窗口相关计算操作
 
上传第3条数据
 
543462,1715,1464116,pv,1511658002（EventTime: 2017-11-26 09:00:02）
 
建立第2个窗口【08:59:54-09:00:04）
 
建立第2个滑步[09:00:02-09:00:04)
 
watermark设置的为延迟一秒所以此时第一个滑步还不会结束 ，也就是说第一个滑步会在09:00:03结束
 
未触发窗口相关计算操作
 
上传第4条数据
 
543462,1715,1464116,pv,1511658003（EventTime: 2017-11-26 09:00:03）
 
处于第2个窗口【08:59:54-**09:00:04）
 
处于第2个滑步[09:00:02-09:00:04)
 
watermark设置的为延迟一秒，已经达到，此时会触发基于窗口的agg操作
 
agg> UserViewCount(1715,1511658002000,2)
 
processFunction里面设置的触发器Ontimer是window.end+1，将在09:00:04到达的时候触发processFunction里面的状态计算
 
第1个滑步[09:00:00-09:00:02) ，触发agg计算
 
上传第5条数据
 
543462,1715,1464116,pv,1511658004（EventTime: 2017-11-26 09:00:04）
 
时间到达注册定时器的阈值，触发第一个窗口【09:00:52-09:00:02）的计算，并输出结果，计算逻辑是按窗口和第一列字段分区算count TopN，因为我们第一列一直为一个，所以此窗口输出结果为2.
 
topN> 1715 1511658002000 2
 
注意此时不会关闭第一个窗口，因为有allowedLateness(Time.seconds(3)），3s之后这个窗口才会关闭，3s之内再来这个滑步区间的值还会更新结果值
 
建立第3个窗口【08:59:56-09:00:06）
 
建立第3个滑步[09:00:04-09:00:06)
 
watermark设置的为延迟一秒所以此时第2个滑步还不会结束
 
上传第6条数据
 
543462,1715,1464116,pv,1511658005
 
...
 
上传第7条数据
 
543462,1715,1464116,pv,1511658006
 
第一个窗口彻底关闭，迟到的极限时间为09:00:02+1+3=09:00:06
 
第2个窗口【08:59:54-09:00:04）触发计算
 
topN> 1715 1511658004000 4
 
 
 
上传第8条数据
 
543462,1715,1464116,pv,1511658000（EventTime: 2017-11-26 09:00:01）
 
该数据为延迟数据，但是小于allowedLateness(Time.seconds(3)）（如果某条数据无法算作当前所有开着的窗口中的一条数据，则该数据将被标记为late数据，并输出到late流）
 
延迟时间大于watermark延迟，小于allowedLateness(Time.seconds(3)），这个时间段的数据不会被输出到迟到数据流
 
此时第1个窗口【08:59:52-09:00:02）已经在 09:00:06彻底关闭（09:00:03的时候触发窗口TOPN计算，但是算完之后状态没有清空，窗口也没有关闭，还在等待延迟数据，不过会在3s之后即09:00:06彻底关闭）
 
此时第2个窗口【08:59:54-09:00:04）将在 09:00:08关闭并在1ms之后出发计算，而这条数据（EventTime: 2017-11-26 09:00:01）属于第2个窗口
 
 
 
上传第9条数据
 
该数据位延迟数据
 
543462,1715,1464116,pv,1511658008（EventTime: 2017-11-26 09:00:08）
 
此时迟到数据重新计算第二个窗口【08:59:54-09:00:04）
 
同时第三个窗口【08:59:56-09:00:06）触发第一次TOPN计算
 
即输出结果如下
 
topN1> 1715 2017-11-26 09:00:04 5
topN1> 1715 2017-11-26 09:00:06 7
 
上传第10条数据
 
543462,1715,1464116,pv,1511657994
 
此数据位迟到数据，何时为迟到数据
 
如果某条数据无法算作当前所有开着的窗口中的一条数据，则该数据将被标记为late数据，并输出到late迟到流
 
当输入上述第9条数据的时候，EventTime已经到了09:00:08，此时只有EventTime-1（watermark）-3（allowedLateness）-10（windowsize）=8:59:54
 
也就是说此时再来一条小于8:59:54的数据才会被当做迟到数据，丢进迟到流
 
late> UserBehavior(543462,1715,1464116,pv,1511657994000)
 
上传第11条数据
 
543462,1715,1464116,pv,1511658014
 
此条数据距离第9条数据差了6s，此时他会把中间所有未关闭（windowEnd4秒内的不会关闭，windowEnd秒以前的窗口已经彻底关闭）的切触发计算窗口进行计算
 
输出
 
topN1> 1715 2017-11-26 09:00:10 9
​
topN1> 1715 2017-11-26 09:00:12 7

 
 欢迎大家关注笔者，你的关注是我持续更博的最大动力
 



 
 
 原创文章，转载告知，盗版必究




 


 
这次彻底解决：windows上拔掉U盘或移动硬盘时，弹出：该设备正在使用中，请关闭可能使用该设备的所有程序或窗口，然后重试。 

文章目录：
 
1 问题描述
1.1 正常硬盘或U盘拔取步骤
1.2 硬盘或U盘取过程提示设备有程序正在使用
  
2 解决硬盘或U盘拔取弹出的提示

 
 
1 问题描述
 
1.1 正常硬盘或U盘拔取步骤
 
我们一般从电脑上取下硬盘或U盘需要两步：
 
1、先在电脑上点弹出 Device
 
 
2、弹出Device提示成功后，在物理插拔硬盘或U盘设备即可
 
1.2 硬盘或U盘取过程提示设备有程序正在使用
 
而我们现在遇到的问题就是，在点弹出 Device时，提示：该设备正在使用中，请关闭可能使用该设备的所有程序或窗口，然后重试。
 
 
但是，你感觉已经关闭了和挂在移动硬盘或U盘所有的相关程序，如何才能安全的取下硬盘或U盘呢，强行拔也不是不可以，但很容易导致：
 
硬盘或U盘的数据丢失
硬盘或U盘因为强行插拔导致设备损坏
 
2 解决硬盘或U盘拔取弹出的提示
 
使用HotSwap软件，该软件很小，只有几百KB。HotSwap 的作用和在 Windows 设备管理器中删除设备是一样的，但它有一个核心功能：在设备热插拔之前，确保将所有数据都完整的写入到磁盘上。然后，强制弹出设备。
 
具体使用步骤如下：
 
1、下载安装HostSwap软件
 
官网下载
国内网址下载
 
下载完后，直接安装即可，安装完后会出现如下的图标
 
 
2、在该图标上鼠标右键
 
然后在设备类型选项卡处，把：可移动磁盘设备和安全移动设备勾选上
 
 
3、此时鼠标左键这个图标，会显示如下
 
 
然后鼠标点击：安全热插拔 \ Device\...，提示：安全移除热插拔设备
 
 
4、此时再点击弹出 Device，就会提示：安全地移除硬件
 
 
5、最后就可以大胆放心的插拔你的移动硬盘或U盘设备了！
 
 
 
 
 
  
 
 
 
  
 
 

 ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠

【前言】 
　　最近在忙着做一些新的项目，因此又搁了一段时间没有更新了。很多朋友在抱怨，这是一种督促，我会尽全力。这篇文章本来早就准备要上，结果打篮球扭伤了脚，耽搁了一周。现在全部奉上，以飨读者朋友们。
 
　　关于移动设备如何监测用户的行为，看似容易，其实不容易。容易的是，如果把移动设备就当成桌面PC，那么其实无论是对App还是对Web，都可以沿用目前在PC上的方式：Page Tagging和Event Tracking。但问题在于移动设备存在更多的灵活性，人们不止使用一个设备，人们还在移动设备和桌面设备之间切换，而且人们还在web和app之间切换。这样，一个人所发生的跨域和跨界的行为就太多了，如果监测不到这些“跨”行为，我们的监测就无法准确。后PC时代，互联网用户的监测也面临新的课题和挑战。
 
 
　　在今年的SEMPO会议上，我有30分钟的演讲，介绍这个话题。不过时间太短，很难展开，但很明显在场的听众非常感兴趣。因此，我又觉得该有文章研究一下这个领域，在这个文章和下个文章中，我将介绍我所了解到的方法。
 
　　这一篇文章，来自于美国同行专家Kevin Trilli的一篇文章，原文题目是《Mobile Tracking: How it works and why it’s different》，我请我的朋友Ptmind的李莹同学帮我做了全文的翻译。非常感谢她的全情帮助！这篇文章不容易，但翻译的非常有水准！文中没有引号的部分是我的注解。
 
【正文】
 
　　“本质上，移动业务的数据监测和我们常见的网站监测在原理上基本共通。举个典型的例子，我们都想要能够贯通各域的跨站监测，但是这种跨站监测的标识信息存活周期偏偏太短，所以我们不得不使用能够存活更久的单域标识来进行监测。然而，在移动监测的世界里，还有一些小波澜会让这些事情变得更加棘手。
 
　　“下文将讲述一些移动监测所使用的技术，并且会强调这些技术和我们传统的线上监测有何不同。其实，当下已经有不少移动广告投放商在对用户进行着标识和监测。简洁起见，下文假设我们是通过广告网络（Ad Network）发放广告，并进行相关的监测追踪。不过这并不代表在只有广告网络才会使用这些技术，在这个供应链中，当然还有其它的使用者。另外还要声明的是，尽管不乏有人担忧移动广告运营链中所采集的用户信息会涉及威胁用户隐私，但本文所述的广告商以及本文意指阐述的内容，都绝对不会涉及任何个人可识别信息进行行为分析，此外，在推广频率和独立用户数的计算方面，对用户信息的使用也做出了最大限度的保护和最有限程度的使用。
 
　　“移动广告网络所面临的一大挑战，就是移动广告的受众对象同时使用着移动网站和App（指mobile application，即移动应用，下同）两种内容媒介。在移动设备上，App和网站分属不同的域，被不同的沙盒所分隔，也使用着不同的标识信息。对于广告网络，这就意味着同一个用户可能被拆分成多个统计形象，广告网络还需要另寻他法将这些不同的识别信息整合到一起。对于这些方法，后文将有详述。
 
　　“我们先来谈谈移动App。对于App，开发者们会调用基于操作系统的标识符来标记独立用户。放眼Android和iOS两大巨头平台，两家分别使用了Android_ID和UDID来做这个事情。安卓同时还支持更多的系统标识信息，包括设备身份码（例如IMEI，MEID或ESN，根据网络不同而异），对于电话设备，可提供用户识别码（SIM卡上的IMSI码），如果设备支持WIFI，还能够提供WLAN MAC地址（iOS上也有这项信息）。这些基于操作系统的标识符着实令广告网络中的各位欣喜若狂，因为无论APP的开发者是谁，这个标识符都不会变。这样一来，太可以实现跨应用追踪独立用户。
 
译文版权归网站分析在中国以及译者所有，原文版权为Kevin Trilli，如欲转载请联系网站分析在中国
 
　　“不过，这种情况下用户基本上没什么自主权逃离监控，于是这一现象促使Apple在iOS5之后开始弃用了UDID。不过，所谓弃用并不代表开发者和广告网络没有办法再用它（他们的确还在用），但Apple强调了不建议开发者使用UDID，并且也意味着在未来的版本中有可能将UDID废除（彻彻底底的告别）。（译注：目前UDID已经废除，2013年年中，新提交的涉及使用UDID的APP已无法通过审核，只有此前提交的仍然可以使用。）
 
 
　　失去了UDID，Apple转而鼓励开发者们自行建立独立用户标识信息。不过当然，这救不了需要贯通信息的广告网络。为了达到跨应用检测，大家想到不少曲线救国的方案，但同样面临到和Apple弃用UDID同样的隐私担忧。
 
　　“接下来我们看看移动网站（mobile web）的情况，和传统线上网站一样，对于跨域监测我们采用的是第三方cookie（书作者注：对于自己网站上用户行为的监测，则还是使用了第一方cookie，原理跟前面谈到的client side tracking方法是完全一样的）。但和传统线上网站不同的是，由于移动设备上缺乏安全软件，广告网络对第三方cookie能写能查。第三方cookie在Android设备上是有效的。常规的Android用户习惯只去使用预装好的浏览器或者将特定的浏览器设成默认，而不再更换其他浏览器。而作为Apple的预装浏览器，Safari的第三方cookie默认设成了关闭，这也就意味着广告网络没法在Apple设备上进行跨域监测。不过，广告网络也采用了一些其它方法来监测iPhone和iPad用户的访问会话。
 
　　“一种方法是取巧于Safari浏览器的一项安全漏洞，如果广告网络运营者能够在页面中嵌入一个透明的iframe，就可以植入cookies。这项由斯坦福大学的毕业生Jonathan Mayer做出的发现一度引起了广泛关注。另一种方法，是去采集浏览器本身披露的信息，为该设备建立一份“指纹档案”。结合浏览器的使用程度、是否支持Javascript等所获信息程度不同，最乐观能达到94%的准确度。
 
译文版权归网站分析在中国以及译者所有，原文版权为Kevin Trilli，如欲转载请联系网站分析在中国
 
　　“还有一种方法，是结合存活期较长的单一域标识信息（长期标识），并借助一个临时的跨域标识符来帮助广告网络达成所需目的。这个长期标识和第一方cookie关联（一对一映射），会在请求广告时作为一种UID信息传递给广告网络。在一次访问周期内，我们可以使用一些在用户访问期间能够保持不变的信息作为临时踏板，例如IP地址，或者通过移动运营商的WAP网关（所有的浏览器会话都会通过WAP网关进行传输）传递的标识符。这样多个网站可以在一个visit周期内被关联起来，被记录为是这个访问者浏览过的网站。而在下一次访问周期内，访问者的IP地址或者WAP网关可能跟第一次访问时不一样了，我们该如何把下一次访问跟前一次访问关联起来归到这一个访问者（而不是两个访问者）呢？为了能够辨别这仍然是前一次的某个访问者，我们观察新一次访问到的所有网站中记录的第一方cookie有没有跟之前的访问网站记录相匹配的。在下图的例子中，正好有这样的情况。这个访问者在第一次访问中访问了Publisher 1、2、3；而第二次访问中访问了Publisher 1、5、19。由于每个网站都有第一方cookie，而两次访问又正好都访问了Publisher 1，因此可以通过publisher 1的第一方cookie知道两次访问是同一个访问者又回来了。并且我们也就可以知道，Publisher 1、2、3、5和9都是这一个访问者浏览的。根据运营商的不同以及运营商和广告商的关系，这个网关识别符存活期可长可短，理想情况下这个标识符可能永远不变。不过显然，这项技术只对于用户常常访问的网站才有效，而且广告网络也基本没办法实时使用这些信息。这种方法可以和数字指纹结合使用，能够提高指纹的准确性或减少生成指纹所需的计算次数。下图对上述方法进行了示例： 
 
 
 
 
 

  　　“不过，如果正好有访问者玩儿了App，又过了会儿上了网（通过手机浏览器），那么该如何辨识他们是同一个人呢？
 
 
 
　　“如上文所述，移动网站和APP分属不同的域，也各自使用着不同的标识符。从广告商的角度来看，这意味着用着同一台设备的同一个人，却被分离成了两个。从用户的角度来看，这不忠实于用户所选的拒绝追踪设置（包括监测和行为分析），明明在一个域下进行过追踪设置（例如在浏览器中停用了Cookie或设置了禁止追踪），在另一个域下却未被识别，因为广告网络也分辨不出来这是之前设置过拒绝追踪的那个人。而且App和网站页面之间为什么常常会跳来跳去，这也让人难以理解。
 
　　“将App和移动网站关联起来的最常见方法，通常是在用户点击一个App内的广告时生效的。用户点击的这个广告时指向目的地的URL对于该用户而言是唯一的，它带有一个能够映射到App域下用户标识符的URL后面的参数，而这个URL和参数，对于同一个设备上浏览网页时的相同广告主的广告，也是一样。即无论在App上做广告，还是在web上做广告，广告的URL后面的参数都必须一样，且这个URL用来标识这个用户。当用户转跳到了广告主的网站上，广告网络就能通过URL尾参中的标识符将App域下的标识符和网站的关联到一起。广告网络也会通过各种技术进行反向定位（举一个重要的使用场景：当用户在网站上看到一个关于新App的广告，例如最新、最酷的游戏，广告网络想要知道这个用户是否最终动心点击广告并且真正完成了下载。）不过，这些技术的应用前提是广告网络能够访问两种不同域下共有的存储信息，各操作系统对此的门槛也高低不同。”
 
译文版权归网站分析在中国以及译者所有，原文版权为Kevin Trilli，如欲转载请联系网站分析在中国
 
我的评注：
 
 
　　这个文章所描述的，是目前移动营销数据监测的一个缩影。移动终端比PC先天好的地方在于，有类似UDID或者IMEI这样的永久性标识来锁定一个设备，这使我们对于unique类数据（例如unique impression，unique click，unique visitor等）的追踪显得更加容易。但这些永久性标识却存在较大的隐私争议，而造成应用范围的不断萎缩。但如果没有这些永久标识，追踪unique类数据就比PC更麻烦了。这种情况下我们仍然不得不求助于cookie，第一方的和第三方的（事实上mobile cookie和web cookie实现方法是不同的，但它们的作用几乎一样，所以也被开发者沿用了cookie的名称），即使是在App中，我们也用曲线救国的方法装入cookie。
 
 
　　但cookie也遇到了问题，除了仍然让人心烦意乱的隐私问题，另一个麻烦是在用户体验上的，iOS系统下，可能会造成用户在点击进入App时，突然被踢出App，打开一个浏览器，然后又被踹回App的体验。Apple也在开始禁止开发者使用cookie追踪技术。
 
　　上面的原理全部集中在如何进行用户辨识和跨域（以及跨界，即跨web和app）上，那么如何辨识web上或是App上用户的具体行为呢？
 
　　从mobile web的角度看，与PC上的web的用户行为追踪原理没有太大的不同，同样需要依赖于cookie，或至少得用pixel tracking的方法（关于什么是pixel tracking，我正在写的书中间会详细说明）。而App内用户行为的追踪最常用的方法是通过SDK（软件开发工具包）在App内放置监测程序的头文件、库和其他模块，同时对你感兴趣的用户交互行为单独加上代码进行追踪，这颇像我们后面小节中要讲到的event tracking（事件追踪）的方法。具体的添加方法我不打算详细说明（它实际上就是一个技术执行手册），如果有朋友有兴趣，可以直接参考Google Analytics SDK的安装说明，见这里：https://developers.google.com/analytics/devguides/collection/。