Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I would like to know what are the main tools in the market for analysing/implementing E-customer behaviour in a Web application.
I just know Google Analytics which tracks client-side activity but maybe there are many alternatives using client and server-side scripts.
I already posted this question on webmasters.stackexchange.com E-customer behaviour in a Web application, but it has been closed and cannot understand why!
There are a vast array of tools to analyse user behaviour on a website. Ecommerce or otherwise.
Google analytics has options like:
Ecommerce
Ecommerce custom variables
Goals & Funnels
Goal flows
etc. which are useful in understanding things like drop off points, conversion rates, typical customer path and other shopper metrics.
Other analytics packages useful for ecommerce / website behaviour:
Clicktale
Crazy egg
Getclicky
and more. Some of these have a live / spy feature that allows you to see what users are doing realtime.
And the best way is to actually watch a recording of your users behaviour complete with keystrokes and mouse clicks / movements.
User recording tools:
MouseStats
Ghostrec
Inspectlet
Mouseflow
Most of the above also do aggregated heatmaps and overlays to give you an insight into what users click most or what catches their eye etc.
Incremental improvement to your website:
A/B testing or multi-variate testing are all the rage now. With A/B testing be aware of local maximum and also avoid the common mistakes people make with testing. Google content expirements (formerly known as google website optimizer) now is part of Google Analytics and you can use this to do testing.
References / more reading for analysing and setting up ecommerce user behaviour:
Stalking Users
Driving online sales
Web Analytics Solution
First of all you need to choose a general propose Web Analytics Solution. Since you are an E-commerce you want to choose one that has good support for tracking E-commerce data.
Google Analytics is the obvious choice here not only because it's free but also because it's better documented and easier to implement.
depending on your size it may make sense to implement a more Enterprise level Ecommerce solution. You may want to take a look at Adobe Omniture and IBM CoreMetrics. They are much more expensive not only because of the licenses but on an implementation perspective. It may take months to implement one of these other tools and the cost of the implementation can be almost the same as the costs for the licenses. Still if you need more enterprise level analysis and integrations with other BI solutions it may be worth taking a look at these.
Note that Google Analytics also has a Premium Edition. This is a fairly new alternative and provide some extra features and early access to beta features.
Product Recommendation
Depending on your Ecommerce platform you might already have some kind of product recommendation or up-selling. You usually can improve these systems based on analytics data. There are just a few options on the market, and most companies doing this tend to develop their own recommendation engine.
If you're just getting started with it, it might be worth looking at LiftSuggest. I haven't tried it but they seem easy enough to implement and leverage Google Analytics data to improve cross-selling.
HeatMap
It's easy enough to implement and may provide some nice isights. I find them more distracting usually but every now and then you can make good use of them. The most common seen around are CrazyEgg and ClickTale.
Behavioral Targeting
This is a technique to customize your site based on a previous knowledge you have about the visitor in order to increase his conversion rate. Tools don't help you much here, since you have to customize your site and no tool can predict how to do that. One common approach is to create buckets depending on factors that you can infer. For example: Users with Internet Explorer might be less tech savvy and thus might be more interested in non-tech products. On the other side Linux users are probably on the technology field. So you can put users on buckets depending on which country they came from, which browser they're using or if they are logged in you can use the information they entered on their profile or based on previous purchases. One tool that helps you doing that is called BTBuckets.
A/B and Multivariate Testing
Google analytics has an A/B testing tool integrated with the tool. Another Good tool that provides both A/B and Multivariate testing are Unbounce, Optimizely and Webtrends Optimize.
Custom Solution
Everybody these days are developing custom solutions. If you still have money and time to spend on Web Analytics after you exausted the other options you can look into building your own. Collecting the data the way you want and analyzing the granular data. Here solutions range fro server side to client side collection, but for the analysis they are usually done with Hadoop or with a OLAP Business Intelligence Tool like Microstrategy.
What you're looking for is a called Customer Relationship Management software, or CRM. They vary greatly, so without an in-depth understanding of your exact needs it's impossible to recommend specific ones. Any good CRM will let you analyze your site visitors in various ways. For example, you can see if customers bought X, they often came back and bought Y one month later.
The difficult part is integration because these systems need information about orders and other user actions. If you're using an off-the-shelf e-commerce package, there are often CRM options readily available.
For a "lighter" system you can use Google Analytics or similar, since it lets you send tracking, conversion, and sales information from the browser. It's great for analyzing the overall success of the site and tracking user actions across pages, but less powerful for sales-specific reporting and analysis.
Related
I am doing project on Recommender systems for an ecommerce B2B
website, I have even gone through recommender systems course from
University of Minnesota from Coursera. I could not implement
Recommender Systems in traditional way of recommending things as the
website I am working on does not have a rating option or click
history. I am finding difficulty here to implement recommendations,
as the website does not have any required parameters. And I have worked in R language with sample dataset which contained rating as parameter to compute recommendations but I am facing difficulty to recommend things to website without the parameter rating . Kindly give a solution on how to make recommendations for my B2B website.
I'm am always amazed at how slowly the world seems to notice that ratings are a horrible way to make recommendations. You have a much better way with sales events. No major player in recommendations uses ratings for recs. This started with the Netflix prize, where they defined the judging criteria as ratings. The effect has been so long lasting that Netflix decided not to use ratings (in their own recommender) before the event was even finished. Thought Coursera might be more nimble than Academia at large.
In any case most modern recommenders will handle non-rating based recommendations. If you want one that can ingest many different indicators of user preference take a look at the Universal Recommender. It can use purchases, views, category preferences, even user profile information and is implemented end-to-end.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Okay, a lot of websites (about 50%) use google analytics. The idea is to know some basic information about your users. But I don't understand why the service is used by so many people, considering 3 things:
1) The code takes time to load. Even the async version takes time and the user sees the loading icon, a bad thing making it seem like your code is terrible or you can't pay a good hosting company.
2) It's a well know script and a some people block it.
3) Google (obviously) get's the data too. Now, don't get me wrong, but why give them free data sacrificing your uses privacy?
2 and 3 are not so important. 1 is. Given the above, what's the drawback of making your own analytics script and serving it to the users? What's the great thing google analytics does and you can't do on your own?
I would say two reasons:
A) It gives you a LOT of convenient visualizations and ways to slice the data - stuff that you would have to build independently. Again - if you just want to watch one number, it doesn't matter much, but you usually want a bigger picture and GA has put a lot of work into making most useful stuff easily available and easy to visualize.
B) Service reliability - basically, the first 10 iterations of whatever solution you choose to implement WILL have bugs (as any programmer who has worked on any meaningful projects knows).
Outsourcing your analytics to GA therefore just saves you a metric ton of time that it would take to reimplement everything yourself and get it working reliably.
As for speed issues - you can always disable GA on the few pages where speed is critical... although considering that page is usually the landing page of the app, that might not be too smart of an idea...
However - in the vast majority of cases, the async GA code is not really the bottleneck for your page. You are probably better off optimizing other aspects of your javascript on the landing page, as the "loading" icon is really something most users do not notice.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As a junior developer, I mean without great experience, what would you do for a client about an eshop? Start from scratch and handcode an e-shop(simple one)? If yes are there any good tutorials you suggest?
Or buy something ready, lets say VirtueMart templates for joomla or a similar solution for Wordpress?
Even if you described yourself as an expert I still wouldn't recommend that you write an ecommerce application from scratch unless
your client does something very specific that can't be made to fit an existing solution
your client has huge amounts of money and doesn't want you to deliver anything for months (or more)
you can offset either of the above because your business plan is to develop the next Magento and you have the resources to hire a development team and market your solution
Displaying products on the front end is relatively trivial. The rest of the iceberg e.g. security, user management, the back end (admin interface) of your website, tax calculations, shipping, cart functionality, templates, payment gateways etc. would take considerably longer.
Unfortunately, even if you deliver you would still be behind the competition when your client says: "I want feature x that I've seen on website y" and you have to quote for bespoke development instead of installing or enabling a module on a ready-made application. Unless they're prepared to spend a lot of time and money they will soon look for an alternative.
If you're already using Joomla, I'd recommend installing the Joomla + VirtueMart bundle here:
http://virtuemart.net/downloads
If you're using WordPress take a look at ShopperPress or Get Shopped.
There are many more out there (Magento, osCommerce, Zen etc.)!
The most important thing to do is to match your client's requirements with the features of the application you feel comfortable using.
I would definitely not hand code or encourage this.
It is not sustainable for the client unless him and you are going to work together for the next millennium. What happens is that in a year or two they want new functionality, and if you are available, you need to have done a very very good job of structuring and commenting your own code to remember it yourself (as a new developer you learn new things every day, and solutions I did a year ago, I would restructure today).
The even more likely scenario is that another developer, system designer or graphic designer comes along, and it will be pointless, enormously time consuming and costly for the client to have person number two dig through your code.
Your time is better spent learning solid cms-systems and improving those, rather than reinventing the wheel. There are too many sites out there that are made as one-offs, and therefore often unmanageable in the long run.
I understand that programmers wants to progam, and the temptation to start with a blank editor page, but it is not good for the client, and it is not good for you reputation down the road.
Use your skills to make unique and custom made plugins, functions etc for your client. Do not waste your time building frameworks that others have already - and most likely - done better.
..and make sure you pick a cms your customer can handle. Do not give him joomla or drupal, if he is of the sort that can barely figure out how to publish a post in wordpress.
You might take this opportunity to learn about recent Web technologies and tools, in particular non-PHP based things like Opa language or Ocsigen library or perhaps Kaya; these tools probably have some useful infrastructure for your needs.
You might also checkout ShopAlternaMart for WordPress
I'm happy with opencart, an open source e-Commerce (see my site here, if you like). There are of course many others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
You can't just have user stories somehow the functionality of the program has to be documented. Do you end up with a specifications document with scrum? If you do do you end up assigning time to do this onto the task?
An example would be a complex workflow.
Another example would be a new member who comes onto the team.
There will be plenty of good ideas added to this question. My personal experience has taught me that:
1~ The working product is a form of documentation itself: assuming the product is accepted, then asking what it should do under certain condition is equivalent to asking what does it actually do under those conditions - log in and try it to get your answer.
2~ The tests, be them manual or automated (or a mix), are a form of documentation. Certainly unit tests may be way too far from the domain language spoken by the less-technically inclined team members (eg: 'business Experts', or Customers). Acceptance tests may be closer to a 'middle ground' of sort. Definitely BDD-style tests seem to have the best chance to build a ubiquitous language everyone can understand (see in this regard Gojko's Bridging the Communication Gap). Nonetheless, all of these form of tests are a form of documentation which can be used to determine what the product should do.
3~ Depending on where your project falls on the spectrum, your documentation (and, in general, all your ancillary artifacts) may require a higher or lower degree of ceremony. Smaller products, smaller teams, where time to market is critical may find that a very formal documentation of requirement costs way too much compared to the value it adds. Extremely large projects, spanning multiple teams and years of development, on the other hand, will find the ROI of formal documentation quite different.
4~ In the perfect world, we probably wouldn't need to document requirements other than in the form of working code (which, in the ivory Tower would also be self-explanatory) and tests (mostly for regression testing, and -on the fringe- to drive development of new features). Thus, the question of requirements documentation is a question about what's different between the Perfect World/Ivory Tower and the Real World/Trenches. The answer, of course, is different on a case-by-case, depending on the project and the team. For instance, we could say "All requirements shall be kept into this wiki, and maintained with the utmost care, etc etc..." but if the team is not familiar and comfortable with wikis this would not work.
5~ In the end, the stakeholders are those you should ask. Certainly, the topic should be approached in a collaborative manner, because everyone on the team will have to interact with the requirements throughout the project, but you must find a form of documentation that satisfy the stakeholders' needs.
All that being said, here's some places I've seen requirements documented while applying Scrum (why do I feel like this word should always be followed by an asterisk?):
PDF document
Bulletin Boards
Wiki
Wiki + Automated Acceptance Tests (read: FitNesse)
Unit tests
Manual Test Plans
User Stories, Use Cases diagrams (read: Enterprise Architect models)
Whiteboards around the office
Emails
Post-it notes
And, to be honest, I cannot say that any one system has a consistently higher correlation with a successful project than the others. I guess, indeed, we don't have a silver bullet.
HTH, thanks for the thought-provoking question!
Adding "documentation" as a task on each user story could certainly go a long ways towards your goal.
Scrum says you should document what you need, when you need it; it doesnt say you shouldnt have documents.
So if a document is required either by the finished product (eg. help documentation) or to produce the finished product (eg. requirements documentation) then there should be a documentation task/user story in your product backlog.
Appropriate priority should then be placed for that task.
For documentation the key point is;
Document only what you need, only when you need it.
You can't just have user stories
somehow the functionality of the
program has to be documented. Do you
end up with a specifications document
with scrum? If you do do you end up
assigning time to do this onto the
task?
Why can't you just have user stories? What purpose do these specification documents serve? What value does the investment in producing these documents return? Does the benefit out weigh the cost? If not, then isn't the time spent creating, and more importantly maintaining, these documents waste?
I know I'm asking more questions than providing answers, but I think part of what Scrum and other Agile approaches like lean do is force you to re-examine your current practices and see if they still make sense.
In the case of specifications, who will be updating and maintaining these documents once the feature has launched? In most companies I've been at, the documentation has been sparse, out of date, or rarely referenced.
Instead, why not use executable tests or BDD so that the documentation becomes part of the code and is executable. For example, see Ben Mabey's talk on Cucumber
If for some reason, a specific type of document is required for legal compliance purposes, you can always add it to the teams' definition of "done", however, I've found in most cases, stories and tests are more than sufficient forms of documentation.
Maybe my understanding of the question is completely wrong, but I what I understood was that the OP was uncomfortable with the mismatch between user stories and requirements. With reason I'd say.
In my opinion, user stories tell how a chunk of functionality shall be demonstrated to the product owner. The language of the story can be something that can be understood by the product owner but mainly by the developers. You might have stories that describe things that are not even directly required by the owner, but are breakdowns of things that are.
Requirements in the other hand are a detailed specification in domain user's language of what the system needs to do in order to be valid. In many cases a requirements document is not optional (fixed price projects for example).
What I do is a mix of both. I have a requirements document, and in most of my scrum stories, I have something in my notes that link that story with one or more items of the requirements. It is as simple as "See FR-042 and FR-45" (FR for functional requirement for example)
I think you are asking for a few different things here. If you are adding a new team member, then the documentation for the system should be geared toward their role on the team as part of the on-boarding process.
If you are talking about documenting the system functionality; in our organization our training teams document the functionality as part of the release. They are engaged (as a stakeholder) during the Sprint Review (demo) and then provided a training environment with the new functionality to prepare the training materials prior to release.
If you are talking about providing documentation for tractability, your backlog can serve as that with the proper process & controls added.
Each one of these different items takes planning and deliberate process development to effectively function and meet the needs of the team. We have included each one of these items in our retrospectives as an issue was identified and then developed our processes over time.
In addition to what James Kolpack said, the user story map should persist after the project is finished as it too is a form of documentation. I believe we plan to some how convert it to a document that lives in our Wiki when all is said and done.
The idea is that this document will be useful for people who need to maintain the system or add enhancements to it in the future because they will have an understanding of the user's perspective.
I mostly agree with Todd, but there was times when part of my team's task was to produce documentation : Documentation was the user story itself our PO asked to be delivered.
In these cases we followed the following guidelines:
try as much as we can to extract documentation from actual working code (typically some document generation program that read internal data structures or configuration files used both for building the actual program and build documents).
define in the documentation US the goal of the documentation :
who the reader is supposed to be
what he should be able to achieve reading that document.
In my experience that makes documents easier to write and enable some kind of test (you ask to someone, typically PO, to read the doc and say if it's OK considering the goal).
You write documentations to validate your system. User stories serve the same purpose if written correctly in a format that reflects user interaction with the system. I will recommend using BDD and writing stories using Gherkin syntax. Eventually your scenarios become your acceptance criteria which helps in validation whether the system is working correctly or not.
We have a docs team that produce the "instruction manual" for our product. The manual is structured around the main features of the product, and the tasks that the user can perform in those features.
Each sprint, Scrum teams work on user stories that add functionality to the product features.
After sprint planning, the docs team meet with the Scrum team and see which user stories that will be developed this sprint. The docs team then start enhancing the instruction manual by writing the initial docs. During the sprint, the docs team follow the progress of the user stories, and can use the product as it's deployed to test environments. At the end of the sprint, the docs team finialise the updated instruction manual and add final screen shots etc...
The instruction manual ship as part of the release each sprint.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is there a comparative analysis available for Mint and Google Analytics which can help me decide which one to implement in my situation?
For every website I work on I only use Google Analytics. My main reasons:
free -- for unlimited sites and hits
no ads
I don't find it hard to use and my clients haven't found it hard either (most figure it out within minutes)
it has an API, so if you want more, you can add your own stats or even incorporate into the site
for ecommerce, the extra tracking for ecommerce is great
there are theories that it might even help your Google ranking (as they gain extra data about your site)
a lot of people use it, so often the JS is cached
easy to setup (I don't know about mint, but GA is a few lines of JS)
connects to adsense so the stats can be tracked together (I don't know if others support this)
... and more.
Mint is simpler, always up to date, and has a lot of plugins aimed at blogs and personal sites. Google Analytics is more complicated and takes a little time to understand, is updated daily, and has more features for larger sites such as marketing, e-commerce and such.
On my own sites I started with Mint, used both of them for a while, but now I'm pretty happy with just Google Analytics.
I've been using Google Analytics in an enterprise environment for a few years now. There are certainly limitations, in particular with merging to other datasets. The API has been invaluable to bridging this gap, and really encouraging stakeholders to ask better questions.
In my opinion, evaluate both and work out the strengths and weaknesses based on your business requirements.
Why have you opted for these two possible options in particular? There are a number of good packages out there, many of which are free and offer excellent services that may provide compelling advantages over the "default" choice, Google.
Have a look at this ReadWriteWeb post that compares 10 free analytics tools for starters.
I use Clicky on my site and find it to be an excellent alternative to GA.
If you are interested in open source server-side analytics you should check http://piwik.org/. I did not use it myself but I've heard good it's decent, comparable to Google Analytics. I myself use GA and I'm happy with it. Just get some additional testing like Kiss Metrics and you should be fine :)
I recommend GA so that as your site grows bigger, you are already on top of a fine analytics tool. Mint is fine for now, but you need to plan for the future, too.