Page view- A request for a file whose type is defined as a page in log analysis. An occurrence of the script being run in page tagging. In log analysis, a single page view may generate multiple hits as all the resources required to view the page (images, .js and .css files) are also requested from the web server.

Visit / Session – A visit is defined as a series of page requests from the same uniquely identified client with a time of no more than 30 minutes between each page request. A session is defined as a series of page requests from the same uniquely identified client with a time of no more than 30 minutes and no requests for pages from other domains intervening between page requests. In other words, a session ends when someone goes to another site, or 30 minutes elapse between pageviews, whichever comes first. A visit ends only after a 30 minute time delay. If someone leaves a site, then returns within 30 minutes, this will count as one visit but two sessions. In practise, most systems ignore sessions and many analysts use both terms for visits. Because time between pageviews is critical to the definition of visits and sessions, a single one pageview event does not constitute a visit or a session (it is a “bounce”).

First Visit / First Session – A visit from a visitor who has not made any previous visits.
Visitor / Unique Visitor / Unique User – The uniquely identified client generating requests on the web server (log analysis) or viewing pages (page tagging) within a defined time period (i.e. day, week or month). A Unique Visitor counts once within the timescale. A visitor can make multiple visits. Identification is made to the visitor’s computer, not the person, usually via cookie and/or IP+User Agent. Thus the same person visiting from two different computers will count as two Unique Visitors. Increasingly visitors are uniquely identified by Flash LSO’s (Long Storage Objects), which are less susceptible to privacy enforcement.

Repeat Visitor – A visitor that has made at least one previous visit. The period between the last and current visit is called visitor recency and is measured in days.

New Visitor – A visitor that has not made any previous visits. This definition creates a certain amount of confusion (see common confusions below), and is sometimes substituted with analysis of first visits.

Impression – An impression is each time an advertisement loads on a user’s screen. Anytime you see a banner, that is an impression.

Singletons – The number of visits where only a single page is viewed. While not a useful metric in and of itself the number of singletons is indicative of various forms of Click fraud as well as being used to calculate bounce rate and in some cases to identify automatons bots).
Bounce Rate – The percentage of visits where the visitor enters and exits at the same page without visiting any other pages on the site in between.

% Exit – The percentage of users who exit from a page.

Visibility time – The time a single page (or a blog, Ad Banner…) is viewed.

Session Duration – Average amount of time that visitors spend on the site each time they visit. This metric can be complicated by the fact that analytics programs can not measure the length of the final page view.

Page View Duration / Time on Page - Average amount of time that visitors spend on each page of the site. As with Session Duration, this metric is complicated by the fact that analytics programs can not measure the length of the final page view unless they record a page close event, such as onUnload().

Active Time / Engagement Time - Average amount of time that visitors spend actually interacting with content on a web page, based on mouse moves, clicks, hovers and scrolls. Unlike Session Duration and Page View Duration / Time on Page, this metric can accurately measure the length of engagement in the final page view.

Page Depth / Page Views per Session - Page Depth is the average number of page views a visitor consumes before ending their session. It is calculated by dividing total number of page views by total number of sessions and is also called Page Views per Session or PV/Session.

Frequency / Session per Unique - Frequency measures how often visitors come to a website. It is calculated by dividing the total number of sessions (or visits) by the total number of unique visitors. Sometimes it is used to measure the loyalty of your audience.

Click path – the sequence of hyperlinks one or more website visitors follows on a given site.

