Group items tagged

内容指标指的是衡量访问者的活动的指标，商业指标是指衡量访问者活动转化为商业利润的指标

网站分析的商业指标 平均订货额　Average Order Amount (AOA) 计算公式：平均订货额＝总销售额／总订货数 指标意义：用来衡量网站销售状况的好坏 指标用法：将网站的访问者转化为买家当然是很重要的，同样重要的是激励买家在每次访问是购买更多的产品。跟踪这个指标可以找到更好的改进方法。 转化率　Conversion Rate (CR) 计算公式：转化率＝总订货数／总访问量 指标意义：这是一个比较重要的指标，衡量网站的对每个访问者的销售情况 指标用法：通过这个指标你可以看到即使一些微小的变化都可能给网站的收入带来巨大的变化。如果你还能够区分出新、旧访问者所产生的订单，那么就可以细化这个指标，对新旧客户进行分别的统计。 每访问者销售额　Sales Per Visit (SPV) 计算公式：每访问者销售额＝总销售额／总访问数 指标意义：这个指标也是用来衡量网站的市场效率 指标用法：这个指标和转化率差不多，只是表现形式不同。 单笔订单成本　Cost per Order (CPO) 计算公式：单笔订单成本＝总的市场营销开支／总订货数 指标意义：衡量平均的订货成本 指标用法：每笔订单的营销成本对于网站的盈利和现金流都是非常关键的。营销成本的计算各人有不同的标准，有些把全年的网站营运费用摊入到每月的成本中，有些则不这么做，关键要看那种最适合自己的情况。如果能够在不增加市场营销成本的情况下提高转化率，这个指标就应该会下降。 再订货率　Repeat Order Rate (ROR) 计算公式：再订货率＝现有客户订单数／总订单数 指标意义：用来衡量网站对客户的吸引力 指标用法：这个指标的高低和客户服务有很大关系，只有满意的用户产品体验和服务才能提高这个指标。 单个访问者成本　Cost Per Visit (CPV) 计算公式：单个访问者成本＝市场营销费用／总访问数 指标意义：用来衡量网站的流量成本 指标用法：这个指标衡量的是你的市场效率，目标是要降低这个指标而提高SPV，为此要将无效的市场营销费用削减，增加有效的市场投入。 订单获取差额　Order Acquisition Gap (OAG) 计算公式：订单获取差额＝单个访问者成本(CPV)－单笔订单成本(CPO) 指标意义：这是一个衡量市场效率的指标，代表着网站所带来的访问者和转化的访问者之间的差异 指标用法：指标的值应是一个负值，这是一个测量从非访问者中获得客户的成本。有两种方法来降低这个差额，当你增强了网站的销售能力，CPO就会下降，这个差额就会缩小，说明网站转化现有流量的能力得到了加强；同样的，CPV可能升高而CPO保持不变或降低，这个差额也会缩小，表明网站所吸引的流量都具有较高的转化率，这种情形通常发生在启用了PPC(pay per click)的计划。 订单获取率　Order Acquisition Ratio (OAR) 计算公式：订单获取率＝单笔订单成本(CPO)／单个访问者成本(CPV) 指标意义：用另一种形式来体现市场效率 指标用法：用比率的形式往往比较容易为管理阶层所理解，尤其是财务人员。 每笔产出　Contribution per Order (CON) 计算公式：每笔产出＝（平均订货数Ｘ平均边际收益）－每笔订单成本 指标意义：每笔订单给你带来的现金增加净值 指标用法：公司的财务总监总是对这个指标感兴趣的，代表了你花了多少钱来赚多少钱。 投资回报率　Return on Investment (ROI) 计算公式： 投资回报率＝每笔产出(CON) /每笔订单成本 (CPO) 指标意义： 用来衡量你的广告的投资回报 指标用法：比较你的广告的回报率，应该把钱分配给有最高回报率的广告，但是这个回报率应当要有时间段的限制，比如“２５％ RIO/每周”和“２５％　RIO／每年”是有很大差别的。

