最初担任负责 SDK 方向的产品经理的时候，其实内心是充满疑虑的，最大的疑虑莫过于“SDK 还需要产品经理”?在实践的时候才发现，SDK 就是很需要产品经理，这个是在深入参与 SDK 的工作后的第一个认知改变。

看不见的需求

SDK 是数据采集这个环节核心中的核心。问渠那得清如许，为有源头活水来。SDK 就是这个源头的活水。从技术角度来说，神策分析本身的设计是比较精巧的，为了保证在私有化部署的情况下也能够拥有较强的性能，会尽量避免把类 ETL 的逻辑做进系统内，这就对 SDK 上报的数据质量提出新的要求，上报即可用。

从业务角度来说，可视化全埋点、热力图、Deeplink 这样看得见摸得着的需求，需要有产品经理来设计整个需求。也有预置的全埋点事件、预置属性这样看上去很技术，但是其实影响到整个数据根基的模块需要去负责，哪怕是一个看似是小问题的起名字，做的不好也会遇到大问题。

举个简单的例子，激活事件 Appinstall 在最初设计的时候没有作为预置事件直接设计出来，所以神策分析的系统没有可靠的依据能够判断到底什么事件才是激活事件。有没有可能因为客户的失误导致双端上报不一致，导致现在渠道迭代的时候需要做一个界面让用户明确事件名，这个其实是非常痛苦的，这一切源自于最早的一念之差。

作为 SDK 的产品经理，第一个面临的任务就是要起能够用 100 年的变量名，并且建立一个可靠的审核机制，这种需求乍一看有一些不务正业，但是又客观存在。更多的各个 SDK 的数据接入的需求，预置事件中预置属性写入的机制，都是影响统计口径的重要需求。这些需求最终其实体现出来的可能是预置事件多出来的一个属性，其背后需要技术顾问、研发长篇累牍的技术调研和在诸多限制下设计出来的业务逻辑。

看得见的需求

看得见的需求，最明显的就是可视化全埋点了。可视化全埋点一直以来是一个痛点，想要做出一个好的可视化全埋点，需要依赖 SDK 研发的力量。但是仅仅依靠 SDK 研发是不够的，还需要前后端、QA(质量保障部)同学的支持。“从 SDK 出发，不局限于 SDK”的责任心，书记体现的淋漓尽致，从文案到交互，项目进度到质量管理，书记全流程参与，不仅仅是站在 SDK 的角度，也是站在整个项目的角度，把项目管理做的井井有条。作为产品经理的我可以专心解决业务逻辑和业务交付的问题，其实是非常“爽”的。

实际上，SDK 研发还有很多同学是像书记一样，能做到“从 SDK 出发，不局限于 SDK”，比如现在负责“可视化全埋点”项目管理的韦章翔，比如被我拉壮丁来帮忙一起整理平台产品项目管理事务的杨站昆。就是这样的责任心才让项目能够落地，让大家成长，走的更远。

更好的数据根基

文锋多次在对内对外的演讲中提到数据根基，其实我们的数据根基是由很多东西组成，有 SDK、SDG、数据流和查询与存储的引擎。为了保证性能和可解释性，我们往往会尽力避免复杂的 ETL 行为以及数据修正的行为，很多数据可以说是开弓没有回头箭。

如何打造更好的数据根基，SDK 是冲在最前方的第一方队。希望在接下来的时间，能够以“让客户以最少的配置和最低的接入成本，获得最多和最结构化的数据”作为第一价值观，和团队一起打造一个中国最好的开源 SDK，让所有无论是购买神策的用户，还是不购买神策的用户，都用上神策的 SDK。

『说在最后』

看到这里了，如果你也对神策数据这家“不一样”的公司感兴趣，那么欢迎加入我们！可以投递简历到 HR@sensorsdata.cn 邮箱，也可以扫描下方二维码线上投递：

 投递简历 

温馨提示：

1、投递简历后请注意查看邮箱，笔试链接邮件有可能被归类到垃圾邮箱；

2、对于海外留学生，建议大家预留微信号，保证沟通及时畅通！

更多招聘详情，关注【神策数据】公众号，让你信息不遗漏，offer 不走丢！

✎✎✎

【更多内容】

• 神策面试官的修炼之道，选对人与吸引人 | 神策军

• 神策军 | 我有一本书，你拿思想来换

• 神策军 | 打破技术型思维：产品经理的门槛在门里面