数据埋点:埋点文档/需求的理解和撰写

埋点文档的撰写,各家规范要求各不相同,但是我们理解它的核心后其实都能快速上手。

撰写埋点文档这不是一个人就能完成的工作,撰写的时候,我们需要去请教数据分析师和前端后端研发,大家一起来确立明确的指标,并且让这份文档有可读性而不是自嗨性。

搜索埋点文档,我们都可以搜索出一大堆相关的文档方案。这些方案确实是有用的,但是却忽略了大部分产品本身没有技术背景,很难去看懂或是理解这些文档。

同时大部分公司也不需要那么复杂的埋点文档用于管理埋点,因此对于埋点文档我们理性看待,不要为了装逼而装逼。


一、日常的埋点需求

工作中,埋点数据需求量最大的无疑是产品的营销运营。这类营销运营会分为常态化专题运营和热点营销活动两类。

常态化运营特点是短平快,要周期性的更新活动主题和内容,核心目的是稳固影响力。热点营销活动主打的是以近期热点作为主题,进行以业务目标为导向的活动。

在这种日常活动中就不适合使用那种完整的埋点文档,我们只需要在需求文档中简单的写明你需要的数据,交付给研发的时候在特别说明下即可。

例如:本次埋点需求

1、统计页面PV(点击浏览量)和UV(去重后的点击浏览量)

2、统计页面中A、B、C、D四个按钮的点击量(点击的PV)和点击人数(点击的UV)

3、统计本次活动的业务订购量

甚至可以让研发单独将这部分写成插件,后续活动直接调用即可,这也花不了多少的时候。这样一个能用的埋点需求就完成了。而接下来的实施部分,可以直接交给研发进行处理,你可以在随后的环节中和研发进行讨论确认一些细节。


例如:记录UV的时候,我们是用什么来作为唯一凭证?

1、手机号:实际能够接收到短信的手机号为准。但会因为需要接受验证码或要求登录从而对参与性要求较高。

2、IP:当前用户访问页面时所在网络的IP地址,会因为切换网络或使用代理进行变更。

3、Cookie:浏览器内保存的标识,包含用户私密信息,可通过服务器进行修改生成,但因大部分手机浏览器不支持而局限。

4、IMEI:移动设备的身份证,具有唯一性。一般需要使用app去获取安卓设备的底层权限。网页H5获取使用。在iOS设备上无法获取。一遍手机都可以修改,需要获取root(最高)权限,在使用软件修改即可。

5、DeviceCheck:iOS设备特有唯一设备码,之前使用uuid,但是因为苹果隐私问题iOS6后就禁止使用了。这个唯一编码只要不退出苹果ID并还原设备,就不会重置,唯一性较高。但是相同的问题,需要app去获取权限,很多H5并不支持。

注:唯一标识,是需求系统的核心指标,常用来作为推荐系统、数据系统等的唯一标识。

二、专业性埋点文档

相比较上面十分随意的埋点需求描述,在大公司面对完善的产品时,因为需求构建复杂的分析体系,就需要使用有深度规范的埋点文档进行管理,以便更好的在各层次中对埋点的理解达成一致。

所以复杂专业的埋点文档一般是公司体系大,产品完善度高的公司才会使用。

1. 存储类型

我们常见埋点文档中出现String、bool、key、value等类型注名,但并不理解他们的含量,这先做一个简单的讲解。

1、String(字符串):表现直接存储一段文本内容,可以是中文,也可以是英文。我们可用来记录用户搜索的内容获取发表的内容。

2、bool(布尔):只能表示true(是)和false(否)。我们已经用户记录用户是否点击按钮。

3、int(整型):记录自然数,从-2,147,483,648到2,147,483,647之间的数都可以使用。

4、float(浮点):这也是我们常说的小数点如1.21、5.20、13.14等等。

除了上面4个类型以外其实还有long、char等等类型,但是为了实用性,我们只要了解上面的4个类型,基本对我们撰写文档来说就没太大的问题了。

在撰写较为专业的埋点文档的时候,我们都需要基于需求去撰写。例如:我们的目标是想了解一段时间内我们的app使用率是否处于正常水平了解app(H5页面)的唤醒(打开)率以便评估是否处于均值。有了目标之后就进入第二部分事件拆分。为了完成我们的目标,用户会经历哪些操作事件?

