值点商家后台(头条的指点商城在哪里)

编辑导语:数据嵌入作为一种常用的数据采集方式,无疑对产品的正常运行起着至关重要的作用,嵌入点的质量管理尤为重要。那么,埋点过程中有哪些常见的质量问题呢?我们应该

编辑导语:数据嵌入作为一种常用的数据采集方式,无疑对产品的正常运行起着至关重要的作用,嵌入点的质量管理尤为重要。那么,埋点过程中有哪些常见的质量问题呢?我们应该采取什么措施来防止这些问题?

值点商家后台(头条的指点商城在哪里)现在互联网人对数据的使用是牛逼的,也是正常的。虽然有些人有日常工作,有些人只需要几次,但无论他们对数据的依赖程度有多高,我们在使用或解释数据时,都应该会遇到以下一两种情况。

团队来了一位新同学,想分析某个功能的数据情况,但感觉无从下手。便问老员工这个功能对应的埋点、那个页面对应的参数,得到的不是口口相传就是看着聊天记录中的文档地址。面对着黑压压一片的埋点信息,内心估计已经开始神兽奔腾了;新版本上线后进行效果分析,发现埋点出现纰漏,此时若是重要数据,需要紧急找人发版,时间紧张又担惊受怕;若此时是一般数据,开发同学的回复大概率是:“和下个版一起迭代”,时隔半年一年再进行分析,这段数据波动的原因估计也没人能说清了;测试同学拿着协作的埋点文档,测试过程中发现不是字段对应错误就是信息维护不全,解读起来麻烦不说,如果碰到大版本还需要进行埋点回归,不仅测试过程中工作量大,还有漏测的风险。

作为日常数据(包括业务数据和对外合作数据)最重要的三大来源之一,埋藏数据不言而喻。可以影响推荐、AB实验、数据分析的准确性;它会影响仓库的结构设计和日常维护成本。目前,数据被公司视为资产。试想一下,年底盘点,面对一组“不断剪不断理还乱”的数据,你会是什么样的心情?

我希望通过这篇文章,通过总结最近接手的埋地质量工程的一些经验,与大家分享我的体会。

一、埋点质量问题有哪些?

嵌入过程整个环节较长,涉及的角色相对较多。查问题难,周期长,团队合作涉及的问题不容易控制。下面总结一下哪些环节容易出问题,导致埋点质量问题。

值点商家后台(头条的指点商城在哪里)如果在输出阶段没有对数据进行控制,那么在应用阶段就会出现数据不完整、数据重复、数据不一致、数据不匹配等一些数据问题。因此,应采取“预防为主、防治结合、综合治理”的原则解决埋地质量问题。下面我们来看看如何管理埋地质量。

二、如何进行埋点质量管理?

实施隐蔽质量管理,笔者认为可以从以下三个角度实施:意识、制度、流程和工具。

1. 意识

这里所谓的意识更多的是一种价值观、信念或者一种行为“动机”。是每个学生为自己做事的软标准,类似于“道德”。

可能大家看到这里都觉得有些浮夸,如何管理一个墓地已经上升到道德层面了。别急,继续往下看。

对于执行层来说,无论是分析师还是嵌入式产品,都必须对自己的需求负责,时刻意识到嵌入式需求是整个数据链的源头,用户产生的实时数据是无法追溯的。如果从源头上“错、缺、乱”,后续环节不仅成本增加,这部分数据也会“白白流失”。

至于高级管理人员,他们应该在任期内对数据管理给予一定的重视,无论是人力还是时间。

让自己或者上级领导提高一些基础设施建设的意识,磨刀不误砍柴工。用产品向上管理很重要。说到底,它是一个看得见、用得着、价值“体验”的载体。如果只在乎光鲜的表面,什么时候才有机会去修补背后的“漏洞”呢?

任何组织在成立的时候都需要有一种文化或者信仰,做事情的时候也能时刻提醒自己。所以质量管理的第一个重要角度是意识。

2. 制度&流程

上面描述了意识的统一,下面从行为的规范开始。俗话说,没有规则就没有方圆。任何事情如果用好的标准去执行,出错的概率会比大家自由发挥低很多。

