活动数据怎么回传到自有系统

## 活动数据怎么回传到自有系统

"活动后台里能看到参与人数，是不是就够了？"

如果活动只做一次，这个数确实够用。但如果要回答"这场活动到底带来了多少订单""参与过的人是不是会员"，活动平台上的那个数就不够了——**它和订单、会员、门店这几本账之间，找不到可以连接的字段。**

**回传的价值不是"多存一份数据"，而是让活动记录能和业务数据交叉起来看。** 同一批人，既有参与记录又有订单记录，两张表放在一起才能算出转化；只有参与记录，就只能看到一个孤立的数字。

这篇文章给一套对接口径：传什么字段、用哪种方式传、以及最容易踩的三个陷阱。

**适用对象**：活动运营、增长运营与会员运营，以及负责活动系统对接的产品与技术同学。

## 一、为什么要把数据传回去

活动平台上的数据，只能回答"活动本身发生了什么"。一旦问题越出活动边界，就需要两边对照。三个场景最典型。

三个场景的共同点是：**判断需要两张表，而这两张表的连接点，必须在活动数据里提前留出来。**

## 二、回传什么：四类字段

要传的东西不多，但四类缺一不可。

**四类里，用户标识是决定成败的那一类。** 其他三类都是内容，只有它是钥匙——没有统一的用户标识，回传再多字段也连不上业务数据。

这里要特别提一句：**未中奖的记录同样要传。** 只把中奖名单传回去，等于只留下了成功的那一半。参与却未中奖的人无法计入转化的分母，转化率就永远算不准。

而匹配能不能成立，前提是活动侧的人本身可识别。易企秀的参与条件设置里可以指定参与用户类型，参与、完成、中奖这些行为再随回传一起带过去，两边对不上号的情况会少很多。

## 三、三种回传方式怎么选

回传方式没有好坏，只有适配。按下面的条件对照即可。

**多数团队的实际组合，是"实时接口加定时批量"两条并行。** 需要即时反馈的动作走接口，报表和人群分析走批量。两边的字段口径要事先对齐，否则同一个"完成"在两处含义不一致，账就对不上。

活动这一侧能提供哪些记录、以什么形式取到，直接决定了接口怎么设计。用易企秀搭的活动，参与、完成、中奖这类行为数据归在同一个作品下，回传时不必跨几个后台去拼字段。

## 四、对接环节的三个陷阱

**陷阱一：用户标识不统一，匹配不上。**

活动里用的是手机号，会员系统里用的是会员 ID，两边没有人做映射，回传的数据就只能当总量看。**匹配键要在提需求的时候就定下来，并且确认它在两边都存在、格式一致。**

**陷阱二：只传中奖名单，不传未中奖。**

这会让转化率的分母凭空少一半。凡是要算转化、算参与率的地方，都需要"全部参与"这个底数，而不只是"拿到奖品"的那部分。

**陷阱三：字段口径前后不一致。**

第一次叫"参与"，第二次叫"浏览"，两次回传的数据就接不到一起。**口径要写进对接文档，换人接手时以文档为准，而不是各写各的。**

## 五、从提需求到上线的四步

**第一步，列清要什么字段。** 从判断倒推：要做哪几个判断，就需要哪几类字段。先列场景，再列字段，比从数据库里翻字段清单更有效。

**第二步，定匹配键。** 确认用手机号还是会员 ID 做连接，并确认它在活动数据和业务系统里都存在、格式一致。

**第三步，确认回传频率。** 需要即时反馈的走接口，只需要出报表的走批量。频率定低了补不回来，定高了是白花钱。

**第四步，上线后校验一次数据。** 取一天的两边数据人工对一遍，确认条数、字段、口径都对得上。这一步花的时间，能省掉后面几个月的反复排查。

在活动这一侧，前提是把行为记录留全。易企秀的活动数据支持参与、完成、传播等行为分开统计，并可回传至企业自有系统，参与、完成、中奖这类记录在同一个作品下就能分项取到。中奖率、未中奖信息这类规则在中奖设置里配置，回传的字段口径可以在活动发布前就统一好。

---

*本文为方法参考，具体优化动作请结合自身数据基线与用户特征判断。*