我将会在接下来的几篇文章里，以一个连续迭代了7个月做了7期的UGC活动为背景，给大伙介绍一下活动运营都需要做些什么。本文适合1~3年的运营人，从更全局的角度去看一个活动运营。

活动运营流程图：

理论上，上述时活动的基本流程。单单看这个，或许对活动运营的时候真正要做什么，遇到什么，还是没有对应概念。且看下文的分解。

活动运营：活动的前期准备

一个重运营的活动，如果规模较大，且前期无相关活动模板，则前期需要大量时间搭建模块，准备素材、跨部门沟通。

如下图所示：

此图将活动运营的前期准备分为：

1. 活动产品线（活动线上承接页面及后台制作）
2. 运营线（特指活动上线后运营）
3. 推广线（活动的曝光和传播准备）

接下来会对这三个方面运营分别要做什么进行详细介绍，同时实际工作中需要注意到，这几条线是几乎同时进行的，且其中大部分工作都需要在活动上线前完成。

另外次图仅仅展示在活动目标确认且获得老板首肯之后要做的事情，即真实的定位应该是：确认了活动目的及将要落地的活动，其前期准备详解。

（省略的步骤是：做活动提案，写明活动背景、玩法、预算、效果、各部门支撑和风险等，做成ppt找上级审核找老板审批拿钱。老板首肯后，这个活动规则就可以细化准备执行了）

1.1 活动产品线

背景：一个线上活动，最基本的功能需求肯定是用户承接页，然后根据活动的需求和复杂程度，还需要增加相应的运营后台、用户信息提取及展示等功能。

思想预防针：产研支撑不一定能制作并满足最流畅的用户体验流程，其他部门的支撑合作程度不一定能满足活动运营需求，可能要以增加运营成本为代价。保持着把活动做到最优的期待，然后清楚这种最优可能要逐步实现而不是一次办成，才能在做活动的时候遇到层层阻碍而不会心灰意冷。

1.1.1 确认产品需求

通过明确活动目标、细化的活动规则及用户参与流程，就可以得出基本的产品需求，在加上其他部门的支撑反馈，则第一期的产品需求就能基本敲定了（但不等于真正实现）。

【其他部门的支持】其他部门的支持程度也会在一定程度上影响产品需求，所以在做提相关需求前（或同时），必须自己把流程试走一次，然后将这个流程中将会涉及的其他部门（通常是财务部）的支撑工作给缕出来，尽早找对应部门商量看看需要怎么实现。然后以最简参与流程为标准，输出产品需求。

例子：

在做一个UGC活动的时候，由于要给用户发奖，我们希望给用户发的步骤和体验可以尽量简单，而此处涉及财务。

财务提供两种办法让我们发放奖金：

1. 现金发奖（走活动经费借支流程）；
2. 拨款至用户账户。

第一种方法会涉及大量的运营清点及发奖等人手动作，第二种方法则对用户还是运营而言都更简单些，但需要财务开放流程，且财务系统于活动系统相关数据需要打通，而且需要产品研发支持。

我们经历了从方法1到方法2的过程，这个推动持续了4~5个月，像是一点点地撬动财务想办法给处更简便的用户参与及获奖体验。同时对应的产品功能也是一点点地迭代调整。

产品的参与：

有了产品的参与，运营要做的事情可能相对简单一定，把自己需要的梳理出来，交给产品去画原型，期间沟通好，确认产品把运营的需求完美展现并优化出来就好。同时，较好的产品经理会帮助运营将活动原型的用户体验实现到可执行范围内的最优，同时也会帮助运营与各个支撑部门沟通以助于实现相关功能。

需要注意的是，产品会有一个内部需求会，通常在资源有限的情况下，内部需求会过后，活动的一些产品功能可能会被砍掉，所以这里的前提是与产品沟通清楚，活动原型产品功能的轻重缓急。

