编辑编者按：不管是每年大的节庆或是小的节庆，他们每当看见大小不一的公益活动，这些都离不开产品副经理和运营相关人员的精心设计酝酿与预备，那怎样来推出优质的产品公益活动本文就为大家展开而言说。

2021年第三季度一直在科学研究市售的网络营销产品，有自己公司的网络营销平台，有从天下人都是产品副经理扒出来的各种文章和案例，也有从服务器端平台注册登记帐号展开体验、科学研究、操作，以为能相匹配自己脑袋里面的两个小模型，如果能米芾一下那就岂不今在今在。

就如正好困了，有人正好给你送去垫子，嗯，我想多了…

每次一到元月、新年、圣诞节、中秋节、六一、情人节、元宵节、十四、双十四、圣诞节，不管是国内的却是国外的，不是冥府的却是冥府的，在运营人的眼睛里（不，应该是脑海中里）那都是可以用来被人民来消费的。

比如说他们刚刚过去的秋海棠恩宠（圣诞节、元月），以及正在展开的吃喝玩乐节（新年），这都离不开运营人的两匹功绩，赶工挖空心思来贪财的（呸，弄错了，来为职工群众提供最优质的服务全力支持）。

做为公司内部的一位雇员，他们很乐于看到运营相关人员为公司的产品提升很高的付费转化率，来为他们发基本工资。

做为公司内的一位产品副经理，那着实从内心深处深处里愿意配合运营相关人员通过他们所描述的需求，以此构筑出优质的产品公益活动全力支持运营计划轻松破冰执行。

 

一、需求

他们很清楚需求的明确提出，怎样明确提出、明确提出的类型、明确提出的时间、明确提出的细节，决定了需求怎样破冰。

对产品和技术而言，东齐县最不想接受的是很很很紧急的需求。比如说：前台有位节庆，今天设计了两个公益活动计划，并明确提出了计划的产品公益活动需求，然后要求明天上架（对于此种网络营销公益活动的产品需求，我想大家都遇到过，我之前遇到的此种残花需求着实数不乌祖埃，所谓天下蝎子一般黑，当然也有部分牛逼的运营团队，真的可以规划出来两个季度或者半年的网络营销公益活动计划，提前布局做预备）。

这时候内心深处的os是：离tmd大谱，因为以两个普通需求的一生，从需求明确提出-产品计划设计-技术开发实现-上架生产环境使用，那都是需要时间和校正的，否则就会有枭女的坑在不知名的地方等着你勒皮伊，我相信很多产品副经理都摔倒过不少次了，我着实摔得满身是包…

随着组织工作的不断积累，和运营相关人员关系密切的组织工作越来越多，在怎样处理网络营销公益活动着实一点儿持续高阶。

 

二、基础类-直接构筑公益活动

刚开始做网络营销相关的产品副经理，在拿到两个需求的时候，会直接按照需求方所描述的需求，依据自己所学的产品知识，流程图、公益活动逻辑直接画产品原型图

以便快速的全力支持运营公益活动，对于网络营销产品的构筑和公益活动架构不会想的太多，以至于他们有时候入职一家新的企业，去了解公司的网络营销前台会看到前台有n个公益活动，如果今年运营新提两个类似的公益活动，也需要产品、技术吭哧吭哧累死累活的再搭两个新的公益活动，而且还不能确定线上环境的公益活动产品不回出现bug。

随着不断的出现紧急需求，技术团队持续的重复开发组织工作，前台一直写重复规则条件，两个公益活动一遍两个公益活动一遍，手都快写麻了。

此种最简单直接的产品计划确实比较容易，却对公司内人力物力财力产生了极大了浪费，人效成本太高了。

 

三、高阶类-模块化建公益活动

为了能提高人效，在构筑网络营销前台的产品副经理考虑网络营销公益活动的时候，多了一种隐藏的责任，那是怎样让现在的公益活动，在未来也可以发挥它的价值，避免重复造车。

玩网络营销的产品副经理都知道，构筑两个网络营销公益活动会有一些基础信息、公益活动规则条件、奖励条件、分享是两个公益活动的必备类型。

基于此当下的产品副经理会拔高自己的维度，使产品抽象化，把抽象的条件归类为模块，分模块化构筑产品公益活动。