这里说的体系包括两个方面:角色流程和集合规范。

1)角色流程

从需求输出开始,嵌入点会经过嵌入点开发、数据上报、数据采集、数据清洗、数据入库,最后是业务应用。涉及的人员包括嵌入式单点产品&分析师、开发、测试、采购工程师、仓库工程师等。

各个环节的有机结合需要一个良好的协调系统,既能保证工作的有序进行,又能避免因权责混淆不能及时答复而导致的问题。

2)收集规格

①文件规范

文件要求负责埋点的同学列出相关需求点,包括需要的事件信息、统计位置、管理逻辑、上报时机等。甚至可能有如何处理失败、失败原因、变更历史等相关内容。详细的需求文档有助于减少学生在其他环节的理解偏差,也便于了解使用埋点时的前因后果和错误信息。

②访问规范

是指业务开发生在使用嵌入式组件时,要严格遵守组件方提供的SDK的使用规则,比如一般事件中扩展字段的嵌入位置和报告机会等。千万不要根据“自我体验”去改变和优化。

③命名规范

命名规范适用于掩埋信息的命名,包括事件ID、事件参数和实际参数值,并实现以下原则:

方便解读;不要有特殊字符,不要采用系统关键字或预置关键字进行命名;字段不易过长;版本前后字段映射统一等。

不能一一维护的参数值可以用SPM或者SCM模型来制定。

SPM,又称超级区位模型,是最早受土地户籍制度启发的区位系统。其目的是应用于页面的统计,跟踪页面来源等场景,埋点时通常作为埋点参数上报给数据后台。其编码形式由A、B、C、D四级组合而成,分别代表业务、页面、页面块、块内点。

我们以小红书商城首页为例:

商业:购物中心(shop_center)

页面:主页(home_page)

页面:美容季

街区点数:3

SPM模型可以写成:shop_center.home_page.beauty.3通过命名澳洲秋冬必备神级修复的地点。

统计的时候可以通过这个参数知道这个模块所在位置的流量。

SCM被称为超级内容模型,用于识别一段独特内容的模型。嵌入时,SCM模型的数据作为嵌入参数上报给数据后台。它的编码形式和SPM的一样,通过A、B、C、D四个层级进行编码,但四个层级记录的信息和SPM的不一样,分别是:内容来源、投放算法、算法版本、对应人群。

也以上面为例:

内容(内容_来源):商店

交付算法):cf

算法版本:3.3

对应人群):女性

本文内容:澳洲秋冬必备神级还原,如:shop.cf.3.3.woman

你可以统计一下这篇文章在不同位置显示的信息和流量。SPM和SCM是两种不同的编码标准。我觉得你可以根据自己的需求做相关的改进,比如改变层次或者定义。

3. 工具

1)埋点模型

嵌入点模型采用事件模型,描述了一个人做一件事需要的几个关键要素:时间(什么时候)、地点(哪里)、人(谁)、方式(如何)和结果(什么)。

比如小明4月3日上午9点在JD.COM买了一部iPhone12,翻译过来就是被埋没的语言:

值点商家后台(头条的指点商城在哪里)以上设备信息为虚拟信息,仅供参考。

目前实现上述信息采集的埋点方式有:代码埋点和无埋点。

①代码嵌入点

代码嵌入是一种根据特定嵌入需求收集数据的方式,也是最早收集用户行为数据的方式。

代码嵌入可以支持客户端嵌入和服务器嵌入。客户端埋点主要收集用户行为,服务器埋点收集更多的业务数据。

优势:

埋点可以做到按需采集、减少无效的信息上报;事件触发方式可以自定义,降低端上的资源消耗。

缺点:

新增埋点周期较长,需要跟随版本迭代;管理成本较高,造成系统代码“冗余”;采集数据有“缺失”,只能获取到上线之后的数据。

②无埋点。

埋点就是在末端识别每个块的元素,综合收集。

优势:

新版本上线也可看到历史数据;前端埋点成本低,管理成本低;埋点范围覆盖相对较广。

缺点:

数据冗余过剩;对应用开发的元素命名和开发规范要求严格;不能进行自定义数据的采集;服务端压力较大。