网站分析的内容指标 转换率　Take Rates (Conversions Rates) 计算公式：转换率＝进行了相应的动作的访问量／总访问量 指标意义：衡量网站内容对访问者的吸引程度以及网站的宣传效果 指标用法：当你在不同的地方测试新闻订阅、下载链接或注册会员，你可以使用不同的链接的名称、订阅的方式、广告的放置、付费搜索链接、付费广告(PPC)等等，看看那种方式是能够保持转换率在上升？如何增强来访者和网站内容的相关性？如果这个值上升，说明相关性增强了，反之，则是减弱。 回访者比率　Repeat Visitor Share 计算公式：回访者比率＝回访者数／独立访问者数 指标意义：衡量网站内容对访问者的吸引程度和网站的实用性，你的网站是否有令人感兴趣的内容使访问者再次回到你的网站。 指标用法：基于访问时长的设定和产生报告的时间段，这个指标可能会有很大的不同。绝大多数的网站都希望访问者回访，因此都希望这个值在不断提高，如果这个值在下降，说明网站的内容或产品的质量没有加强。需要注意的是，一旦你选定了一个时长和时间段，就要使用相同的参数来产生你的报告，否则就失去比较的意义。 积极访问者比率　Heavy User Share 计算公式：积极用户比率＝访问超过１１页的用户／总的访问数 指标意义：衡量有多少访问者是对网站的内容高度的兴趣 指标用法：如果你的网站针对正确的目标受众并且网站使用方便，你可以看到这个指标应该是不断的上升。如果你的网站是内容型的，你可以针对不同类别的内容来区分不同的积极访问者，当然你也可以定义２０页以上的才算是积极的访问者。 忠实访问者比率　Committed Visitor Share 计算公式：访问时间在１９分钟以上的用户数／总用户数 指标意义：和上一个指标的意义相同，只是使用停留的时间取代浏览页数，取决于网站的目标，你可以使用两个中的一个或结合使用。 指标用法：访问者时长这个指标有很大的争议，这个指标应结合其它的指标一起使用，例如转换率，但总体来说，较长的访问时长意味着用户喜欢呆在你的网站，高的忠实访问率当然是较好的。同样的，访问时长也可以根据不同的需要自行设定。 忠实访问者指数　Committed Visitor Index 计算公式：忠实访问者指数＝大于１９分钟的访问页数／大于１９分钟的访问者数 指标意义：指的是每个长时间访问者的平均访问页数，这是一个重要的指标，它结合了页数和时间。 指标用法：如果这个指数较低，那意味着有较长的访问时间但是较低的访问页面（也许访问者正好离开吃饭去了）。通常都希望看到这个指数有较高的值，如果你修改了网站，增加了网站的功能和资料，吸引更多的忠实访问者留在网站并浏览内容，这个指数就会上升。 忠实访问者量　Committed Visitor Volume 计算公式：忠实访问者量＝大于１９分钟的访问页数／总的访问页数 指标意义：长时间的访问者所访问的页面占所有访问页面数的量 指标用法：对于一个靠广告驱动的网站，这个指标尤其值得注意，因为它代表了总体的页面访问质量。如果你有１００００的访问页数却仅有１％的忠实访问者率，这意味着你可能吸引了错误的访问者，这些访问者没有啥价值，他们仅仅看一眼你的网页就离开了。这是你应该考虑是否广告的词语产生了误解。 访问者参与指数　Visitor Engagement Index 计算公式：访问者参与指数＝总访问数／独立访问者数 指标意义：这个指标是每个访问者的平均会话(session)，代表着部分访问者的多次访问的趋势。 指标用法：与回访者比率不同，这个指标代表着回访者的强烈度，如果有一个非常正确的目标受众不断的回访网站，这个指数将大大高于１；如果没有回访者，指数将趋近于１，意味着每一个访问者都有一个新的会话。这个指数的高低取决于网站的目标，大部分的内容型和商业性的网站都希望每个访问者在每周／每月有多个会话(session)；客户服务尤其是投诉之类的页面或网站则希望这个指数尽可能地接近于１。 回弹率（所有页面）Reject Rate／Bounce Rate 计算公式：回弹率（所有页面）＝单页面访问数／总访问数 指标意义：代表着访问者看到的仅有的一页的比率 指标意义：这个指标对于最高的进入页面有很重要的意义，因为流量就是从这些页面产生的，当你对网站的导航或布局设计进行调整时尤其要注意到这个参数。总而你是希望这个比率不断地下降。 回弹率（首页）Reject Rate／Bounce Rate 计算公式：回弹率（首页）＝仅仅访问首页的访问数／所有从首页开始的访问数 指标意义：这个指标代表所有从首页开始的访问者中仅仅看了首页的访问者比率 指标意义：这个指标是所有内容型指标中最重要的一个，通常我们认为首页是最高的进入页面（当然，如果你的网站有其他更高的进入页面，那么也应该把它加入到追踪的目标中）。对任意一个网站，我们可以想象，如果访问者对首页或最常见的进入页面都是一掠而过，说明网站在某一方面有问题。 如果针对的目标市场是正确的，说明是访问者不能找到他想要的东西，或者是网页的设计上有问题（包括页面布局、网速、链接的文字等等）；如果网站设计是可行易用的，网站的内容可以很容易地找到，那么问题可能出在访问者的质量上，即市场问题。 浏览用户比率　Scanning Visitor Share 计算公式：浏览用户比率＝少于１分钟的访问者数／总访问数 指标意义：这个指标一定程度上衡量网页的吸引程度。 指标用法：大部分的网站都希望访问者停留超过一分钟，如果这个指标的值太高，那么就应该考虑一下网页的内容是否过于简单，网站的导航菜单是否需要改进。 浏览用户指数　Scanning Visitor Index 计算公式：浏览用户指数＝少于１分钟的访问页面数／少于１分钟的访问者数 指标意义：一分钟内的访问者平均访问页数 指标用法：这个指数也接近于１，说明访问者对网站越没兴趣，他们仅仅是瞄一眼就离开了。这也许是导航的问题，如果你对导航系统进行了显著的改进，应该可以看到这个指数在上升；如果指数还是下降，应该是网站的目标市场及使用功能有问题，应该着手解决。 将浏览用户比率和浏览用户指数结合起来使用，可以看出用户是在浏览有用的信息还是厌烦而离开。 浏览用户量　Scanning Visitor Volume 计算公式：浏览用户量＝少于１分钟的浏览页数／所有浏览页数 指标意义：在一分钟内完成的访问页面数的比率 指标用法：根据网站的目标的不同，这个指标的高低有不同的要求，大部分的网站希望这个指标降低。如果是搞广告驱动的网站，这个指标太高对于长期的目标是不利的，因为这意味着尽管你通过广告吸引了许多的访问者，产生很高的访问页数，但是访问者的质量却是不高的，所能带来的收益也就会受到影响