Click – “refers to a single instance of a user following a hyperlink from one page in a site to another”[A growing community of web site editors use click analytics to analyze their web sites.

source: http://en.wikipedia.org/wiki/Web_analytics

Agile Model
- promotes development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle.
- minimal planning and documentation
- small timeframe tasks (1-4 weeks)
- each iteration involves full SDLC, from requirements analysis to acceptance testing
- emphasizes on individual interactions and effective communication with cross-functional team members working of a project
- encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.
- encourages customer collaboration
- low product failure rate

When to use
- when requirements change often
- product has low criticality to customers (ie, not causing any inconvenience to customers)
- small number of senior developers

When not to use
- when comprehensive documentation is required for each phase of SDLC
- culture that embraces traditional development procedures
- when seeking official approvals for each deliverables are required in each phase of the lifecycle

Waterfall Model
- focuses on structured, step-by-step process in SDLC from requirements analysis to maintenance with comprehensive documentation
- less development iterations
- as requirements change with the project team, it is difficult to add in change requests when the development is in action due to limited interactions with team members
- high chance for product becomes obsolete by the time it goes to production.
- the risk of project failure is high

When to use
- when projects have well-defined and understood requirements
- when the development team has experienced similar project before hand
- product is critical to customers (ie, causing inconvenience to customers)
- large number of junior developers

When not to use
- when project requirements are not well understood by the team
- large complex projects that take months to develop; requirements maybe obselete by product launch time

Type of Launches

Keys to Successful Launch

- Product Plan Checklists
– Summary
– Purpose of this product
– Market Overview
– Key Market Trend
– Target Customers and their needs
– The product
– Window of opportunity/ Ship date
– Positioning
– Tag line
– Feature and benefit
– Price
– Place and Channel
– Marketing Strategy
– Marketing Tactics / Promotion
– Launch Budget
– Marketing Mix
– Expected ROI
– Action Plan/ Deliverable Ownership
– Rough Timeline / Schedule
– Key Decisions remaining

Internal Communication
– Weekly meeting to track deliverables, clarify blocking issues, assign responsibilities and action items
– Reporting top level details to executives

External Communication
– Provide courtesy warning to customers in timely manner

Product Readiness Checklists
- Documentation
- Help System
- Packing
- Support Policies
- Additional Support Programs
- Support Training
- Sales tools & training
- Operation readiness
- Channel training
- Press tour materials
- Collateral
- Beta program completed
- QA completed
- Signoff by executives
- Customer references
- Warranty & return policies
- Website updated
- BOM completed
- Contracts / Legal work
- Market plan signed off
- Marketing program
- International readiness
- Certifications readiness
- Promotions in place
- Positioning, tagline, USP
- Pricing signed off
- Sustaining marketing plan
- Forecast signed off

Factors For A Good Beta Program
1. Set goals
– be clear about what is important and what is your real goals
– the goals should be as concrete as possible to get team and execs to buy-in
– set your goals as early as possible in product development process
– if possibe include the goals in MRD

Typical goals may include answers to these questions:

• Do you want to validate product if it is ready to ship?
• Do you want to supplement QA to cover configuration that aren’t being tested?
• Do you just want participants to find bugs or also looking ofr early customer references?
• Are you gathering feedback to get ahead of the curve for the next version?
• Do you trying to find support issues and compile a FAQ for smoother product launch?
• Do you intend to support PR for early reviews during the beta?

2. Prepare a plan and get sign off
– a good plan should be as concise, as specific as posible
– key points for a beta program plan should include

• goals
• recruiting
• criteria for starting
• costs
• timeline
• responsibilities
• criterai for success
• sign off

3. Decide who will manage the program
– this person should be reliable and able to respond to the customer appropriately
– this person must be committed and dedicated for the duration of the program
– choice of candidates depend on your stated goals (ie., choose someone with good people and communication skill if one of the goals in your beta program involves PR reviews)

4. Determine the length of program
– Essential criteria on when to start beta program

• no crashing bugs
• bug count stabilized
• internal team successfully uses the product for specific period of time

– underestimating the length of program at the start or cutting the program length short while executing prompts to program failure.
– too long a program is also hard to keep going, unless it is an exciting product and have enticing incentive for participants
– ideally 4-6 weeks is sufficient but again, program length is dependent to type of product and the goals of your beta program

5. Recruite participants
– set expected participation levels and goals
– set number of participants, participation duration and program details
– participants can be from
a. current customers
b. prospects who didn’t purchase
c. VCs/Investors
d. personal networks
e. sales force and leads
f. advertisements
– Communication
a. make sure the participants understand why this is worth their time and beneficial
b. make it excited (ie, make it an incentive related contest with special name)

6. Select candidates
– make sure you know each participant’s environment and select those whose environment matches the program
– make sure you have a well-balanced user group with different performance levels

7. Define factors in response rates
– influence factors of response rate
a. popularity of the product
b. are you completely new and unproven?
c. any risk to interrrupt participants’ daily business?
d. are you established? or an unknown startup?
e. marketing pitch (ie, with personal touch/mass email blast)
f. any incentive?

8. Estimate participation levels
– always shoot for large number of sign ups
– percentage of active participants always much smaller than that signs up and committed

9. Obtain agreements
– a good beta agreement set expectation on both sides
– always includes a NDA (Non Disclosure Agreement)
– agreement should entail the program length, what you expect the participants to do, support you will provide them and incentive, if any
– make sure the participants sign and return the beta agreement by a given deadline
– you can evaluate if the pool of participants will help you to accomplish your goals, after collected the agreements

10. Determine incentives
– might want to consider adding incentive to the program if the response rate is unsatisfactory
– incentive can be varied. If this is a contest, consult the contest rules in the state which you do business

11. Kick Off the program
– have a double check items list prior to kicking off
a. installer and software download sites
b. usability of the interface and documentation are ready for customers
c. have an FAQ ready to support customers

12. Maintain on-going communication
– keep the communication in all forms open (ie. email, phone)
– check in to participants’ commitment
– keep participants posted with status updates
– your communication should include
a. start & end dates
b. how to submit bugs/feedback
c. ongoing status
d. new build/installation info
e. contest details/additional incentives, if applied

13. Respond to participants
– set expected response time for participants who have questions or encounter problems
– set expected acknowledgement time for participants who submit bug reports, feedbacks or feature requests
– capture information via Web form and into a database

14. Communicate internally
– as program progress, send either daily/weekly status reports to increase visibility and credibility of the program
– reports should include
a. number of bugs & their priorities
b. number of feedbacks & feature requests from customers
c. if the program is meeting the stated goals
d. if this is a contest, announced the outstanding contestant of the week who found most bugs or the most devastating bug to the product
e. if this is a contest, announced the outstanding contestant of the week who gave most feedback or most creative feature request

15. Administrate exit survey
– always end your beta program with an exit survey.
– if the program is tied to incentives, make sure participants submit their survey prior to getting their incentives
– you want to from the participants:
a. the overall impressions
b. how much have they used the product
c. is the product ready to ship
d. features important in rank
e. suggestions for improvement
– use online tools for exit survey (ie. Zoomerang or Survey Monkey)

16. Final report should include
– bug trend info to show that bug has stablized
– unresolved, open issues
– conclusion (whether you met the overall goals)
– summary of customer opinions/feedback from exit survery

Timeline
The schedule is highly dependent on the goals in the program. Roughly 8-12 weeks are required to run a very comprehensive beta program

Best Practices
1. Follow up with the program participants to leverage the relationships built for future beta programs
2. Circle back and circulate a brief summary to the team about the program, what worked, what didn’t
3. Express appreciation to all the collaborated team members involved in the program

High impact roadmaps not only able to drive the business strategy of the company and development effort, but also provide business partners, PR, customers and analysts a clear idea of the direction the product heads to.

Challenges, 1) roadmaps can be very detailed or high level, depending the intention of usages, whether as internal communication reference with the business and enginneers in the company, or as marketing communication tool outside the company. 2) regardless to many different types of roadmaps, they need to be alligned to ensure quality delivery on time.