思想预防针：需求是会被砍的，也可能以打了折扣的形式展现的，持续推动不断优化就好。能说清楚需求的轻重缓急和收益，是让需求更快实现的前提。

1.1.2 输出产品原型中需要填充的文案

上面说到产品的参与会给运营省去很多麻烦和工作，他们会画产品原型，展现活动的架构及交互需求，但其他的页面文案，就需要由运营提供。

大致的流程是：落实产品需求——运营提供文案（标题、规则、按钮文案、交互文案等等）——设计（页面设计）及技术（运营后台制作）制作。

文案有哪些：文案真的有很多。

• 页面文案（主副标题、活动流程、活动规则、奖励标准、按钮文案等等）
• 触达消息文案（大致是指，用户报名后收到的短信、用户获奖收到的短信等等基于用户某个动作后产生的站外提示性内容）
• 交互文案等等（大概如：用户任何做任何预想中的交互动作后给出的弹窗提醒或下一步动作引导，比如提交成功了，可能会说“恭喜您提交成功”、“将于XX个工作日内反馈”、“添加XX微信了解进度”等等。）
• 产品文案（譬如：在后台页面上，需要记录的信息表头，或者信息状态判别项等等此类产品文案）
• 其他……

另外，有一些文案是要交给设计放到图片里面的，有一些文案是给研发部门做适配的。做适配的文案例如：一个滚动文案说，“XX用户赢取了XX元”这种类型。文案到底是直接显示在页面里，还是做适配，就看运营需求了。

例子：下图的所有文字都是需要运营提供的文案，而产品提供的，只是其中结构排版。

1.1.3 活动产品设计及研发的跟进及沟通

活动产品线方面，通常有产品经理跟进的话会省心很多，但不是说运营就放着不用管。因为运营是活动的需求方，因而对于活动的设计、开发需求，会比产品清晰很多。

设计跟进方面：如果希望活动省心省力进行，提交活动设计需求时，除了产品那边提供产品原型，运营方面最好能找到期待的风格素材作为设计参考。

与设计沟通的理想流程应当是：

• 运营与设计确认设计公司设计风格规范；
• 运营到相关网站寻找若干个符合活动风格，且符合公司设计规范的设计样板供给设计参考；
• 设计做好大致风格样式后及时与运营沟通；
• 确认风格及元素ok后完成设计。

而现在很多无经验者走的流程是：

• 运营提需求后，设计根据产品原型及活动主题，给活动设计活动页；
• 设计完成基本页面设计，与运营沟通；
• 若运营认为设计的风格与想象中有较大差异，则需要再次沟通调整风格；
• 设计修改，持续沟通；
• 由于时间关系设计无法做大规模调整，初步定稿。

虽然也有很幸运地设计就设计出运营想要的页面的情况，但这种情况太考究设计和运营间的默契。所以为了减少来回沟通，给设计需求时最好是同时给出风格参考。
（做这个UGC活动时，运营就曾跟设计就头图的展现开了一个下午的会议来商讨，而那个下午，运营才了解设计对公司的活动图的设计风格及元素要求具体且严格到什么程度。)

开发方面：运营与开发方面通常要沟通的问题基本是确认某一个功能的实现，而这里的复杂程度就和产品的后台数据相关。
我经常遇到的情况是，开发问：你这里是要实现XXX功能吗？是的话，把其设计的所有数据定义情况给我。

例子：

曾经为了达到某个运营目的，提出了读取该订单的完成信息，以便运营判断该订单是否有资格参与活动的概念性需求。而这个需求到达开发处，应当翻译为：读取后台订单状态中，其中A、B、C定义为订单已完成，D、E、F定义为订单未完成，G、H 定义为未知。读取后在活动后台展示”已完成/未完成/未知“。

可能很多功能提需求的时候运营和产品都未意识到其中数据的复杂性，当研发真正落实的时候，就会发现这个问题，并需要运营进一步落实。

1.1.4 活动上线前测试