为了隐藏所有的数据&通常,这两个标准可以以两种方式结合起来。关键和非关键页面嵌入代码,非关键页面嵌入无代码。合理分配两种埋地策略,保证在合理的维护费用范围内不发生损失和渗漏,收集尽可能多和完整的数据。

2)埋地平台

虽然有了意识的“统一”和制度的标准,但相信还是有一些团队在用公开的文档来维护被埋没的信息。

文档维护的问题在信息量较小的情况下并不明显,但面对数百个埋点时,就会出现埋点信息维护不全、查找困难、测试生面对“海量”上报数据头晕目眩、测试容易遗漏、无法及时发现实际上报数据等问题。

因此,埋点质量的最后一个环节需要通过平台化进行管理,主要管理方向如下:

元数据管理完善、可溯源,提升查询效率;自动化测试+人工校验、降低漏测风险;质量监控,提升对错误埋点的发现效率;引入埋点流程、辅助进行“团队管理”。

①元数据的完善

元数据管理主要包括以下内容:事件基本信息、业务组织结构、当前发展状况、运营日志、变更日志。

事件基础信息:事件ID&名称、参数ID&名称、参数值ID&名称,统计口径、上报时机、版本、需求地址等。业务组织架构:事件归属的页面、功能层级结构等信息。当前开发状态:该事件所处的流转状态,包括:需求中、需求完成、开发中、开发完成、测试中、测试上线、灰度、正式上线。操作日志及变动日志:记录系统上所有人员对于元数据的操作日志以及该事件历史版本变动日志等。

有了完整的元数据信息,还需要提供完善的筛选和搜索机制,方便埋藏地用户管理和查询。

同时,平台可以根据嵌入式组件的规范和嵌入式信息,自动生成一段面向业务开发学生的代码,降低了嵌入式代码的开发成本和出错概率。

②自动测试

对于测试,借助完美的元数据,嵌入式平台可以提供:

自动化的测试功能:可以根据实际上报的数据明细自动比对元数据模块下维护的信息内容,在每次测试任务中都会自动提醒哪些事件不符合规范,极大的提高了测试效率,加上后期的人工校验,也会降低漏测的概率。规范的数据展示方式以及详细的信息记录:传统的测试方式一边需要对着文档、一边需要看着一条巨长的上报数据来找到需要比对的信息来确认埋点是否准确。平台完全可以结构化上报数据,隐藏无关维度信息,并根据上报内容关键字(事件或参数信息)自动去元数据内进行数据查询,埋点同学每次测试任务只需要了解版本需求范围即可。

③质量监控

就算测试通过了,埋掉一些数据会让人放心吗?肯定不是。大样本上线使用后,用户App各种型号都有,甚至有些信息会被篡改。

为了减少最终上报数据中的错误,嵌入平台可以提供质量管理模块,具体的监控策略可以根据数据质量评价标准的五大通用准则:完整性、及时性、唯一性、稳定性和准确性来设定。

值点商家后台(头条的指点商城在哪里)④引入嵌入过程辅助。

管理整个埋地平台的使用过程,按照上面2。系统&过程的角色被划分和管理。上线前,每个环节都经过相关负责人员的确认,多层确认机制可以保证埋单信息的完善性和准确性,也为后续管理带来了极大的便利。埋地平台的功能框架如下:

值点商家后台(头条的指点商城在哪里)第三,写在最后。数据质量问题会在业务发展的某个阶段遇到。就像你升职后需要管理一个团队,不同层级面临的问题不同,需要采取的手段也不同。

希望这篇文章能给即将面临这个问题或者已经身处其中的人一些借鉴。由于篇幅问题,涉及SDK、嵌入式设计、平台搭建的部分无法详细描述。欢迎对此感兴趣或有疑问的同学互相交流。

作者:一个数据人的私人保留;微信官方账号:一个数据人的保留

本文由@一个数据人私人预定授权发布,人人都是产品经理。未经许可,禁止复制。

题目来自Unsplash,基于CC0协议。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。

作者:美站资讯,如若转载,请注明出处:https://www.meizw.com/n/31508.html

发表回复

登录后才能评论