High level roadmaps (for a variety of audiences)
1. Market & Strategy roadmaps – outline which markets to enter and the strategy to enter them
2. Visionary roadmaps – outline the industry trends maps to high level company vision in the future
3. External product roadmaps – outline the high level product plans

Detailed roadmaps
1. Internal product roadmaps – solidify product decisions, resource allocation, communicate with other constituents in the company about the product line direction

Steps for Building Roadmaps
1. Detail level and time to spend for preparation
- Importance: What is the shelf life? Level of firm commitment? Strategy driven?
- Available time and resource: How serious is the company to roadmaps?

2. Competitive, Market & Technology Trends Analysis
- As a reality check to make sure your product roadmaps make sense

3. Gather & prioritize requirements
- Having PRD and/or MRD with features included for release ready
- List of future requests, including additional requirements from all shareholders, anyone with good ideas
- Prioritize requests into a prioritization matrix, with assign weight and rank to each request

4. Timeframe
- Depend on the use of roadmaps, determine whether you should have short term (monthly, quarterly, annually) or long term (three years, five years) timeframe for your roadmap
- Rule of thumbs: 3-5 years timeframe for strategic planning roadmap, next 4-6 quarters for briefing customers and PR communication.

5. Organize Roadmaps based on either
- Themes: popular for products with major release with many features for easy management of bug fixes, release “cleanup” and “feature creep”
- Golden Feature: focus on one single the absolutely most important, high priority feature that provide enought customer value to the entire release. Especially effective to increase success rate on short release cyles, agile projects that requires meeting a tight schedule.
- Timed Release: uses pre-determined release date to drive the schedule. The upsides are 1) have known ship dates and 2) alleviate the pressure of everyone trying to get their features into one release. The downsides are 1) not working very well for long development cycles project, 2) resources may be diverted to other work for the interim and thus large feature may never complete.

6. Building internal roadmap
– Include as much details as possible so that anyone look at it will gain a quick understanding of what’s being worked on.

7. Fine tune & get buy-in
– compare roadmap against your competitive trends analysis before reviewing it with internal constituents, then get buy-in from the stakeholders (ie., management, support, operation)

8. Create External Roadmap
– omit feature details and specific dates of release. Be generic and vague with undefined time period
– make sure to put the appropriate disclaimers (ie, confidential, plans may change, etc)

If there is multiple product lines, gather information for each project and rank the projects against each other using prioritization matrix. Determine the cut off line based on available resources and priorities of the company and its business.

Use multiple roadmaps to create a compelling story and illustrates that your plan is well thought out.

Roadmap Best Practices
1. Get early involvement of the rest of your team to determine feasibility, resource load balancing and schedule viability
2. Always use code name for projects on roadmaps
3. Always release roadmaps in PDF file format or in PowerPoint presentations
4. Include international and minor releases in roadmaps. It should have enough details for anyone to get a snapshot of all the works planned

Online Video Ad Formats – http://online.wsj.com/article/SB123258749787704697.html