上线前，运营应该在测试环境下，按用户参与流程及运营逻辑将活动体验一次。尽管有测试帮忙测bug，但运营可以测出活动流程逻辑是否有bug（与预期不符）。

以上就是产品线相关的工作问题。

在运营过程中会发现，提需求花费的时间不多，但在沟通上花费的时间可能会更多一些。和产品的沟通交流时间是必不可少的，产品越是了解活动需求，越能做出符合运营期望的产品原型。

至于与设计和开发之间的沟通上，运营可以在每次沟通过程中了解设计和开发的思维逻辑，提需求的时候可尽量顺着他们的逻辑去走，这样会减少沟通时间。

1.2 运营线

前期准备越充分，活动上线后的麻烦会越少（自然不能避免有麻烦，毕竟一般人不能穷尽所有麻烦情况。）

可能需要考虑到的：

• 用户对活动的咨询
• 活动后发放奖品的采购

例子：

用户对活动的咨询：以这个UGC活动为例子，由于写长篇UGC内容有一定难度，需要运营介入引导与鼓励，所以肯定涉及不少的沟通。且在活动流程上，我们确认了需要添加用户微信来保证有效沟通，所以跟用户有必不可少的对话。

通常用户产生的问题和困难80%都是相似的，对于这类型的问题，我们可以预测其中的FAQ，整理好相应的话术文案，以便活动上线后能更加从容应对。若是遇到操作类或较为理解上较为复杂的，可以通过图文解释，增加可读性。
曾经，我们给到用户的规则描述，是一大段微信文字，用户长段文字的解读显然不在行，很多问题会问了再问，而将这种复杂文案做成图文之后，情况就优化了很多。

例子：

关于活动后发放的奖品采购：如果奖品是用户支线活动（促进主线活动玩的），那就必须和奖品管理的相关部门了解清楚剩余奖品数量、申请流程等细节。

曾经我们有一个奖品是一个毛绒公仔，当时库存剩余20个，同时可能会有4个主要部门的人申请，毛绒公仔从制作到到货的时间需要2周，如果要申请采购，需要走流程层层上报，整个申请流程走起来，最少需要两天。

所以如果没有前期了解好这些信息，贸然答应给用户一些奖品，最后真正需要兑现的时候容易捉襟见肘。

1.3 推广线

活动上线了就要推广才有用户知晓和参与，不同活动目的需要的推广资源不同，不同推广资源的流量不同，需要提供的素材也不同。

一般app有闪频（一打开app看到的）、有banner（一些轮播横幅广告）。闪频只要一开app就能看到，浏览和点击量都很高。banner还根据页面和位置的不同有不同的点击量，那我们做活动的时候，是要banner还是要闪频，还是都要？

• 看目的（我是否要那么大的曝光/我是否有能力和预算承接那么多用户？）
• 看功能（我的活动需要特定时间向特定城市特定类型用户曝光，这些资源位/渠道是否能做到？）
• 看排位（这些资源位都有排位吗？）

1.3.1 梳理可用推广位

一般推广位可以分内部外部，一个站内的活动，可能内部推广位已经足够了，如果涉及外部推广位，通常与拉新目的相关。

• 内部可能有：各种自营媒体（微信、微博、抖音、支付宝生活号……）、产品资源位（banner、闪频、feed流、push等等）、EDM、短信；
• 外部推广位：外部资源合作（其他线上线下广告位）。

例子：

这个持续在做的UGC活动，在不断迭代的过程成挖出了不少资源位。

• 已在运营的资源位：闪频、banner、分级页面banner。其中尤其是banner和分级页面banner，在后期已经和对应负责部门预定好了每月的固定位置。
• 新增的资源位：触发类型（用户下单后推送活动，用户完成订单后推送活动）、固定位置类型（菜单栏中的特定类目、用户订单页面新增按钮）。

ps：对于新增资源位的挖掘逻辑，就是根据用户的使用流程和使用逻辑，在合适的地方埋下曝光活动的点。当然这么做的前提是有产研支持。

