Google Analytics 归因模型工具

众所周知,谷歌在免费版GA中没有开放归因工具的使用,而这个功能在付费版以及Double Click的reporting当中都是可以自由使用的。好在它的原理并不复杂,之前Lunametrics曾经放出过一个在线使用的版本,感兴趣的可以来这里下载,遗憾的是功能比较少,也不方便使用自定义渠道组。因此个人制作了这个excel版本的归因模型工具,使用方法很简单,简要说明一下:
1.打开Google Analytics当中Conversion>Multi-channel Funnel>Top Conversion Path报告,导出分析时段内所有路径数据的CSV
这里有几点说明:
建议使用自定义渠道组
Path Length调成All(全部长度包括首次即转化的路径)
按分析需要调节lookback window并选择时间段
尽量避免抽样(可以采用by周或by天导出报告避免)

2.拷贝所有CSV内数据到归因模型当中DS表单内
3.切换到Summary表单,在Channels下方填入所有渠道组
4.点击Process按钮,稍等片刻即会呈现渠道在不同归因模型下的表现报告
Tips:
默认情况下模型统计只包含路径长度大于等于2的转化,可以通过左侧按钮切换为所有路径(如果你的回访转化很少,建议保持默认设置)
可以通过过滤器(Filter)选择所有涉及指定渠道的转化统计,更加全面的了解渠道表现
如果没有正确填写渠道组,程序会自动提示并补足,重新点击Process运行即可

点击下载归因模型(Click to download Multi-channel Atrribution Modeling Tool)
如果还有关于程序的其他问题,请通过邮件新浪微博反馈

使用Google Analytics监测优酷视频播放

一直以来以为无法监测优酷视频播放, 原来优酷已经提供了相关API支持。当然监测是发生在自己的页面下的,也就是说我们需要申请一个youku开发账号,拿到client id后就可以对网站内所有引用的视频进行监测了。
方法很简单,可以参看下方代码:

<div id="youkuplayer"></div>
<script type="text/javascript">
var isready = false;
function onYoukuPlayerReady(){
    isready = true;
}
// call js api(pause video)
function pauseVideo() {
    if (!isready) return false;
    player.pauseVideo();
}
function onPlayStart(){alert("start")}
function onPlayEnd(){alert("Finished")}
</script>
<script type="text/javascript" src="http://player.youku.com/jsapi">
player = new YKU.Player('youkuplayer',{
        client_id:'44503cca1be605b5',
        vid:'XMzQwNjk3MDQ',
        width:480,
        height:480,
        autoplay:true,
        show_related:true,
        events:{ 
            'onPlayerReady': onYoukuPlayerReady, 
            'onPlayStart':onPlayStart, 
            'onPlayEnd':onPlayEnd  
        }
    } 
);
</script>

对于视频开始播放,播放完成,播放ready都可以通过在相应函数内填入代码实现跟踪。
而对于播放进度,需要写一段循环代码,首先用api获取视频总长度,然后每几秒种返回一下页面播放进度,通常我们会在25%,50%,75%时触发GA的事件代码。当然也可以利用onunload和onbeforeunload在页面关闭或离开时返回播放时长到GA server,这里推荐使用user timing,这样可以方便的获得播放时间分布。
上述的功能一般来说已经够用了,如果你还想监测播放,暂停,拖放等动作的话,可以在优酷的视频播放器上加一个浮层,在相应区域添加onclick等函数实现。
这篇文章只是一个大致思路,具体涉及代码有时间再更新,最后分享一个MV~



Play ………………. Pause ……………….. Seek to 30 second ………………. Get Play Time

Google Analytics中的隐藏函数

最近为了解决一个虚拟电商监测的问题,不得不打开firebug查询GA内部函数,把所有的函数导出以后发现了不少惊喜,当然也解决了问题。先把这些函数全部贴出来。

Functions in Google Analytics (DocumentedUndocumentedDeprecated)
1._addDevId 32._getTracker 63._setCustomVar
2._addEventListener 33._getTrackerByName 64._setDetectFlash
3._addIgnoredOrganic 34._getTrackers 65._setDetectTitle
4._addIgnoredRef 35._getVersion 66._setDomainName
5._addItem 36._getVisitorCustomVar 67._setHrefExamineLimit
6._addOrganic 37._getXKey 68._setLocalGifPath
7._addTrans 38._getXValue 69._setLocalRemoteServerMode
8._anonymizeIp 39._initData 70._setLocalServerMode
9._clearIgnoredOrganic 40._link 71._setMaxCustomVariables
10._clearIgnoredRef 41._linkByPost 72._setNamespace
11._clearOrganic 42._removeEventListener 73._setPageGroup
12._clearTrans 43._sendXEvent 74._setReferrerOverride
13._clearXKey 44._setAccount 75._setRemoteServerMode
14._clearXValue 45._setAllowAnchor 76._setSampleRate
15._cookiePathCopy 46._setAllowHash 77._setSessionCookieTimeout
16._createEventTracker 47._setAllowLinker 78._setSessionTimeout
17._createTracker 48._setAutoTrackOutbound 79._setSiteSpeedSampleRate
18._createXObj 49._setCampaignCookieTimeout 80._setTrackOutboundSubdomains
19._deleteCustomVar 50._setCampaignTrack 81._setTrans
20._forceSSL 51._setCampCIdKey 82._setTransactionDelim
21._gasoCPath 52._setCampContentKey 83._setVar
22._gasoDomain 53._setCampIdKey 84._setVisitorCookieTimeout
23._getAccount 54._setCampMediumKey 85._setXKey
24._getClientInfo 55._setCampNameKey 86._setXValue
25._getDetectFlash 56._setCampNOKey 87._trackEvent
26._getDetectTitle 57._setCampSourceKey 88._trackPageLoadTime
27._getLinkerUrl 58._setCampTermKey 89._trackPageview
28._getLocalGifPath 59._setClientInfo 90._trackSocial
29._getName 60._setCookiePath 91._trackTiming
30._getPlugin 61._setCookiePersistence 92._trackTrans
31._getServiceMode 62._setCookieTimeout 93._visitCode