从上图可以很明确的知晓，他们把公益活动抽象拆分为不同的模块，对于可以使用的模块在构筑新公益活动时直接引用到新的公益活动内，避免了技术同事的重复开发；对于不可直接引用的模块，去持续增加模块，奖励配置1、奖励配置2，对不同的奖励配置不同的规则，把所有的是模块合并到一起是两个新的公益活动，即满足了运营同学所明确提出的网络营销公益活动产品计划，又提高了人效，一举两得。

在和很多朋友聊天沟通网络营销中台相关组织工作、网络营销公益活动新公益活动产品的开发时，目前市售的企业都是在使用模块化构筑产品公益活动，虽然提高了部分人效，但是其实没有实际的解决两个公益活动的所有问题，治标不治本。

两个公益活动的创建不仅体现在前台，还有前端破冰页，虽然在前台他们可以按照模块化的方式去配置公益活动规则等信息，但是如果在前端破冰页下两个公益活动想添加个排行榜、滚动条等，就却是需要重新开发-发版-上架。

我在使用的时候感觉却是太太过于麻烦了，所以我一直在想，我怎么才能让运营、产品、技术、测试，4端联动的成本和人效再提升两个档次呢，便有了下方的两个想法…

 

四、高级类-组件化建公益活动

提到组件化不得不提服务器端全力支持平台，比如说易企秀、凡科互动等，组件化此种模式在服务器端平台的破冰页被使用的炉火纯青，在两个空白页面可以自己随意添加自己想要的组件：视频、图片、文字、按钮…

你可以从左侧添加你想要的任何组件提现在画布上，还可以随意的移动位置，构筑完成的画布样式所见即所得。

避免了公司持续不断破冰页公益活动每次都要重复浪费前端、后端写两个破冰页的资源浪费。

当然，也有不好的地方，那是使用它的产品就要为他背书，因为末尾会有两个大大的logo，除非你付费了会员。就好比我司运营对我说的一句话

虽然我很想怼一句，那你去申请预算呀！

对于破冰页，组件化是很简单的，只是通过页面拼接做了一张图而已，不会有产品逻辑、多页面等情况。

联想到公益活动组件化后就一直在思考，这么多页面，这么多逻辑，这么多规则，怎样构筑呢，是不是对整个公益活动内的规则细节要更抽象化，两个规则是两个组件。

首先归类，哪些信息是一类，哪些信息是一类，大类规划完后，在大类里面去丰富组件，通过不通过的组件组合成两个又两个不同的公益活动，未来产品、技术只往里面丰富不同的组件就可以了。

公益活动的大类共分为了4大类：基本配置、页面模版配置、规则配置、奖励配置。

基本配置：

点击新建首先进入到基础配置，基础配置是针对两个公益活动必须要用到的固定字段，可根据自己的需要展开相应的调整，如：名称、时间、说明、优先级。

页面模版配置：

点击页面模版配置，左侧组件栏定位到页面模版组件，用户可自己在画布上面添加这个公益活动破冰页所需要的组件，并调整组件相关的内容，如：背景、顶图、图片、按钮、文字等等。

同时对于两个公益活动内，有公益活动页、中奖页、未中奖页面的样式都可展开自定义。

规则配置：

规则组件是我认为最重要的两个组件模块，它的重要程度体现在，你所创建的这个公益活动，是让哪些人可以参与的，能覆盖到哪些用户；这个公益活动的逻辑规则里面会用到哪些组件，直接从左侧拖拽，添加的组件不需要也可以直接删除展开调整，很灵活。

包括下方的奖励配置也是一样的如此：

奖励组件决定了参与这个公益活动的用户，达到了什么奖励条件，才能获得相应奖励，可以不断的添加奖项，包括不同的奖项所构筑的不同奖励条件也可以很灵活。

公益活动组件化，在后期展开维护的时候，只要去丰富这个插件内的规则组件、奖励组件，运营在节假日时想到了我要做两个什么什么类型的公益活动，打开这个网络营销公益活动中台，按照自己设计的公益活动逻辑，先丰富页面、再拖拽公益活动规则和奖励规则就快速的设计完成了两个网络营销公益活动。

省去了正常产品先提需求-产品规划需求-出产品计划-技术实现-测试测试上架，等一系列骚操作。

以此提高人效，快速构筑你想要的网络营销公益活动哟。

当然，随着公益活动的持续丰富，各类组件也需要不断的丰富能支撑未来更多的网络营销公益活动产品。来真真正正的提高人效，解放技术相关人员去做更多有挑战的事情。