1.3.2 根据活动的推广节奏，与相关部门安排好资源位需求

有些资源位并不能长期被占领，因此必须根据活动的节奏，安排资源位的上线时间，如：banner、闪频、弹窗等。

有些资源位可能可以长期发布，但内容需要经常更换，如：微博、抖音等社交媒体，另外邮件、短信、push、微信推文也可视为次类型，但频率需要控制在该部门建议范围内。

1.3.3 确定资源位需求，向设计、技术等部门发起需求

不同资源位需要的物料不同（图片、文案等），图片需要设计协助制作。有些资源位可能需要前端切图，如：邮件中的有交互效果的“图片”。

1.3.4 输出相关资源位需要的相应文案

比如微博：在不同的活动周期（前期、中期、后期），需要用的文案时不一样的，可以提前想好不同周期的文案结构。

比如推文：不同位置需要的文案也是不一样的，如单独一篇推文推活动，或在日常推文下增加一小部分活动介绍，文案都不一样。

所以推广的位置和节奏越多越丰富，运营需要输出的文案就越多。

ps：推广也是各强沟通强输出工作，第一次活动对推广位不熟悉时，尽量安排更多时间跟进。

到了这里，活动的前期准备基本说完了。

写在最后

以上仅仅是活动前期要做的东西，接下来还有活动上线后要做什么，一期活动结束后要做什么等等内容，敬请关注。

另外需要提醒的是，以上所有描述均基于个人经验，不同公司不同活动目的和产研支持，都会有不一样的经验和问题，所以以上仅供参考，同时也欢迎朋友们来讨论～～～

来源：安徒生

我将会在接下来的几篇文章里，以一个连续迭代了7个月做了7期的UGC活动为背景，给大伙介绍一下活动运营都需要做些什么。本文适合1~3年的运营人，从更全局的角度去看一个活动运营。

活动运营流程图：

理论上，上述时活动的基本流程。单单看这个，或许对活动运营的时候真正要做什么，遇到什么，还是没有对应概念。且看下文的分解。

活动运营：活动的前期准备

一个重运营的活动，如果规模较大，且前期无相关活动模板，则前期需要大量时间搭建模块，准备素材、跨部门沟通。

如下图所示：

此图将活动运营的前期准备分为：

1. 活动产品线（活动线上承接页面及后台制作）
2. 运营线（特指活动上线后运营）
3. 推广线（活动的曝光和传播准备）

接下来会对这三个方面运营分别要做什么进行详细介绍，同时实际工作中需要注意到，这几条线是几乎同时进行的，且其中大部分工作都需要在活动上线前完成。

另外次图仅仅展示在活动目标确认且获得老板首肯之后要做的事情，即真实的定位应该是：确认了活动目的及将要落地的活动，其前期准备详解。

（省略的步骤是：做活动提案，写明活动背景、玩法、预算、效果、各部门支撑和风险等，做成ppt找上级审核找老板审批拿钱。老板首肯后，这个活动规则就可以细化准备执行了）

1.1 活动产品线

背景：一个线上活动，最基本的功能需求肯定是用户承接页，然后根据活动的需求和复杂程度，还需要增加相应的运营后台、用户信息提取及展示等功能。

思想预防针：产研支撑不一定能制作并满足最流畅的用户体验流程，其他部门的支撑合作程度不一定能满足活动运营需求，可能要以增加运营成本为代价。保持着把活动做到最优的期待，然后清楚这种最优可能要逐步实现而不是一次办成，才能在做活动的时候遇到层层阻碍而不会心灰意冷。

1.1.1 确认产品需求

通过明确活动目标、细化的活动规则及用户参与流程，就可以得出基本的产品需求，在加上其他部门的支撑反馈，则第一期的产品需求就能基本敲定了（但不等于真正实现）。