这里面红色粗体的几个函数非常有趣,比如这个_clearTrans就解决了同一页面虚拟电商监测重复触发的问题,它可以清空数组内的历史交易记录,这对于采用Flash制作的页面特别有用。setMaxCustomVariables其实之前曝光过很多次,虽然目前还无法在免费版GA使用多于5个以上的CV,但是其实是可以向GA发送额外的CVs,如果今后GA开放了10个CV的话是有可能直接获取到这些历史数据的。setPageGroup, setAutoTrackOutbound,setTrackOutboundSubdomains这几个不知道有没有人使用过,如果work的话相信可以简化很多自定义代码的工作。

移动应用QC方法

通常在移动应用监测代码添加完成后,我们需要通常需要测试一下监测代码是否正确添加了。在PC端我们有很多类似的测试工具,比如HTTP Watch,HTTP Fox等,而对于移动应用,这里推荐简单易用的免费工具Flidder2,测试的前提条件是移动设备与PC处于同一WIFI环境下,推荐使用笔记本进行测试。

1.首先需要启用Flidder2的代理功能,启动Flidder2,点选顶部菜单Tools>Flidder Options>Connections,勾选Allow remote computers to connect,端口号默认是8888,如果有冲突可以更换,配置完后点OK,退出Flidder再次进入使代理生效。

2.获取PC端IP地址,Win+R打开运行窗口,输入 cmd 并回车,进入后输入ipconfig,IP Address即为PC端地址(下图中IP地址为192.168.1.2)

3.移动设备端需在WiFi设置内填入相应代理。这里以iOS设备为例,依次点击 设备>Wi-Fi>当前WiFi右侧箭头,在下方选择手动,并填入刚刚获取的IP地址和之前端口号(8888)

4.此时移动设备的配置已经完成,试着打开应用测试吧,所有网络请求都会被flidder截获,通过设置右侧的Filters可以方便的筛选结果。

 

Google Analytics UTME参数详解

今天我们来看一下GA中的utme,这个参数很有趣,主要包含三类信息:事件,自定义变量以及时间。
首先来看一下最简单的事件追踪中utme的格式:
5(category*action*label)(value)
以5开头,category,action,label这些字段之间用*号分隔, 可选参数不存在时则不显示相关字段

接下来是自定义变量中utme的格式,比较复杂:
8([s1!]Var1-name*[s2!]Var2-name*…*[sN!]VarN-name)
9([s1!]Var1-value*[s2!]Var2-value*…*[sN!]VarN-value)
11([s1!]Var1-scope*[s2!]Var2-scope*…*[sN!]VarN-scope)
简单来说自定义变量的名称,值以及类型分别以8,9,11开头 。每个自定义变量间以*号分隔,而[sN!]则代表自定义变量的slot number,当sN-1变量存在时sN不会显示,换句话说,sN-1变量不存在时sN必须显示。
我们来看一个例子, 如果有三个不同类型的自定义变量:

自定义变量1(Slot 2): name = apple, value = iphone, scope = 2 (visit level)
自定义变量2(Slot 4): name = microsoft, value = winphone, scope = 3 (pageview level)
自定义变量3(Slot 5): name = google, value = android, scope = 1 (visitor level)

相应的我们在utme中可以看到:
8(2!apple*4!microsoft*google)9(2!iphone*4!winphone*android)11(2!2*5!1)
注意自定义变量类型(scope)为默认的页面级别时不需要显示,也就是说本应显示为11(2!2*4!3*1)被简化成了11(2!2*5!1)

最后再来看一下时间监测。主要有两种类型的时间监测,页面加载时间和用户自定义时间。
用户自定义的时间格式较为简单
14(90!Label*Category*Variable*TimeValue)(90!TimeValue‘)
以14开头,格式类似于事件跟踪,不过这里指定了slot number为90。这里有一点不明白的地方就是TimeValue,仔细观察上面的两个TimeValue会有一定区别,第二个TimeValue会精确到毫秒(个位),而第一个TimeValue则会进行一定精简,具体原因不明

页面加载时间的格式如下:
14(Time1*Time2*Time3*Time4*Time5*Time6*Time7*Time8)(Value1*Value2*Value3*Value4*Value5*Value6*Value7*Value8)
代码示例:14(12800*0*0*1710*4790*0*8300*8300)(12844*0*0*1718*4797*0*8344*8344)
同样是以14开头,之后的8个字段分别代表:
Time1: Total Time
Time2: Domain Lookup Time
Time3: Server Connection Time
Time4: Server Response Time
Time5: Page Download Time
Time6: Redirect Time
Time7: Dom Interactive Time
Time8: Dom Loaded Time
这里同之前的用户时间存在同样的问题,真实的时间变量是存储在第二个括号内的,而第一个括号内的变量降低了精确度,原因不明,也请知道的同学给我留言。
另外针对页面加载速度特别说明一点,我们看到的total time其实是由navigationStart截至到onload事件触发,因此2+3+4+5+6+8并不等于total time,感兴趣的同学可以参看一下navigation timing的API