“差异化策略”对推广工作进行“精耕细作”，对群发对象分类，区别对待不同用户，推送不同的信息，以实现不同层次的推广目的。这样，既符合信息传达的精准定位原则，也适用产品生命周期不同阶段的宣传策略，不断发掘新功能和产品卖点，维持产品活力。同时，把活动营销型的推广纳入周期性产品推广中去。 差异化落脚点： • 接收对象的差异化； • 推广目的的差异化； • 推送信息和形式的差异化； • 推广效果的差异化

这里讨论的是一种直投形式的产品推广策略，直投推广分很多种：DM纸质广告、传单、email、无线领域的手机短信、彩信等，不管哪种，只要接收推广的对象具有一定的目标和确定性，而且推广的内容和接收对象之间的联系性比较强，就可以认为是直投推广。

音乐的精细化营销在理论上依据主要有两点：     1.音乐和音乐之间是有关联的，就是超市里的货品一样，超市里的货品摆放，看似随意，其实是经过精心设计的。音乐也一样，喜欢A歌曲的人，往往也喜欢B歌曲，就说明A和B之间的关联度比较高。     2.用户应该按不同的维度进行细分，如：订制渠道、订制时间、内容喜好等等用户分得越细，推荐歌曲就越准确，推荐越准确，推荐短信就越不容易引起用户投放。

精细化营销的三大主要方式

2、商业智能

1、网站统计来路分析：大名鼎鼎的Google AnalyticsTrack where your visitors came from, and which links they clicked. Google Analytics—get it here!

2、网站点击热图：哪儿的点击最受欢迎？Easy-to-interpret “heatmaps” showing exactly where people clicked (even if it wasn’t a link). Crazy Egg—get it here!

3、访客浏览录制：更清晰的真实反应访客在你博客的动作。“In-page” web analytics, showing videos of visitors’ screens(!) The perfect complement to Google Analytics. ClickTale—get it here!

豆瓣音乐人能给音乐人带来什么？

音乐人可以在这里发布自己的最新动态，以唤醒歌迷的关注。 可以上传自己的歌曲试听，以吸引更多的乐迷。 可以和乐迷形成很好的互动，我相信豆瓣上的乐迷都是那些态度认真的，他们有很高的音乐欣赏素质。

1—logo：基本logo特征，符合logo设计基础（平面设计通用）显示器效果：清晰度，最小尺寸（因显示器分辨率而带来的，等同线下平面设计的印刷效果）2—文字：内容等级决定字体、字号大小、粗细；状态决定颜色（默认或者根据网站特殊统一）3—广告、内容图片：尺寸样式的定位，同一页面的和谐性，图片的优化，位置的节奏，大小对比。4—icon：品牌性，表达准确合理，设计手法（依据品牌性），一致性，作用：吸引，醒目，方便识别、理解、操作、记忆。5—可点击（button)：区别（不可点击），根据人的生活经验：厚度，可按，质感（实体联想），色彩（品牌性、统一性、对比性）；统一的样式大小（依据里面文字的内边距统一）6—背景图片：氛围效果营造，同产品的统一性，优化（品质大小，色彩信息，实现方案），7—图文排版：主图次文，图文节奏，空隙，模块化。8—当前状态：放大（形状），变色（反色、对比色、明度纯度区别色），链进链出后指定内容提示。9—交互控件：样式合理准确性（人对系统默认的认知和生活常规认知），状态（视觉表现样式和动作过程优化），创意。10—loading：内容关联性（loading前后的内容关联），无聊等待的乐趣，体积、面积优化，创意。11—用户反馈_ 成功、出错、提示、无结果：文案（明确、合理、人性化、创意），图形（明确、醒目、色彩的心理认知准确度）。12—动画效果：过程合理（模拟真实环境的合理化），连续，节奏感，用户日常动作表现，音效配合，创意。13—首尾设计：首（品牌宣传、自身特点、明确内容、气氛表达、创意。尾：呼应、节奏（与首），创意。14—适应屏设计（全屏设计）：最大最小屏幕的考虑（文字、图片的位置、折行效果）15—固定尺寸的栅格设计：合理的单元格（考虑黄金分割），单元格面积节奏，边距统一性16—demo设计样稿：对内容最多最少的考虑。17—页面：品牌性，基调元素一致性，复用性，节奏感、面积感，视觉第一吸引，引导浏览，点线面关系，素描原理（运用素描的基本规律来做页面）。18—阅读：背景对阅读（视力）的舒适度，内容与背景的对比舒适度

