编辑导语：每当电商大促时间到来，我们总是会忙得不可开交，特别是活动监控方面。我们需要实时反馈活动数据，以及时作出调整。那么，面对这种促销活动监控该如何做呢？

每年的618都很特别，那时候小伙伴是不是都在忙着加班，备战活动呢？特别是活动监控，每次活动领导都一次次催监控数据，搞得人紧张兮兮。

那么，到底活动监控该怎么做呢？就拿上个月我司刚做过的一个小活动举个例子吧。这个活动是一个很简单的全民派福利活动。

从5月10日开始到5月31日，用户登录APP后可以领一张优惠券，优惠券在5月内都有效，满400减80呢。

活动好简单呀！于是负责运营的妹纸做的汇报也很简单：

• 5月11日：28万人参加
• 5月12日：12万人参加
• 5月13日：8万人参加
• ……

像小鸡啄米一样，一个字一个字的嘣，然后当场被领导批了：进度不是这么报的！然后我就被要求陪着一起加班了。

为什么会被批呢？因为用领导原话：“这也看不出来啥呀！至少把目标加上吧！”确实，如果不带目标的话，也不清楚这些数字是好是坏。因此，做运营进度监控，第一条就是：与目标做对比，发现问题。

活动的总目标是100万人参加，50万人用券消费。那么是不是就直接拿现在的数据，和这个100万/50万对比呢？

当然不是，因为活动的时间长达22天，如果只看整体目标的话，在最后一天才发现：诶呀，不能达标！那就大势已去了。因此，做运营进度监控，第二条是：分解目标，树立标准。

理论上最简单的分解方法，就是100/22=4.5万。每天参加4.5万人就算达标。但是从实际数据看，显然第一天参加的人更多，第二天开始大幅度减少。因此很有可能参与人数的分布不是均匀的。因此可以参照之前的活动数据，看看每日参与分布。

找到4月份类似的活动为参考。当时有80万人参加，在4月12日到4月30日，活动参与数据如下表所示。为了看得清楚分布，可以分为：

1. 第一步：用SUM函数，计算整个活动总参与人数
2. 第二步：计算每日参与人数，占总人数比例
3. 第三步：画出折线图（10个点以上且是连续数据，用折线）

这样就看得很清楚啦。

从这个分布看，前三天是重点，之后每天也有3%-1%参与，结尾时有个小高潮。虽然5月份活动时间和4月份不一样，但活动形式是一样的，这样就能参考4月份走势。仿照4月份走势，做5月的目标拆解如下：

用同样的方法，可以拆解用券人数目标。有趣的是，用券人数走势和领券人数走势并不一致，在月底有明显高峰。猜：应该有两类用户。

• 一类：领到券立刻用，从数据上看，这个比例是相对稳定的。
• 另一类：月底券快失效了，收到提醒的时候才用。

因此计算最后一天的用券率，公式应该是：用券人数/（有领券人数-已用券人数）计算，经过估算，大概4月30日用券率是20%，如下图。

这样可以模拟出5月份的每天用券人数了。

有了这些判断标准，就能判断本月活动走势到底怎么样了。在对比目标的时候，每日完成情况与累计完成情况，都要做对比，因为二者含义不同。

每日完成情况：发展趋势如何？眼前的手段是否有效？

累计完成情况：整体上，还盈余多少，差多少。

5月数据做出来，结果如下图。

这样看，就比一开始光秃秃的只报数字，多说明了很多问题：

首先，整体领券情况并不好，5天下来，差了5万的进度。

其次，领券发展趋势也不好，除了第一天人暴多，后边每日差异都是负的。

类似的，也能做用券表对比如下：

啊，用券的结果，兼职更加惨不忍睹。这样下去，这个月的活动肯定会完蛋呀！得赶紧想办法了。可是，在短时间内，运营能想的办法是有限的。

1. 把领券放到更显眼的位置
2. 全体用户再推送一轮
3. 提前发用券提醒，让用户把券用一用

注意，这三种做法能起到的效果是不一样的：

1. 放到更显眼位置：增加每日用户参与人数
2. 强推一轮信息：立刻拉一批人参与
3. 提前发用券提醒：月底峰值下降，月底前用券率提升

体现在数据上，可能的效果有下图：

可是，看起来，这些都是临时抱佛脚的做法。很有可能是这个活动本身设计的不好。

比如就有小哥哥说：4月份活动效果好，是因为领的是满100减20。虽然满400减80看起来优惠力度是一样的，都是减了20%，但是要用户出320元现金，肯定比出80元更难。

嗯嗯，听着好有道理，但是眼下木已成舟，临时改规则，不但额外增加开发负担，而且对已经参加过活动的用户不公平，会被投诉的。眼下也只能救救急了。

至于是不是因为券的问题导致的，得等事后再分析了。

以上就是运营活动监控分析大体做法。就这么简单轻松，用excel就能完成哦。

做数据分析一般有3个场景：

1. 事前：策划类分析、预测类分析
2. 事中：监控类分析、原因类分析
3. 事后：总结性分析

作者：码工小熊，微信公众号：码工小熊

本文由 @码工小熊 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议