江苏龙网

  1. 首页 > 人文 > >

「」从业务视角，分析埋点思路( 二 )

  • 预先定义数据结构还有一个好处 ， 就是能保持ios ， Android两端上报一致 ， 有利于提高后期的数据清洗及处理的效率；
    • 【「」从业务视角，分析埋点思路】 3. 埋点分类及示例
    「」从业务视角，分析埋点思路
    本文插图
    在埋点示例之前 ， 这里要简单介绍下埋点需要关注的信息 ， 这里总结为由“5W2H分析法”简化而来的“4W1H”用户行为模型；
    • WHO：用户属性；这里包括用户本身属性（性别 ， 年龄 ， 籍贯等）及产品属性（会员等级 ， 活跃度 ， 偏好的内容类型等） ， 因为属性本身不与行为的发生而随之改变 ， 所以不用在埋点中体现 ， 一般由user_id与用户宽表关联即可；
    • WHEN：发生行为的时间 ， 注意不是上报时间 ， 一般上报时间相比行为时间上会有一定的延迟；
    • WHERE：发生的地点；
    • HOW：发生行为时的一些状态 ， 例如操作系统 ， 网络状态 ， 屏幕比例 ， 分辨率等等；
    • WHAT：具体发生的行为 ， 例如点击 ， 曝光 ， 访问等 ， 这里会在后面的示例中展开；
    3.1 公共参数
    埋点时常常有一些公共参数 ， 即无论什么行为都需要上报的参数 ， 为了避免重复劳动 ， 这些参数通常是提前定义 ， 每次版本埋点默认上报 ， 下面列举了部分通用示例：
    「」从业务视角，分析埋点思路
    本文插图
    3.2 页面访问
    类似于公共参数 ， 一般页面访问也是底层定义好的逻辑 ， 无需重复定义
    「」从业务视角，分析埋点思路
    本文插图
    这里展开讲2个参数：
    1. 是否返回is_back：如果要统计某个页面的PVUV ， 若没有这个参数 ， 会无法区分用户从下一页面返回的数据 ， 导致数据偏高；
    2. 动态json串：有些页面需要上报一些定制化的参数 ， 例如订单页面想知道订单ID&订单状态 ， 内容页面想知道这篇文章的ID ， 以便精细化运营；
    3.3 曝光类
    顾名思义 ， 曝光埋点即不发生点击行为 ， 内容曝光时上报的埋点 ， 多用于内容流（商品流）的数据分析 ， 用来计算CTR（点击通过率 ， 点击次数/曝光次数） ， 用户时长（曝光时长） ， 下面以某电商App首页商品流为例做埋点示例：
    「」从业务视角，分析埋点思路
    本文插图
    3.4 打点类
    打点类埋点一般用来统计各类按钮点击的事件 ， 这里简单用点击点赞按钮做示例：
    「」从业务视角，分析埋点思路
    本文插图
    3.5 追踪参数
    有时候需要追踪用户单次使用产品或使用某个功能的路径 ， 个人习惯用user_id+时间戳作为追踪ID ， 这里需要注意要明确时间戳的选取 ， 例如追踪整个产品路径 ， 那时间戳就是打开App的时间；但若是追踪搜索行为路径 ， 那就需要用点击搜索框的时间戳作为追踪ID
    4. 写在最后
    写本文的初衷是在某职场社交App上做了个小调查 ， 结果表明大多数PM都需要在日常工作中负责埋点文档的输出 ， 同时PM新人又对埋点感到陌生和迷茫 ， 于是：
    本文用示例提供从业务视角设计埋点的思路 ， 仅根据自身经验总结的一家之言 ， 并不代表行业规范；如果本文对产品新人对埋点 ， 数据分析等方面有一点启发 ， 便是初心所在 。
    同时欢迎前辈们提供建议及补充~
    本文由@gxxx 原创发布于人人都是产品经理 。 未经许可 ， 禁止转载
    题图来自Unsplash ， 基于CC0协议


    推荐阅读


    上一篇：『每日经济新闻』成立五家“弗迪”公司 比亚迪电池业务拆分上市提速？

    下一篇：【】频率提升124% Intel奔腾MMX处理器超频到372MHz