《HD01活动定制引擎V1.0》是优秀的网上活动定制和推广系统。利用它，不需要进行任何研发，就可以在3～10分分钟内设计、定制多种常见的网上活动。
- 网上活动:
由共同目的联合起来，部分或全部基于网络而完成的一定社会职能的动作的总和。网上活动由目的、动机和动作构成，具有完整的结构系统。
- 网上活动的营销优势:
网上活动本质上是一种营销推广手段，以有一些独特的营销优势：
用户喜欢参加：网上活动有精彩互动过程，有奖品，用户喜欢主动参加；
深度宣传推广：网上活动有精彩过程，产品和服务本身的卖点能在活动过程相结合， (如答题活动的题目可以以产品的特征为题干)。用户在参与过程中主 动的或不知不觉就深度掌握了产品和服务。
推广和销售结合：网上活动加上网上支付的功能，就可以实现推广与销售相结合，一箭双雕。
- 常见的网上活动:
l答题类：知识竞赛、问卷调查、投票、竞猜； l推广类：团购、招聘、有奖注册、免费领取，试用、促销、秒杀、优惠卷； l 征集类：摄影作品征集、DV作品征 集、标志、LOGO、吉祥物等平面作品征集、广告语，广告词，宣传语，口号，短信征集、网络征文、动画，彩信征集、歌词歌曲征集； l 游戏类：每一种休 闲游戏加上成绩排行都可以看成是一种活动； 生活中无处不活动，以上只是部分列出。
以下是用活动创建平台创建、主办外包、主办方自行研发三种活动创建方法在成本、时间和营销效果上的对比：
对比点 | 用活动创建平台创建 | 主办方外包 | 主办方自行研发 | |
活动类型 | 20～60种，按需选择 | 每次只能1种 | 每次只能一种 | |
创建成本 | 设计成本 | 只需考虑活动如何举办，告诉引擎即可，会打字就行。 | 需要和外包人员沟通，设计越复杂，成本越高 | 需请专人设计每个 活动细节页面 |
研发成本 | 无需写一行代码 | 需要和外包人员沟通，功能越复杂，成本越高 | 需请研发人员研发 每个功能 | |
界面美化成本 | 只需提供一些产品或 服务的图片 | 需要提供一些产品或 服务的图片给外包方 | 需聘请美术人员进 行每个网页的美化 | |
定制成本 | 定制功能极强，0成本使用 | 定制要求越高，成本也就越高 | 一般无力支持定制功能，而且成本高 | |
上线时间 |
| 1小时即可上线 | 15～60天或更多 | 15～60天或更多 |
营销效果 | 中奖面 | 支持小额发奖，中奖面大 | 小 | 小 |
病毒式传播 | 支持奖励邀请好友参加活动 | 有的支持，有的不支持 | 有的支持，有的不支持 | |
自适应搜索引擎 | 能自适应搜索引擎 | 有的支持，有的不支持 | 有的支持，有的不支持 | |
以下是具体活动功能上的对比：
对比点 | HD01活动定制引擎 | 自主研发 | 外包 | |
活动界面表现 | 风格 | 无需写代码，主办方可在活动的任何时间调整活动风格。 | 每次活动，需要独立研发，不能复用；研发完就固定死了，不能调整。 | 每活动活动，需要独立研发，不能复用；研发完就固定死了，不能调整。 |
布局 | 无需写代码，主办方可把首页任意切换成支持 1：2：1，1：3，3：1的布局。 | 布局是死的，不能调 | 布局是死的，不能动 | |
模块 | 无需写代码，主办方可自定义自己的大图，列表、文本、声音、动画、视频模块，并可放在页面的任何地方 | 不支持 | 不支持 | |
头尾、背景 | 主办方可随时对任一活动的头、尾及背景进行自定义 | 可以做到，但需要写代码 | 可以做到，但需要写代码 | |
导航 | 主办方可随时扩展活动的主栏目，以满足形式发展的需要 | 可以做到，但需要写代码 | 可以做到，但需要写代码 | |
活动信息展现 | 活动基本信息 | 主办方可随时扩展活动基本信息，会打字就行 | 需要专业人员才能做到 | 需要专业人员才能做到 |
组织者 | 主办方可随时扩展组织者信息，会打字就行 | 需要专业人员才能做到 | 需要专业人员才能做到 | |
联系方式 | 主办方可随时扩展联系方式，会打字就行 | 需要专业人员才能做到 | 需要专业人员才能做到 | |
注册 | 系统注册项 | 主办方可从数十项注册项里随时选择自己需要的注册项，以针对性的收集参与者的信息。 | 一但确定，不能更改 | 一但确定，不能更改 |
自定义注册项 | 如果系统提供的注册项不能满足需求，主办方可自定义 | 无法做到 | 无法做到 | |
活动 逻辑 |
| HD01提供了60种不同的活动逻辑供主办方使用，并可扩展。主办方无需编码 | 只能有一种 | 只能提供一种 |
新闻 中心 | 新闻分类 | 无需编码，主办方能随时增删改活动的新闻分类 | 需要大量编码 | 需要大量编码 |
新闻内容管理 | 主办方能随时增删改新闻内容， | 需要大量编码 | 需要大量编码 | |
奖项 奖品 | 奖项设置 | 主办方能随时增删改奖项设置 | 需要大量编码 | 需要大量编码 |
奖品设置 | 主办方能随时增删改奖项设置 | 需要大量编码 | 需要大量编码 | |
评奖方式 | 专家评奖 | 主办方能任意组合这三方评奖方式进行奖项评定。 | 只能编码实现里面的一至两种，且编码后不能移植到别的活动类型 | 只能编码实现里面的一至两种，且编码后不能移植到别的活动类型 |
按活动成 绩评定 | ||||
抽奖 | ||||
网上 支付 |
| 可任意选择多种网上支付方式 | 一般不支持 | 一般不支持 |
第三方数据交换 |
| 支持与第三方网站进行用户信息交换 | 不支持 | 不支持 |
BBS |
| 每个活动均有自己的BBS | 没有 | 没有 |
动转静 |
| 重要动态页面均转成静态页面访问 | 不支持 | 不支持 |
个人评价:
通过半年的开发,项目已经运营.但回想起来,整个项目中遇到了许多的问题,还好需求策划上一直很好(原因在于老板原来就是一个产品总监且目前的策划都很有逻辑性),所以对于开发人员而言没有吃苦.问题在于微软的实体框架EF让人简直痛恨至极(个人愚见),
其一:效率(如果有人做过测试我想都和我有同感,这增删改查无处不见其效率之低下,我想如果说你要执行原生态的sql表达式 或者较为其次的LINQ,根本就没有用它的必要性,更何况linq是一个值得争议的技术,有人测过他的效率就知道了.
单凭实体框架的效率问题,在一个并发性能可能上万的项目中,简直BS至极)
其二:数据冗余(如果你查询一个或两个字段,你的查询结果真够要命....不用多说)
其三: 项目版本更新问题(如果你的项目版本更新,你需要重新生成数据库(这里说的是ModeFirst),你需要做哪些事情?自己想想)
当然也有其有点:但是我们完全可以用powerdesigner代替它.
教训:简单实现的东西或许用了其他东西作为交换(性能).最新的不一定是最好的.