【其他部门的支持】其他部门的支持程度也会在一定程度上影响产品需求，所以在做提相关需求前（或同时），必须自己把流程试走一次，然后将这个流程中将会涉及的其他部门（通常是财务部）的支撑工作给缕出来，尽早找对应部门商量看看需要怎么实现。然后以最简参与流程为标准，输出产品需求。

例子：

在做一个UGC活动的时候，由于要给用户发奖，我们希望给用户发的步骤和体验可以尽量简单，而此处涉及财务。

财务提供两种办法让我们发放奖金：

1. 现金发奖（走活动经费借支流程）；
2. 拨款至用户账户。

第一种方法会涉及大量的运营清点及发奖等人手动作，第二种方法则对用户还是运营而言都更简单些，但需要财务开放流程，且财务系统于活动系统相关数据需要打通，而且需要产品研发支持。

我们经历了从方法1到方法2的过程，这个推动持续了4~5个月，像是一点点地撬动财务想办法给处更简便的用户参与及获奖体验。同时对应的产品功能也是一点点地迭代调整。

产品的参与：

有了产品的参与，运营要做的事情可能相对简单一定，把自己需要的梳理出来，交给产品去画原型，期间沟通好，确认产品把运营的需求完美展现并优化出来就好。同时，较好的产品经理会帮助运营将活动原型的用户体验实现到可执行范围内的最优，同时也会帮助运营与各个支撑部门沟通以助于实现相关功能。

需要注意的是，产品会有一个内部需求会，通常在资源有限的情况下，内部需求会过后，活动的一些产品功能可能会被砍掉，所以这里的前提是与产品沟通清楚，活动原型产品功能的轻重缓急。

思想预防针：需求是会被砍的，也可能以打了折扣的形式展现的，持续推动不断优化就好。能说清楚需求的轻重缓急和收益，是让需求更快实现的前提。

1.1.2 输出产品原型中需要填充的文案

上面说到产品的参与会给运营省去很多麻烦和工作，他们会画产品原型，展现活动的架构及交互需求，但其他的页面文案，就需要由运营提供。

大致的流程是：落实产品需求——运营提供文案（标题、规则、按钮文案、交互文案等等）——设计（页面设计）及技术（运营后台制作）制作。

文案有哪些：文案真的有很多。

• 页面文案（主副标题、活动流程、活动规则、奖励标准、按钮文案等等）
• 触达消息文案（大致是指，用户报名后收到的短信、用户获奖收到的短信等等基于用户某个动作后产生的站外提示性内容）
• 交互文案等等（大概如：用户任何做任何预想中的交互动作后给出的弹窗提醒或下一步动作引导，比如提交成功了，可能会说“恭喜您提交成功”、“将于XX个工作日内反馈”、“添加XX微信了解进度”等等。）
• 产品文案（譬如：在后台页面上，需要记录的信息表头，或者信息状态判别项等等此类产品文案）
• 其他……

另外，有一些文案是要交给设计放到图片里面的，有一些文案是给研发部门做适配的。做适配的文案例如：一个滚动文案说，“XX用户赢取了XX元”这种类型。文案到底是直接显示在页面里，还是做适配，就看运营需求了。

例子：下图的所有文字都是需要运营提供的文案，而产品提供的，只是其中结构排版。

1.1.3 活动产品设计及研发的跟进及沟通

活动产品线方面，通常有产品经理跟进的话会省心很多，但不是说运营就放着不用管。因为运营是活动的需求方，因而对于活动的设计、开发需求，会比产品清晰很多。

设计跟进方面：如果希望活动省心省力进行，提交活动设计需求时，除了产品那边提供产品原型，运营方面最好能找到期待的风格素材作为设计参考。

与设计沟通的理想流程应当是：

• 运营与设计确认设计公司设计风格规范；
• 运营到相关网站寻找若干个符合活动风格，且符合公司设计规范的设计样板供给设计参考；
• 设计做好大致风格样式后及时与运营沟通；
• 确认风格及元素ok后完成设计。

而现在很多无经验者走的流程是：