我们一一进行拆解。首先用户会先拿出手机,其次打开或登录我们的app(页面),最后再进行其他的浏览、购买行为。

到了这里这就是一个十分简单的登录(浏览)事件,有了事件接下来就需要我们明确数据指标。在登录(浏览)事件中,我们首先要梳理的是哪个指标可以作为用户在我们系统中的唯一标识。

有了标识后我们要明确用户什么样的行为算一个有效的登录,是只需要打开app、加载页面就算,还是需要进行后续滑动、点击等交互行为后才算。这两个确定后我们就可以撰写文档了。

文档撰写每个公司要求都不一样,但是我们按照“便于理解”,“避免争议”的逻辑去写问题就不大。我们先将他们进行分类,本次埋点属于登录(浏览)事件,我们是以用户是否成功浏览页面作为评判标准,那么我们他们归于页面浏览这一大类中。

随后我们进行细化,页面的浏览也会因为页面的繁多而混杂,这里因为我们属于首页内容的浏览,因此它的第二类就算首页页面。有了这两个分类,我们就可以在后续有需要查询埋点的时候快速理解定位埋点,随后就是具体的埋点参数了。

这里假设我们使用IMEI作为用户唯一标识,之后因为我们是需要通过登录情况去了解我们的用户,这里我们可以判断她是否是首次登录,用于删选重复登录的用户,这样一个简单的埋点文档有雏形了。


同时因为代码是字母编码,所以我们要将文档中的中文名称给确定一个英文名称,这样我们后续就知道埋点在系统中叫什么。不然直接给中文,可能会因为每个人英语水平问题,造成埋点名称各不相同。例如手机号我取名叫number,你取名叫iPhone,他取名叫Telephone number这就乱了。因此我们最好加上他们的英文名称。


2. 扩展:预置属性

到后去业务埋点需求越来越多之后,我们的埋点会越来越多,最后在没有更好的管理下,直接每次找埋点找的崩溃。


所以我们不时对埋点进行整理,将通用的数据进行抽离,将他们单独抽离出来,抽离后形成一张新表,代表每个埋点在搜集数据时,都需要同时收集这张表上的预置内容。


这样后续我们只要慢慢根据我们的目标进行完善埋点即可。

3. 扩展:共性提取(key value)

除了预置属性以外,我们要需要一个代码类型《键值对》(我们理解为一个主键一个数值对应)。为什么理解?因为就算使用预置属性我们还是会面对埋点数据过多的问题,因为一个成熟产品最少都拥有10个以上的页面,更别说更加成熟产品了(淘宝、拼多多)。

面对大量页面不同,统计数据相同的埋点,我们要选择一套高效的管理手段。所以我们需要了解《键值对》(方法都是方便文档管理,而实际数据库存储是由研发设计规划,所以建议及时和研发进行沟通)。

键值对:按照名称,key值,value值进行存储。其中一个名称对应多个key值,一个key值对应多个value值,这里不想去理解key和value代表什么,毕竟我们不是研发。我们只需要他们所对应的格式即可,就像一级分类,二级分类,三级分类一样。

例如:

页面浏览(键值对的名称)— 首页页面(键值对的key)— 访问次数(键值对的value)

页面浏览(键值对的名称)— 详情页面(键值对的key)— 访问次数(键值对的value)

页面浏览(键值对的名称)— 购物车页面(键值对的key)— 访问次数(键值对的value)


(我这种方式我感觉只是文档管理方便,对于研发来说,还是需要看需求是否只是需要总数还是详情来设计数据库存储,一样麻烦。)

三、最后

埋点文档其实没你想象中那么难,也没你想象中那么简单。现在有太多的数据平台,神策、诸葛io、友盟、growingio等等,都是一套的解决方案,从采集到存储以及分析可视化等等。

所以其实去了解下他们的分析解决方案即可,没必要自己进行搭建整个一套,就像我开头说的,如果只是日常需要,就直接写想要什么数据给到研发就行,强行搭建费时费力,并且还不一定好。如果真要搭建那么还需要你多和研发进行沟通,毕竟代码是实现功能的基础。

-END-

作者:wcof,在努力做产品不做产品经理的人

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,423评论 6 491
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,147评论 2 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,019评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,443评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,535评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,798评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,941评论 3 407
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,704评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,152评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,494评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,629评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,295评论 4 329
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,901评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,742评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,978评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,333评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,499评论 2 348

推荐阅读更多精彩内容