作者回复: 您好，感谢你的这个问题，问出了一个我们自己曾经也很纠结过的问题。 最开始，我们在服务客户的时候，也是想按照以终为始的方式，先去确定要看哪些指标，然后再看这些指标需要哪些数据，最后再确定去做哪些埋点。 这个方法从理论上当然是对的，不过，在实践中，会碰到一些具体问题，例如，一开始很难确定分析的范围，导致需要返工，或者说需求本身也发生了变化，需要增加埋点，这时候会发现已经无法回溯数据了，毕竟某些用户行为如果当时没有采集后面就再也没办法采了。 因此，在多次碰到类似的问题之后，现在我个人对于这个方法论有一些修正。因为技术的进步，目前网络和存储都挺便宜，而且全埋点这种方法需要的开发成本其实也不算太高，那么，在这样的大前提下，在不增加太多成本，适当多埋一些点，为未来的扩展性保留适当的空间。 不知道是否回答了你的问题，如果有更多疑问，欢迎留言我们进一步探讨。

作者回复: 您好，感谢你的问题。 你的观点是对的。在采集日志的时候，服务端 SDK 的作用除了通过网络发送数据以外，还有一个重要的作用是规范打出来的日志 schema，所以在神策的服务端 SDK 中，也是可以把日志打到本地的。 所以在实际的工程实践中，如果不想在打日志之前规范化，而是打出来日志再做采集和转换，当然也是可以的。只不过按照我们之前在百度的实践经验来看，“先污染后治理”很多时候还是不如直接打出好的日志的，这也是为什么我推荐在打日志的时候就通过 SDK 等方式，进行管控和约束。