• 运营提需求后，设计根据产品原型及活动主题，给活动设计活动页；
• 设计完成基本页面设计，与运营沟通；
• 若运营认为设计的风格与想象中有较大差异，则需要再次沟通调整风格；
• 设计修改，持续沟通；
• 由于时间关系设计无法做大规模调整，初步定稿。

虽然也有很幸运地设计就设计出运营想要的页面的情况，但这种情况太考究设计和运营间的默契。所以为了减少来回沟通，给设计需求时最好是同时给出风格参考。
（做这个UGC活动时，运营就曾跟设计就头图的展现开了一个下午的会议来商讨，而那个下午，运营才了解设计对公司的活动图的设计风格及元素要求具体且严格到什么程度。)

开发方面：运营与开发方面通常要沟通的问题基本是确认某一个功能的实现，而这里的复杂程度就和产品的后台数据相关。
我经常遇到的情况是，开发问：你这里是要实现XXX功能吗？是的话，把其设计的所有数据定义情况给我。

例子：

曾经为了达到某个运营目的，提出了读取该订单的完成信息，以便运营判断该订单是否有资格参与活动的概念性需求。而这个需求到达开发处，应当翻译为：读取后台订单状态中，其中A、B、C定义为订单已完成，D、E、F定义为订单未完成，G、H 定义为未知。读取后在活动后台展示”已完成/未完成/未知“。

可能很多功能提需求的时候运营和产品都未意识到其中数据的复杂性，当研发真正落实的时候，就会发现这个问题，并需要运营进一步落实。

1.1.4 活动上线前测试

上线前，运营应该在测试环境下，按用户参与流程及运营逻辑将活动体验一次。尽管有测试帮忙测bug，但运营可以测出活动流程逻辑是否有bug（与预期不符）。

以上就是产品线相关的工作问题。

在运营过程中会发现，提需求花费的时间不多，但在沟通上花费的时间可能会更多一些。和产品的沟通交流时间是必不可少的，产品越是了解活动需求，越能做出符合运营期望的产品原型。

至于与设计和开发之间的沟通上，运营可以在每次沟通过程中了解设计和开发的思维逻辑，提需求的时候可尽量顺着他们的逻辑去走，这样会减少沟通时间。

1.2 运营线

前期准备越充分，活动上线后的麻烦会越少（自然不能避免有麻烦，毕竟一般人不能穷尽所有麻烦情况。）

可能需要考虑到的：

• 用户对活动的咨询
• 活动后发放奖品的采购

例子：

用户对活动的咨询：以这个UGC活动为例子，由于写长篇UGC内容有一定难度，需要运营介入引导与鼓励，所以肯定涉及不少的沟通。且在活动流程上，我们确认了需要添加用户微信来保证有效沟通，所以跟用户有必不可少的对话。

通常用户产生的问题和困难80%都是相似的，对于这类型的问题，我们可以预测其中的FAQ，整理好相应的话术文案，以便活动上线后能更加从容应对。若是遇到操作类或较为理解上较为复杂的，可以通过图文解释，增加可读性。
曾经，我们给到用户的规则描述，是一大段微信文字，用户长段文字的解读显然不在行，很多问题会问了再问，而将这种复杂文案做成图文之后，情况就优化了很多。

例子：

关于活动后发放的奖品采购：如果奖品是用户支线活动（促进主线活动玩的），那就必须和奖品管理的相关部门了解清楚剩余奖品数量、申请流程等细节。

曾经我们有一个奖品是一个毛绒公仔，当时库存剩余20个，同时可能会有4个主要部门的人申请，毛绒公仔从制作到到货的时间需要2周，如果要申请采购，需要走流程层层上报，整个申请流程走起来，最少需要两天。

所以如果没有前期了解好这些信息，贸然答应给用户一些奖品，最后真正需要兑现的时候容易捉襟见肘。

1.3 推广线

