我将会在接下来的几篇文章里，以一个连续迭代了7个月做了7期的UGC活动为背景，给大伙介绍一下活动运营都需要做些什么。本文适合1~3年的运营人，从更全局的角度去看一个活动运营。 理论上，上述时活动的基本流程。单单看这个，或许对活动运营的时候真正要做什么，遇到什么，还是没有对应概念。且看下文的分解。 一个重运营的活动，如果规模较大，且前期无相关活动模板，则前期需要大量时间搭建模块，准备素材、跨部门沟通。 接下来会对这三个方面运营分别要做什么进行详细介绍，同时实际工作中需要注意到，这几条线是几乎同时进行的，且其中大部分工作都需要在活动上线前完成。 另外次图仅仅展示在活动目标确认且获得老板首肯之后要做的事情，即真实的定位应该是：确认了活动目的及将要落地的活动，其前期准备详解。 （省略的步骤是：做活动提案，写明活动背景、玩法、预算、效果、各部门支撑和风险等，做成ppt找上级审核找老板审批拿钱。老板首肯后，这个活动规则就可以细化准备执行了） 背景：一个线上活动，最基本的功能需求肯定是用户承接页，然后根据活动的需求和复杂程度，还需要增加相应的运营后台、用户信息提取及展示等功能。 思想预防针：产研支撑不一定能制作并满足最流畅的用户体验流程，其他部门的支撑合作程度不一定能满足活动运营需求，可能要以增加运营成本为代价。保持着把活动做到最优的期待，然后清楚这种最优可能要逐步实现而不是一次办成，才能在做活动的时候遇到层层阻碍而不会心灰意冷。 通过明确活动目标、细化的活动规则及用户参与流程，就可以得出基本的产品需求，在加上其他部门的支撑反馈，则第一期的产品需求就能基本敲定了（但不等于真正实现）。 【其他部门的支持】其他部门的支持程度也会在一定程度上影响产品需求，所以在做提相关需求前（或同时），必须自己把流程试走一次，然后将这个流程中将会涉及的其他部门（通常是财务部）的支撑工作给缕出来，尽早找对应部门商量看看需要怎么实现。然后以最简参与流程为标准，输出产品需求。 在做一个UGC活动的时候，由于要给用户发，我们希望给用户发的步骤和体验可以尽量简单，而此处涉及财务。 第一种方涉及大量的运营清点及发等人手动作，第二种方对用户还是运营而言都更简单些，但需要财务流程，且财务系统于活动系统相关数据需要打通，而且需要产品研发支持。 我们经历了从方法1到方法2的过程，这个推动持续了4~5个月，像是一点点地撬动财务想办法给处更简便的用户参与及获体验。同时对应的产品功能也是一点点地迭代调整。 有了产品的参与，运营要做的事情可能相对简单一定，把自己需要的梳理出来，交给产品去画原型，期间沟通好，确认产品把运营的需求完美展现并优化出来就好。同时，较好的产品经理会帮助运营将活动原型的用户体验实现到可执行范围内的最优，同时也会帮助运营与各个支撑部门沟通以助于实现相关功能。 需要注意的是，产品会有一个内部需求会，通常在资源有限的情况下，内部需求会过后，活动的一些产品功能可能会被砍掉，所以这里的前提是与产品沟通清楚，活动原型产品功能的轻重缓急。 思想预防针：需求是会被砍的，也可能以打了折扣的形式展现的，持续推动不断优化就好。能说清楚需求的轻重缓急和收益，是让需求更快实现的前提。 说到产品的参与会给运营省去很多麻烦和工作，他们会画产品原型，展现活动的架构及交互需求，但其他的页面文案，就需要由运营提供。 大致的流程是：落实产品需求——运营提供文案（标题、规则、按钮文案、交互文案等等）——设计（页面设计）及技术（运营后台制作）制作。 触达消息文案（大致是指，用户报名后收到的短信、用户获收到的短信等等基于用户某个动作后产生的站外提示性内容） 交互文案等等（大概如：用户任何做任何预想中的交互动作后给出的弹窗提醒或下一步动作引导，比如提交成功了，可能会说“恭喜您提交成功”、“将于个工作日内反馈”、“添加微信了解进度”等等。） 另外，有一些文案是要交给设计放到图片里面的，有一些文案是给研发部门做适配的。做适配的文案例如：一个滚动文案说，“用户赢取了元”这种类型。文案到底是直接显示在页面里，还是做适配，就看运营需求了。 活动产品线方面，通常有产品经理跟进的话会省心很多，但不是说运营就放着不用管。因为运营是活动的需求方，因而对于活动的设计、开发需求，会比产品清晰很多。 设计跟进方面：如果希望活动省心省力进行，提交活动设计需求时，除了产品那边提供产品原型，运营方面最好能找到期待的风格素材作为设计参考。 虽然也有很幸运地设计就设计出运营想要的页面的情况，但这种情况太考究设计和运营间的默契。所以为了减少来回沟通，给设计需求时最好是同时给出风格参考。 （做这个UGC活动时，运营就曾跟设计就头图的展现开了一个下午的会议来商讨，而那个下午，运营才了解设计对公司的活动图的设计风格及元素要求具体且严格到什么程度。) 开发方面：运营与开发方面通常要沟通的问题基本是确认某一个功能的实现，而这里的复杂程度就和产品的后台数据相关。 我经常遇到的情况是，开发问：你这里是要实现X功能吗？是的话，把其设计的所有数据定义情况给我。 曾经为了达到某个运营目的，提出了读取该订单的完成信息，以便运营判断该订单是否有资格参与活动的概念性需求。而这个需求到达开发处，应当翻译为：读取后台订单状态中，其中A、B、C定义为订单已完成，D、E、F定义为订单未完成，G、H 定义为未知。读取后在活动后台展示”已完成/未完成/未知“。 可能很多功能提需求的时候运营和产品都未意识到其中数据的复杂性，当研发真正落实的时候，就会发现这个问题，并需要运营进一步落实。 上线前，运营应该在测试下，按用户参与流程及运营逻辑将活动体验一次。尽管有测试帮忙测bug，但运营可以测出活动流程逻辑是否有bug（与预期不符）。 在运营过程中会发现，提需求花费的时间不多，但在沟通上花费的时间可能会更多一些。和产品的沟通交流时间是必不可少的，产品越是了解活动需求，越能做出符合运营期望的产品原型。 至于与设计和开发之间的沟通上，运营可以在每次沟通过程中了解设计和开发的思维逻辑，提需求的时候可尽量顺着他们的逻辑去走，这样会减少沟通时间。 前期准备越充分，活动上线后的麻烦会越少（自然不能避免有麻烦，毕竟一般人不能穷尽所有麻烦情况。） 用户对活动的咨询：以这个UGC活动为例子，由于写长篇UGC内容有一定难度，需要运营介入引导与鼓励，所以肯定涉及不少的沟通。且在活动流程上，我们确认了需要添加用户微信来有效沟通，所以跟用户有必不可少的对话。 通常用户产生的问题和困难80%都是相似的，对于这类型的问题，我们可以预测其中的FAQ，整理好相应的话术文案，以便活动上线后能更加从容应对。若是遇到操作类或较为理解上较为复杂的，可以通过图文解释，增加可读性。 曾经，我们给到用户的规则描述，是一大段微信文字，用户长段文字的解读显然不在行，很多问题会问了再问，而将这种复杂文案做成图文之后，情况就优化了很多。 关于活动后发放的品采购：如果品是用户支线活动（促进主线活动玩的），那就必须和品管理的相关部门了解清楚剩余品数量、申请流程等细节。 曾经我们有一个品是一个毛绒公仔，当时库存剩余20个，同时可能会有4个主要部门的人申请，毛绒公仔从制作到到货的时间需要2周，如果要申请采购，需要走流程层层，整个申请流程走起来，最少需要两天。 所以如果没有前期了解好这些信息，贸然答应给用户一些品，最后真正需要兑现的时候容易捉襟见肘。 活动上线了就要推广才有用户知晓和参与，不同活动目的需要的推广资源不同，不同推广资源的流量不同，需要提供的素材也不同。 一般app有闪频（一打开app看到的）、有banner（一些轮播广告）。闪频只要一开app就能看到，浏览和点击量都很高。banner还根据页面和的不同有不同的点击量，那我们做活动的时候，是要banner还是要闪频，还是都要？ 一般推广位可以分内部外部，一个站内的活动，可能内部推广位已经足够了，如果涉及外部推广位，通常与拉新目的相关。 ps：对于新增资源位的挖掘逻辑，就是根据用户的使用流程和使用逻辑，在合适的地方埋下活动的点。当然这么做的前提是有产研支持。 有些资源位并不能长期被占领，因此必须根据活动的节奏，安排资源位的上线时间，如：banner、闪频、弹窗等。 有些资源位可能可以长期发布，但内容需要经常更换，如：微博、抖音等社交，另外邮件、短信、push、微信推文也可视为次类型，但频率需要控制在该部门范围内。 不同资源位需要的物料不同（图片、文案等），图片需要设计协助制作。有些资源位可能需要前端切图，如：邮件中的有交互效果的“图片”。 比如微博：在不同的活动周期（前期、中期、后期），需要用的文案时不一样的，可以提前想好不同周期的文案结构。 比如推文：不同需要的文案也是不一样的，如单独一篇推文推活动，或在日常推文下增加一小部分活动介绍，文案都不一样。 以上仅仅是活动前期要做的东西，接下来还有活动上线后要做什么，一期活动结束后要做什么等等内容，敬请关注。 另外需要提醒的是，以上所有描述均基于个人云南迷人湖经验，不同公司不同活动目的和产研支持，都会有不一样的经验和问题，所以以上仅供参考，同时也欢迎朋友们来讨论～～～ 人人都是产品经理（是以产品经理、运营为核心的学习、交流、分享平台，集、培训、社群为一体，全方位服务产品人和运营人，成立8年举办在线+期，线+场，产品经理大会、运营大会20+场，覆盖北上广深杭成都等15个城市，在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监，他们在这里与你一起成长。 |