YUE.on(neoA3, 'click', function(evt) {YUE.preventDefault(evt)YUD.addClass(neoDiv, 'hidden')埋点new Image().src = 'atpanel/jsclick?cache=' + (+ new D鸡te) + '&cartframe=guanbi'})上面红色的字体就是埋点了，它不做页面相关的事情而是把用户当前点击的东西，传到服务器达到记录用户点击的每一步。
问题二：页面埋点 是什么意思 页面埋点的作用，其实就是用于流量分析。而流量的意思，包含了很多：页面浏览
(PV)、独立访问者数量(UV)、IP、页面停留时间、页面操作时间、页面访问次数、按钮点击次数、文件下载次数等。
问题三：java 程序埋点具体是指什么 就是在特定的地方打印日志，看看输出是否符合要求。。
问题四：页面埋点是什么意思 页面设置埋点的方法如下：
在2的位置插入
悬浮导航那里插入点击我连接到2
锚点的名字是可以随便改的。
页面埋点的作用，其实就是用于流量分析。而流量的意思，包含了很多：页面浏览
(PV)、独立访问者数量(UV)、IP、页面停留时间、页面操作时间、页面访问次数、按钮点击次数、文件下载次数等。
问题五：SPM埋点，CNZZ埋点是什么意思 玩QQ农场啊！挖坑种东西咯！
问题六：如何做好数据分析的第一步，数据埋点 整理真实有效的大数据。
问题七：整天看用户埋点数据，知道数据是咋来的吗 我们平时看到的报表复杂而多样，能够通过多种纬度的数据评估用户的使用习惯和对应功能的价值。然而这些报表是如何产生的呢?今天咱们就看看上报数据一步一步变成报表的大致流程。
所有上报的数据都是为了记录一次事件的发生或者描述一个状态，具体的上报数据可以设计为KEY-VALUE的形式或者数据组合的形式。KEY- VALUE的形式主要用来统计简单的计数类上报，如按钮点击的次数，某个选项的值等，KEY用来区分不同的事件，VALUE代表事件发生的次数、状态值等数据组合的主要用来描述一个事件或者状态需要多种属性描述的场景，比如下载成功事件，描述这个事件的数据组合可能包括对应的下载地址、下载渠道来源、下载耗时等信息。
当上报数据设计好后，后续的工作才能正常开展。下面一步一步说。
1、埋点
所谓「埋点」，就是在正常的功能逻辑中添加统计逻辑。拿统计微信右上角「+」的点击次数为例，上报的数据可以采用KEY-VALUE形式，我们定义 KEY为「CLICK_ADD_BTN」，VALUE的值为点击的次数。当用户点击「+」时，展示菜单的代码会通过按钮的「回调」(详见《聊聊同步、异步和回调》)来触发执行，程序猿在业务代码执行完后，又加上了统计代码，把「CLICK_ADD_BTN」对应的VALUE加1，「+」被统计到了一次使用。
2、上报
并不是每统计到一次事件或者状态就会发起数据上报，客户端统计到的数据会先暂时存储在内存或者磁盘上，当用户启动、退出应用程序的时候，或者在其他更合适的时机，将当前周期统计到的事件批量上报到服务器，这样做的目的主要是考虑到与服务器多次建立连接的性能损耗(详见《不得不知的TCP和UDP》) 和流量问题(相同大小的数据分多次发送比一次发送要消耗更多流量)，另外客户端在上报具体的统计事件之外，还会将标识用户的ID一并上报，后续用于计算用户相关的数据如日使用用户和留存率等。
3、后台记录日志
数据上报到服务器后，服务器会将客户端上报的原始数据存储到服务器的磁盘中。一般来说，非强实时性的数据上报到服务器后，并不会立即参与计算，获得最终的统计结果，比如一个功能的日使用次数，日用户数，日留存等数据，而是等到服务器负载较低的时间段利用预先配置的计划任务进行离线处理。这样处理的目的是为了节约服务器资源(钱)，因为大家肯定不想因为计算统计数据而影响实时业务的处理效率。
4、计算&入库
报表中展示的数据，并不是客户端上报的原始数据，比如「+」的使用次数、使用用户数、日留存率这三组数据，都是通过对客户端上报的「CLICK_ADD_BTN」对应VALUE值的累加并结合上报用户ID二次计算得出的。
如果我们的产品达到微信这种日登陆数五六亿，那么每天上报的统计数据将是海量的，为了从这种海量的数据中计算出「+」的使用次数、使用用户数等信息，就需要用到「数据仓库工具」，比如当下流行的Hive处理工具，它基于Hadoop分布式系统基础框架，利用计算机集群的能力进行分布式计算。当「数据仓库工具」计算出最终的结果后，计划任务会将结果(「+」的日使用次数、日使用用户数等数据)保存到数据库中，也就是「入库」过程。「入库」后的数据才能与前端对接，组成报表展示系统。
一般情况下，原始数据经过数据仓库工具处理后，对应的日志文件还会在服务器上保留一段时间(一般3~7天)，以便追溯统计问题，所以，如果发现统计数据有问题问题，一定要及时反馈给负责的程序猿，否则就会「死」无对证咯。
5、展示
当数据「入库」后，报表的展示就水到渠成了。报表系统通过前端页面用户的输入获取查询条件，然后通过后......>>
问题八：产品助理的职位描述中有一条：“知道如何埋数据点，取数据” 是什么意思？ 数据埋点，在链接中加一串指定代码吧，我之前做推广的时候做过。
不知道会不会折叠...
问题九：如何通过客户端埋点进行用户画像 目前的大数据在淘宝这种电商平台，尤其是商家可以使用的还是很有限，以前有个数据魔方，现在是专业版的参谋，您可以用付费版的进行店铺和产品的定位规划，所谓精细化就是找准一个类目针对一个人群进行深挖细分，比如大码女装也分为欧美，韩版简约的风格，这些数据可以借助市场行情和来分析，或者地域年龄的分析，对后期推广也有方向性指导意义，希望能帮到你。
问题十：什么是用户行为分析？怎么做用户行为分析？ 第一个问题，什么是用户行为分析：
过去的用户行为分析普遍的问题是：分析不聚焦、采集不全面、开发周期长、完全依靠人工埋点、事后分析、维度单一、指标传统。
所以当下可以把用户行为分析定义为：基于用户生命周期管理模型、全面采集所有数据、事中分析、提前预测、实时多维组合、科学维度划分、自定义指标的分析。
第二个问题：怎么做用户行为分析
你提出这个问题，证明你可能暂时没有数据分析团队，或者数据分析团队尚不成熟和完善，所以需要开展数据分析工作的话建议是借助第三方的平台。
这一块业务目前国内已经相对成熟，也有很多不错的合作伙伴可以选择了，硅谷的明星公司可以选择Google Analytics或者Mixpanel等，不过我最推荐的还是国内的数极客。
具体如何开展，我个人的建议是：
选择采用AARRR模型的平台，通过对用户全程行为的跟踪，让我们在经营中运营中，拥有Acquisition(获客)、Activation(激活与活跃)、Retention(留存)、Revenue(收入)、Refer(二次传播) 全程数据分析功能。
javascriptwu_wen_cai原创
关注
4点赞·2951人阅读
第一步：
使用 神策 插件 npm install sa-sdk-javascript --save
第二步：
在vue项目新建文件（sensors_config.js）// 初始化埋点功能
const sensors = require('sa-sdk-javascript')
sensors.init({
show_log: true,
server_url: '#', // 神策数据接收地址
is_track_single_page: true, // 单页面配置，默认开启，若页面中有锚点设计，需要将该配置删除，否则触发锚点会多触发 $pageview 事件
use_client_time: true,
send_type: 'beacon',
heatmap: {
//是否开启点击图，default 表示开启，自动采集 $WebClick 事件，可以设置 'not_collect' 表示关闭。
clickmap: 'not_collect',
//是否开启触达图，not_collect 表示关闭，不会自动采集 $WebStay 事件，可以设置 'default' 表示开启。
scroll_notice_map: 'not_collect'
}
})
// 注册公共属性
sensors.registerPage({
user_code: '123456789', // 工号
user_name: '张三' // 姓名
})
export default sensors
第三步：
在mian.js进行导入注册
import sensors from './sensors_config'
Vue.prototype.$sensors = sensors
第四步：
在神策元数据管理中
元事件中创建埋点事件（要埋点的事件，例如：点击）
事件属性中创建属性（要传递的参数或者公共属性，例如：点击的页面）
第五步：
在项目中进行点击埋点
<template>
<div>
<el-button @click="ClickBtn">点击</el-button>
</div>
</template>
<script>
export default {
methods: {
ClickBtn() {
this.$sensors.track("cs", {
// 传递的参数
source_page: '首页' // 点击的页面
})
}
}
}
</script>
<style>
</style>
vue项目前端埋点的实现
5下载·0评论
vue 项目中神策埋点
3162阅读·1评论·3点赞
Vue项目埋点方案
138阅读·0评论·0点赞
基于Vue的数据埋点统计
1201阅读·0评论·6点赞
神策埋点测试教程（图文介绍）
43下载·0评论
vue项目中数据埋点
1472阅读·0评论·1点赞
vue前端添加埋点事件
1570阅读·0评论·1点赞
前端埋点实现方案
3271阅读·2评论·8点赞
vue项目进行数据埋点
2344阅读·0评论·0点赞
神策埋点的接入使用方法
5010阅读·2评论·2点赞
uni-App神策数据埋点引入以及使用
580阅读·0评论·0点赞
神策数据埋点实操
1662阅读·2评论·3点赞
vue自定义指令实现前端埋点+重写路由方法监听浏览时间
571阅读·0评论·1点赞
Vue前端神策数据埋点
1550阅读·0评论·1点赞
Vue项目中，webfunny前端埋点部署
646阅读·2评论·3点赞
前端vue自定义指令（directive）实现数据埋点
115阅读·0评论·0点赞
vue自定义指令实现数据埋点
313阅读·0评论·0点赞
去首页
看看更多热门内容
作者 | 秦路
来源 | tracykanc
谈到数据驱动业务，离不开数据是怎么来的，数据收集是整个数据生命周期的初始环节。
数据生命周期的大体介绍，在过去的一篇文章中有提到。虽然文章的部分内容我准备重新构造，但是对于这部分的基础环节，并没有太多的变换。
文章会涉及到不少技术相关的知识，我会尽量减少这部分的细节。相信经过一系列的讲解，你会明白埋点数据怎么成为驱动业务的指标，文章也会提供网上的公开数据，帮助你实际上手操作。
需要收集的数据主要能划分成四个主要类型：行为数据、网站日志数据、业务数据、外部数据。
Web日志数据
网日志数据是Web时代的概念。
用户浏览的每一个网页，都会向服务器发送请求，具体的技术细节不用关注。只要知道，当服务器和用户产生数据交互，服务器就会把这次交互记录下来，我们称之为日志。
127.0.0.1 - - [20/Jul/2017:22:04:08 +0800] "GET /news/index HTTP/1.1" 200 22262 "-" "Mozilla/5.0 (MacintoshIntel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.66 Safari/537.36"
上图就是一条服务器日志，它告诉了我们，什么样的用户who在什么时间段when进行了什么操作what。
127.0.0.1是用户IP，即什么样的用户。不同用户的IP并不一致，通过它能基本的区分并定位到人。 [20/Jul/2017:22:04:08 +0800] 是产生这条记录的时间，可以理解为用户访问的时间戳。
"GET /news/index HTTP/1.1"是服务器处理请求的动作，在这里，姑且认为是用户请求访问了某个网站路径，/news/index。这里省略了域名，如果域名是www.aaa.com，那么用户访问的完整地址就是www.aaa.com/news/index，从字面意思理解，是用户浏览了新闻页。也就是what。
who、when、what构成了用户行为分析的基础。Mozilla/5.0这个字段是用户浏览时用的浏览器，它的分析意义不如前三者。
如果我们基于who分析，可以得知网站每天的PVUV；基于when分析，可以得知平均浏览时长，每日访问高峰；what则能得知什么内容更吸引人、用户访问的页面深度、转化率等属性。
上面的示例中，我们用IP数据指代用户，但用户的IP并不固定，这对数据口径的统一和准确率不利。实际应用中还需要研发们通过cookie或token获取到用户ID，并且将用户ID传递到日志中。它的形式就会变成：
127.0.0.1 - 123456 [20/Jul/2017:22:04:08 +0800]…
123456就是用户ID，通过它就能和后台的用户标签数据关联，进行更丰富维度的分析。
案例的服务器日志，记录了用户的浏览数据，是标准的流量分析要素。但是网站上还会有其他功，即更丰富的what，譬如评论、收藏、点赞、下单等，要统计这些行为靠日志就力有未逮了。所以业内除了服务器日志，还会配合使用JS嵌入或者后台采集的方式，针对各类业务场景收集数据。
在这里我提供一份网上公开的数据集，年代比较古老，是学生在校园网站的浏览行为数据集。数据原始格式是log，可以txt打开。需要的同学可以在后台发送「日志下载」。
它是标准的服务器日志文件，对分析师来说，IP，时间、浏览了哪些网页，这三个字段足够做出一份完整的分析报告。后续的章节我将围绕它进行演练，为了照顾新手，会同时用Excel和Python演示。
首先进行简单的清洗。如果是Excel，直接将内容复制，文件开头的内容只需要保留第四。
按空格进行分列，初步的数据格式就出来了。
我们仔细观察cs-uri-stem，会发现有很多无用数据。比如/images/index_r2_c1.jpg，它是向服务器请求了图片数据，对我们分析其实没有多大帮助。用户访问的具体网页，是/index.asp这类以.asp为结尾的。
利用过滤功能，将含有.asp字符串的内容提取出来，并且只保留date、time、c-ip、cs-uri-stem、cs-uri-stem。按c-ip和time按从小到大排序，这样用户在什么时间做了什么的行为序列就很清晰了。
像172.16.100.11这位游客，在凌晨30分的时候访问了网站首页，然后浏览了校园新闻和一周安排相关的内容，整个会话持续了半小时左右的时间
Python相关的清洗留待下一篇文章，这里就不多花时间讲解了。感兴趣，大家可以先自行练习一下。
APP行为数据
数据埋点，抽象理解便是记录用户在客户端的关键操作行为，一行数据便等于一条行为操作记录。点击「立即抢购」是，在文章页面停留5min是，发表文章评论是，进行退出登录操作是，视频网站首页看到了10条新视频的内容曝光也是...反必要的，我们都采集。
APP行为数据是在日志数据的基础上发展和完善的。虽然数据的载体是在APP端，但它同样可以抽象出几个要素：who、when、where、what、how。
who即唯一标识用户，在移动端，我们可以很方便地采集到user_id，一旦用户注册，就会生成新的user_id。
这里有一个问题，如果用户处于未登录状态呢？如果用户有多个账号呢？为了更好地统一和识别唯一用户，移动端还会采集device_id，通过手机设备自带的唯一标识码进行区分。
实际的生成逻辑要复杂的多，安卓和iOS不一样，device_id只能趋近于唯一、用户更换设备后怎么让数据继承，未登录状态的匿名账户怎么继承到注册账户，这些都会影响到分析的口径，不同公司的判断逻辑不一致，此处注意踩坑。
回到用户行为：
when依旧是行为发生的时间。
where即行为发生的地点，手机上，通过GPS定位权限，获取用户比IP更详细的经纬度数据并不难。
what是具体的行为，浏览、点赞、评论、分享、关注、下单、举报、打赏，均是行为，如何统计取决于分析的维度。
如果我们想知道用户的点赞行为，那么在用户点赞的时候要求客户端上报一条like信息即可。
如果只是到这里，还称不上埋点，因为点赞本身也会写入到数据库中，并不需要客户端额外采集和上报，这里就引入了全新的维度：how。
如何点赞，拿微信朋友圈举例。绝大部分的点赞都是在朋友圈timeline中发送，但是小部分场景，是允许用户进入到好友的个人页面，对发布内容单独点赞的。服务端/后台并不知道这个点赞在哪里发生，得iOS或安卓的客户端告诉它，这便是how这个维度的用处。
换一种思考角度，如果很多点赞或留言的发生场景不在朋友圈，而是在好友个人页。这是不是能讨论一下某些产品需求？毕竟朋友圈信息流内的内容越来越多，很容易错过好友的生活百态，所以就会有那么一批用户，有需要去好友页看内容的需求。这里无意深入展开产品问题，只是想说明，哪怕同样是点赞，场景发生的不同，数据描述的角度就不同了：朋友圈的点赞之交/好友页的点赞至交。
除了场景，交互行为方式也是需要客户端完成的。例如点击内容放大图片、双击点赞、视频自动播放、触屏右滑回退页面...产品量级小，这些细节无足轻重，产品变大了以后，产品们多少会有这些细节型需求。
行为埋点，通常用json格式描述和存储，按点赞举例：
params是嵌套的json，是描述行为的how，业内通常称为行为参数，event则是事件。action_type指的是怎么触发点赞，page是点赞发生的页面，page_type是页面的类型，现在产品设计，在推荐为主的信息流中，除了首页，还会在顶栏划分子频道，所以page=feed，page_type=game，可以理解成是首页的游戏子频道。item_id指对哪篇具体的内容点赞，item_type是内容类型为视频。
上述几个字段，就构成了APP端行为采集的how和what了。如果我们再考虑的齐全一些，who、when及其他辅助字段都能加上。
埋点怎么设计，不是本篇文章的重点（实际上也复杂的多，它需要很多讨论和文档and so on，有机会再讲），因为各家公司都有自己的设计思路和方法，有些更是按控件统计的无痕埋点。如果大家感兴趣，可以网络上搜索文章，不少卖用户分析平台的SaaS公司都有文章详细介绍。
除了行为「点」，埋点统计中还包含「段」的逻辑，即用户在页面上停留了多久，这块也是客户端处理的优势所在，就不多做介绍了。
这里提供一份来源于网上的我也不知道是啥内容产品的行为数据源，虽然它的本意是用作推荐模型的算法竞赛，不过用作用户行为分析也是可以的。
这几个字段便是用户行为的基础字段，像deep_view，虽然没有明确说明是什么含义，但也猜测是描述了用户浏览的深度，比如看了50%+的文章内容，它只能以客户端的形式统计，实际业务场景往往都需要这种有更深刻含义的数据。
具体的分析实操留待下一篇文章讲解，感兴趣的同学可以自行下载，和网页日志放一起了。
行为数据不是百分百准确的，采集用户行为，也会有丢失和缺漏的情况发生。这里不建议重要的统计口径走埋点逻辑，比如支付，口径缺失问题会让人很抓狂的，相关统计还是依赖支付接口计算。支付相关的埋点仅做分析就行。
APP行为数据往往涉及到大数据架构，哪怕10万DAU的一款产品，用户在产品上的操作，也会包含数十个乃至上百的操作行为，这些行为都需要准确上报并落到报表，对技术架构是一个较大的挑战。而行为数据的加工处理，也并不是mysql就能应付，往往需要分布式计算。
对数据源的使用方，产品运营及分析师，会带来一个取舍问题。如果我只想知道点赞和分享数，那么通过api或者生产库也能知道，是否需要细致到行为层面？这便是一个收益的考量。
当然啦，我个人还是挺建议对分析有兴趣的同学，去能接触到用户行为数据的公司去学习。
业务数据
业务数据是生产环境提供的，我们在APP端获得了用户user_id，文章或商品的item_id，乃至支付order_id，但它们只和用户的行为有关。换句话说，我并不知道user_id是什么样的用户。
是男是女，芳龄几何？出生籍贯，从哪里来？这些人口统计学的信息必然不会在行为埋点中包含。商品内容订单也是同理。
单依靠埋点的行为数据，我们并不能准确描述什么样的用户做了事情，也不知道对什么样的内容做了行为。描述性质的数据/维度是分析的价值所在。男女的行为差异，不同城市的用户群体购买习惯，这才构成了分析和精细化的基础。
业务数据和行为数据的结合，在数据层面上可以简单理解为join。比如把用户行为数据的user_id和存放用户信息的user_id进行关联起来。形成如下：
上图是简化后的字段。user_name和sex就是取自业务数据的用户信息，item_tag也是取自内容信息表中的字段，而event则来源于行为埋点。三者共同构成了，什么样的用户who在什么时候when对什么样的内容做了什么事what。
简单说，很多用户行为的建模，就是拿各种数据组合在一起计算。用user_id的粒度聚合，你算得是这些用户喜欢哪些文章，用item_id的粒度聚合，你算得是这篇文章被哪类用户喜欢。它们都是你看待/分析事物的角度。
从更深的层面上说，行为数据也是可以再加工和利用的，它是构成用户标签的基础。拿浏览行为数据说，我们设计了埋点，知道王二狗看了哪些类型的文章，
item_tag是文章类型，游戏、娱乐、科技这类。有些用户可能各种各样的类型都喜欢，有些用户的口味偏好则比较集中，产品上可以拿用户偏好来代称，这里专指兴趣的集中度。
现在取所有用户的浏览数据，算它们在不同类型tag下的浏览分布（上文提供的行为数据就可以计算，cate_id便是内容类型）。比如王二狗可能90%的浏览都是游戏，10%是其他，那么就可以认为王二狗的兴趣集中度高。
这里有一个很简易的公式，1-sum(p^2)，将所有内容类别的浏览占比平方后相加，最终拿1减去，就算出了用户兴趣的集中程度了。我们拿案例简单看下。
上图的李二狗，他的兴趣90%集中在游戏，所以兴趣集中度= 1 - (0.9*0.9+0.1*0.1)=0.18,李三妞的兴趣稍微平均点，所以1-(0.5*0.5+0.5*0.5)=0.5，兴趣集中度比王二狗高。赵四有三个兴趣点，所以比李三妞稍微高一些，王五是均衡的，所以是四人中最高的。可能有同学疑问，兴趣程度为什么不用标准差算呢？它也是算波动偏离的呀，这是一个思考题，大家可以新加一个tag类别再算一下。
1-sum(p^2)是趋近于1的，有四个类别，一位均衡的用户（四个都是0.25）是0.75的集中度，当有十个类型，一位均衡的用户（四个都是0.1）是0.9的集中度。这种公式的好处就是兴趣类别越多，集中度的上限越接近1，这是标准差比不了的。
这里并没有涉及太高深的数学模型，只是用了加减乘除，就能快速的计算出兴趣的集中程度了。通过行为数据算出用户兴趣集中度，便能在分析场景中发挥自己的用武之地了，它是用户画像的基础，以后有机会再深入讲解。
外部数据可以分为两个部分，一个是行业市场调研类的，一个是爬虫抓取的，它们也能作为数据源分析，比如站外热点内容和站内热点内容、竞品对手商家表现和自己产品的商家，大家有机会应用的不多，就不多讲了，我也不怎么熟。
到这里为止，文章主要讲了用户行为层面的数据是怎么来的，更多是基础概念的讲解，下一篇文章会通过具体的数据教大家用户行为分析的技巧。不过，因为数据来源于网上，数据的丰富程度还是欠缺了不少，说白了，业务场景比较弱，希望大家自己在工作中多思考。