活动上线了就要推广才有用户知晓和参与，不同活动目的需要的推广资源不同，不同推广资源的流量不同，需要提供的素材也不同。

一般app有闪频（一打开app看到的）、有banner（一些轮播横幅广告）。闪频只要一开app就能看到，浏览和点击量都很高。banner还根据页面和位置的不同有不同的点击量，那我们做活动的时候，是要banner还是要闪频，还是都要？

• 看目的（我是否要那么大的曝光/我是否有能力和预算承接那么多用户？）
• 看功能（我的活动需要特定时间向特定城市特定类型用户曝光，这些资源位/渠道是否能做到？）
• 看排位（这些资源位都有排位吗？）

1.3.1 梳理可用推广位

一般推广位可以分内部外部，一个站内的活动，可能内部推广位已经足够了，如果涉及外部推广位，通常与拉新目的相关。

• 内部可能有：各种自营媒体（微信、微博、抖音、支付宝生活号……）、产品资源位（banner、闪频、feed流、push等等）、EDM、短信；
• 外部推广位：外部资源合作（其他线上线下广告位）。

例子：

这个持续在做的UGC活动，在不断迭代的过程成挖出了不少资源位。

• 已在运营的资源位：闪频、banner、分级页面banner。其中尤其是banner和分级页面banner，在后期已经和对应负责部门预定好了每月的固定位置。
• 新增的资源位：触发类型（用户下单后推送活动，用户完成订单后推送活动）、固定位置类型（菜单栏中的特定类目、用户订单页面新增按钮）。

ps：对于新增资源位的挖掘逻辑，就是根据用户的使用流程和使用逻辑，在合适的地方埋下曝光活动的点。当然这么做的前提是有产研支持。

1.3.2 根据活动的推广节奏，与相关部门安排好资源位需求

有些资源位并不能长期被占领，因此必须根据活动的节奏，安排资源位的上线时间，如：banner、闪频、弹窗等。

有些资源位可能可以长期发布，但内容需要经常更换，如：微博、抖音等社交媒体，另外邮件、短信、push、微信推文也可视为次类型，但频率需要控制在该部门建议范围内。

1.3.3 确定资源位需求，向设计、技术等部门发起需求

不同资源位需要的物料不同（图片、文案等），图片需要设计协助制作。有些资源位可能需要前端切图，如：邮件中的有交互效果的“图片”。

1.3.4 输出相关资源位需要的相应文案

比如微博：在不同的活动周期（前期、中期、后期），需要用的文案时不一样的，可以提前想好不同周期的文案结构。

比如推文：不同位置需要的文案也是不一样的，如单独一篇推文推活动，或在日常推文下增加一小部分活动介绍，文案都不一样。

所以推广的位置和节奏越多越丰富，运营需要输出的文案就越多。

ps：推广也是各强沟通强输出工作，第一次活动对推广位不熟悉时，尽量安排更多时间跟进。

到了这里，活动的前期准备基本说完了。

写在最后

以上仅仅是活动前期要做的东西，接下来还有活动上线后要做什么，一期活动结束后要做什么等等内容，敬请关注。

另外需要提醒的是，以上所有描述均基于个人经验，不同公司不同活动目的和产研支持，都会有不一样的经验和问题，所以以上仅供参考，同时也欢迎朋友们来讨论～～～

目前ofo的扫码用车的入口有三个，自有的ofo小黄车APP，微信服务号：ofo小黄车，支付宝生活号：ofo共享单车。在每一个可以用车的入口，都有一个明显的位置展示ofo的月卡。

APP用启动页活动展示的形式，在用户刚一进入APP的时候就能看见月卡活动；微信服务号在进入服务号-点我用车之后，会在扫码用车页面以弹出toast的形式展示，支付宝生活号里面，进入ofo共享单车之后，内容虽然有些杂乱，但是在明显的位置给了一个banner展示月卡活动，并且在顶部的tab中也有领取月卡的入口（用红框标注）。

