![]() | 1 sirthisman 123 天前 参考下神策的全埋点方案试试? |
2 shunia 123 天前 这种问题不是应该在报告端解决吗?如果路径变了,上线后就要更新报告了,把新老两条路径合到一个口径的数据里。 既然都要求这么高了,数据报告平台应该有这个能力吧? track-id 之类的方案,如何应对动态创建的元素?出了 bug 咋整? 另外数据统计大部分情况下是统计趋势,绝对数字影响相对很小,综合考虑你们的实际需求看看吧。 |
3 Leoon 123 天前 GTM ?各种基本事件都会留痕了,硬找也能找着 |
![]() | 4 Torpedo 123 天前 我总觉得全自动埋点花费的经理,不如直接手动埋了 |
![]() | 5 tcper 123 天前 记得以前公司几乎每个需求都有埋点的要求,然后最多两三周有人关注,之后几乎没人关注 埋点,除了核心流程,关键步骤,比如付费,跳出之类的真正有意义,加那么多埋点纯属没事找事 在代码里还能看到两三年前的埋点,相关需求的产品经理都离职不知道几轮了,路径变化,业务逻辑变化,那数据早乱了,有谁关心?甚至根本没人知道。 搞这个东西别真上头,三个月前的埋点数据你看看有谁关心。 |
![]() | 6 Charbo OP ![]() @tcper 太真实了,跟我们这一模一样,然而就是人工埋点太乱,导致想看的数据没有埋点,临时加又得等几天才能看数据,没用的埋点代码又越堆越多。老板就想着搞成自动的,只能说的确能解决一部分问题吧 |
![]() | 7 shadowyue 123 天前 神策吧,交给专业的 |
![]() | 8 duanxianze 123 天前 楼上说的太真实了,所谓埋点除了刚做好那几天以后根本无人关注 |
9 cytsui 123 天前 推荐 GTM |
![]() | 10 yutong16 123 天前 还是推荐 GTM ,把上报配置结构固定好, 自定义事件结构固定好。产品想要什么埋点,自己去加,解放研发资源。 |
11 h1298841903 123 天前 如果是简单的标识唯一元素,那就不建议使用 data-track-id 属性,可以维护一个平台,维护元素路径和元素的关系。可以等到用的时候,再进行映射规则编写。当然,也可以结合 data-track-id 属性,对于重要的元素,也可以根据 data-track-id 来锁定其他元素路径。 我现在遇到的问题,其实是如何携带额外的参数,比如点击页面的任务 ID 、工单类型等非标准化的值,每个埋点要上报的数据还都不太一致,和业务相关。 |
13 riceball 122 天前 从系统上约定好 id 命名规范,比如: 'btn_RootCategory_SubCategory_MeaningfulName' 这样后期分析就好做些,这个是公司层面的问题。底层开发者无法解决. |