1. 你们的项目组使用源代码管理工具了么？MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么？MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。 3. 你们的测试组还在用Word写测试用例么？MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。 4. 你们的项目组有没有建立一个门户网站？MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 5. 你们的项目组用了你能买到最好的工具么？MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 6. 你们的程序员工作在安静的环境里么？MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 7. 你们的员工每个人都有一部电话么？MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 8. 你们每个人都知道出了问题应该找谁么？MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。 9. 你遇到过有人说“我以为…”么？MVM：要消灭“我以为”。Never assume anything。 10. 你们的项目组中所有的人都坐在一起么？MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 11. 你们的进度表是否反映最新开发进展情况？ MVM：应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。 12. 你们的工作量是先由每个人自己估算的么？MVM：应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 13. 你们的开发人员从项目一开始就加班么？MVM：不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？MVM：不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 15. 值得再多花一些时间，从95%做到100%好MVM：值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。 16. 登记新缺陷时，是否写清了重现步骤？MVM：要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 17. 写新代码前会把已知缺陷解决么？MVM：要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 18. 你们对缺陷的轻重缓急有事先的约定么？MVM：必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。 19. 你们对意见不一的缺陷有三国会议么？MVM：必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

20. 所有的缺陷都是由登记的人最后关闭的么？MVM：Bug应该由Opener关闭。Dev不能私自关闭Bug。 21. 你们的程序员厌恶修改老的代码么？MVM：厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。 22. 你们项目组有Team Morale Activity么？MVM：每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 23. 你们项目组有自己的Logo么？MVM：要有自己的Logo。至少应该有自己的Codename。 24. 你们的员工有印有公司Logo的T-Shirt么？MVM：要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。 25. 总经理至少每月参加次项目组会议MVM：要的。要让team member觉得高层关注这个项目。 26. 你们是给每个Dev开一个分支么？MVM：反对。Branch的管理以及Merge的工作量太大，而且容易出错。 27. 有人长期不Check-In代码么？MVM：不可以。对大部分项目来说，最多两三天就应该Check-In。 28. 在Check-In代码时都填写注释了么？MVM：要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。 29. 有没有设定每天Check-In的最后期限？MVM：要的，要明确Check-In Deadline。否则会Build Break。 30. 你们能把所有源码一下子编译成安装文件吗？ MVM：要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。 31. 你们的项目组做每日编译么？MVM：当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 32. 你们公司有没有积累一个项目风险列表？MVM：要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。 33. 设计越简单越好MVM：越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 34. 尽量利用现有的产品、技术、代码MVM： 千万别什么东西都自己Coding。BizTalk和Sharepoint 就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文 本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 35. 你们会隔一段时间就停下来夯实代码么？MVM：要。最好一个月左右一次。传言去年年初Windows 组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 36. 你们的项目组每个人都写Daily Report么？MVM：要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。 37. 你们的项目经理会发出Weekly Report么？MVM：要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。 38. 你们项目组是否至少每周全体开会一次？MVM：要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 39. 你们项目组的会议、讨论都有记录么？MVM：会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

40. 其他部门知道你们项目组在干什么么？MVM：要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。 41. 通过Email进行所有正式沟通MVM：Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 42. 为项目组建立多个Mailing GroupMVM： 如果在AD+Exchange里面，就建 Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 43. 每个人都知道哪里可以找到全部的文档么？MVM：应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 44. 你做决定、做变化时，告诉大家原因了么？MVM： 要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于 是不是能access information/data，而在于是不是掌握资源。 45. Stay agile and expect changeMVM：要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。 46. 你们有没有专职的软件测试人员？MVM：要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 47. 你们的测试有一份总的计划来规定做什么和怎么做么？MVM：这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。 48. 你是先写Test Case然后再测试的么？MVM：应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 49. 你是否会为各种输入组合创建测试用例？MVM：不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。