ofo在它所有入口的明显位置都展示了月卡活动，可见对于月卡的重视程度，那么推出的月卡活动到底能为ofo解决什么问题呢，从产品上讲我列了三条：

一、用户运营的一把利器

目前的月卡活动，是一元包月，而ofo的使用价格计算，规定的是0.5元/小时，不足一小时的按一小时计费。从价格上说，只要每个月能骑两次及以上，月卡对于用户来说就是划算的。优惠力度如此大的活动，最受惠的群体就是一直有使用共享单车习惯的用户，无论是使用ofo还是其他的共享单车，这样的优惠力度都会让这些用户去使用ofo，从而完成用户的沉淀和用户促活。

由于使用共享单车这类群体有一个比例，近一半的用户，既会使用ofo又会使用Mobike。

所以将用户从一个平台迁移到另一个平台的事情，不是ofo重点考虑的问题，最重要的还是应当把未使用共享单车的新用户作为主要的拉新目标。拉新或者是流失用户挽回，这个活动同样也非常适用，依靠现在的社交平台的转发，会有很多用户加入。

对于拉新用户、促进用户活跃、流失用户召回来说，都是一种很有效的方式。当用户通过这样的活动沉淀下来之后，接下来的用户付费转换也会变得轻松不少。

二、改变用户的使用习惯

之前由于ofo的产品存在着这个致命的bug，可以提前结束用车，或者通过对车辆报修，不花钱使用车辆。

这样的产品bug，ofo团队一直都没有修改过，我们这里不谈他们对此不做修改的原因，我们谈谈月卡的活动对于这一行为的改变程度。之前的用户习惯，由于智能锁出现之前之前是传统的机械锁，用户养成的使用付费习惯是结束用车之后，马上手动的在APP同步结束，甚至是在还没有到达目的地，就提前结束用车，还有一些用户，会钻ofo的这个漏洞，随意的编个理由就可以在线上结束用车。

上述两个不规范的用户行为，都是由于金钱引发的，无非就是想少花点钱罢了。但是月卡活动推出来之后，每个月的花费支出是固定的，用户不会再关心价格的问题，之前养成的行为慢慢的得到了转变。之前每次用车结束之后都会在线上马上进行同步，到现在往往是下一次打开应该的时候，才发现上一次的用车订单确认还没有完成。用户不再去关心何时付款这个问题，慢慢的在改变之前的用户使用习惯。

紧跟着这样的用户行为被改变之后，最直观的改善就是ofo车辆管理系统的改善，之前由于不规范的使用行为，用户随意的点击车辆故障，会让ofo地面的运维团队花费更多的时间去处理本身并没有故障的单车，当用户的行为规范之后，地面运维团队就可以更精确的提供车辆维修调度的服务。

三、通过优质的原始数据，进行数据挖掘

这一步我想才是ofo最终的目的，众所周知数据的价值会越来越大，目前共享单车的MAU大约在3264万，ofo的MAU在1758万。

这样一个庞大的人群贡献出来的出行数据，通过这些出行数据所衍生出来的消费习惯，消费能力，用户行为，用户画像等等都可以通过大数据进行描绘。但是之前由于不规范的使用行为，所产生的有效数据可信度，无从考证，所以那时候的数据的利用价值就会很低。当ofo通过月卡活动改变了用户行为习惯之后，得到的骑行数据的可靠性就会比之前的数据要高得多。通过这些数据得到的结论，可信度也会高出很多。

四、总结

一个好的活动会多方位收益，就像ofo这个月卡活动，在用户运营、用户行为规划、数据挖掘三个模块都可以有所贡献。可以说月卡活动效果显著，在2017年6月TOP10共享单车应用MAU及增速这个图中显示（上图），ofo已经超越了Mobike登顶榜首。ofo接下来的动作，我想会是招聘数据科学家这类数据型人才，扩大它的数据分析部门。以及，未来如何将已经有了良好使用习惯的用户，在ofo平台上持续的使用。