一、活动分析的思路 @数据运营
虽然并没有负责做活动的分析，但是听到了不错的理论可以剽窃一下，至少如果让我去主持设计、评估一个活动，这将会是我最大的一个盲区：
不要局限于活动中火爆的数据表现，注意活动后数据的回落，其根本在于关注用户行为。
如果对活动结束后一段时间的数据也进行密切的追踪，可能你会不幸的发现你关心的指标如销量竟掉的比活动前还要低，这说明活动改变了你用户的消费行为，甚至让你的用户流失了。这种效果可能是因为用户享受了活动时的优惠，活动后的价格显得让人难以接受，或活动优惠让你的品牌形象大打折扣。
综上，一次活动是否成功需要关注的根本点在于：考察活动对用户的影响，如活动后新客的留存、老客的复购，活动后目标是否骤降，活动对用户的消费行为是否造成了影响。
与短时间内的激增销量相比，留住用户、引导用户的消费行为是活动最本质的目标，留的肥羊在，天天薅羊毛。
二、写了两周Bug的血泪 @数据提取
在连续写了快两周Bug以后，我觉得还是可以复盘出一些普适的方法论的：
1. 开码前明确需求和思路
说多了都是泪，如果在故事的开始就拿出流程图或者只是和无良的需求方嘴上讨论几句思路，一定可以省去许多无无用功；
2. 将大目标拆解为小功能
感觉到无从下手，嗯，还是因为问题大于能力值了…那就愉快的分功能块处理吧！
比如虽然没有办法一下子写出一个报表，先写(抄)一个处理日期的函数总是可以的嘛…最后拼拼咯…
菜鸟就请先别考虑代码是不是简洁的问题了；
3. Talk is cheap, show me the code
“嵌套字典/DataFrame/Panel？迭代/循环？面向过程/面向对象/面向函数？” Balabala蹦出一大堆技术名词，感觉自己像个很厉害的Geek在做技术选型，不知道到底要用哪个来写从而陷入深深的纠结…
终于我对面的朋友听不下去了：
别bb了，先写一个再说…没见过谁代码是一步到位不优化的。
我觉得他说得对，对于小白来说最艰难的可能就是敲下第一行代码吧！写着写着除非你是个傻子，不然总会发现自己写了很多重复的代码吧？是时候在优化时造个函数了…总会发现卧槽为啥程序运行这么慢吧？是时候在优化时改变提取数据的方式了…总之就别想着一下子写出一个不需要迭代的程序了；
4. 看文档没啥好说的吧
PS: 顺带记录一下本次的绊脚石们
- 找到一个直观的易于操作的数据结构 - Pandas.DataFrame()
- 处理日期 - datetime
- KeyError问题 - 太傻了