We currently have an existing page for our checkout, let's say checkout is the URL.
We would like to create a new version of this page and specifically control the number of users that enter this view/route.
As an example, we would start with 50% of all users will access the original and the other 50% will access the new.
Ideally, we would like to keep the same URL structure and just change out the view that is displayed. No changes are required for the existing view/path setup.
I have looked at a bunch of A/B Testing options but cannot see one that fits these requirements. Ideally, I'd like to keep this server side. Can anyone recommend any A/B testing options that can help with this?
There are multiple ways of accomplishing this. You could use a testing tool server-side SDK like Optimizely or Google Optimize.
Both having cons and pros. This would allow you to make a bucketing decision on the server using a unique user identifier. I typically use a random string in a Cookie. This would allow the controller to switch out the view based on the variant and send goals and objectives to the correct analytics platform. Optimizely's SDK has bucketing built-in and Optimize allows the developer to perform the bucketing themselves. Avoiding the need for an API and therefore slowing the server speed down.
Another way is to add a param to the end of the URL that switches out the view on the server. Then use a redirect test on a front-end testing tool to redirect from the default control to the variation. This typically tends to be better if you are using a caching server as you can avoid the logic involved in cache busting.
Here are a few links to help you out!
https://developers.google.com/optimize/devguides/experiments
https://docs.developers.optimizely.com/full-stack/docs
Related
I'm using this link https://www.google.com/reader/api/0/stream/contents/feed/FEEDHERE?output=json&n=20
to fetch feeds using Google's algorithm. As you can see I'm not adding any other parameters, just fetching the returned data in JSON format. My app will be heavily used hopefully and if I send a lot of requests to this link, will Google block my access or something?
Is there anything I can include, like userip, url for my app (so if they have problem to just contact me) or something else?
The most basic answer to your question is that Google will change its Terms of Service whenever it likes, and you've got no say in the matter. So if it's allowed today, it might not be allowed tomorrow, at Google's whim.
On this issue, though, you seem fairly safe. From the Terms of Service (these is the general document, since Reader doesn't seem to have a specific one):
Don’t misuse our Services. For example, don’t interfere with our Services or try to access them using a method other than the interface and the instructions that we provide.
Google provides RSS and Atom. They provide these feeds, so I assume they expect that they'll be used. They don't say that it's a misuse to point someone else at those feeds, so it looks OK for now, but they could add such a clause at any time.
All online services are subject to the terms and conditions of the providers of those services. So, as others have said, they may be ok with your use today, but they can change their mind any time down the line. I doubt including a URL or email or contact info will help anything, because when these services change, they don't notify every user of the service, they just announce the change publicly, and usually they give several month's notice in order to give users a chance to adapt their applications, but this is not standardized or enforced so there is no guarantee. One example would be the fairly recent discontinuance of the Google Finance API (for which no replacement has been announced).
The safest approach would be to design your app such that this feature that uses google's functionality is decoupled as much as possible from the rest of your app, so that, when or if the availability of the service changes (ie it's no longer available at all) you can adapt your app to use some other source for the feeds with minimal impact to the rest of the app. Design for change and plan for the worst.
I have a simple page that provides a search experience. It allows users to search via a query form, filter results, and perform more in-depth searches based on the results of the first search.
I would like to get some metrics around the user experience and how they are using the page. Most of the user actions translate in a new query string. For example:
how many users perform a search and then follow up with another search / filter
how many times a wildcard is used in the search query
how many results does a user browse before a new search
I am also limited of using google analytics and the sort because of copyright issues (maybe I can make a case if it is really the way to go for open web analytics or smth). Server side I am thinking of using cookies to track users and log4net to log what they do, then dump the info in a db and do analysis from there. Or log to the event viewer and use the Log Viewer to get the info from there.
What do you think is the overall better approach?
I would recommend you use an existing, off-the-shelf solution for this, rather than building your own - it's the kind of project that very rapidly grows in size. You go from the 3 metrics in your question to "oh, and can you break that down by the country from which the user browses?", "what languages affect the questions?", "do they end up buying anything if they click results for bananas?". And then, before you know it, you've built your own web analytics tool...
So, you can either use "web analytics as service" offerings like Google Analytics, or use a more old-fashioned log-parsing solution. Most of the questions you want to answer can be derived from the data in the IIS web logs; there are numerous applications to parse that data, including open source and free solutions.
It's been a long while since I used a log file based analytics tool, but my ISP provides AWStats, which seems pretty good - to do what you want, you'll have to set up specific measurements around your search page; not sure if AWStats does that (Google Analytics definitely does); check the Wikipedia list for log file analysis tools which do that.
Obviously you need to log every submit of the search page.
In particular you need to log:
DateTime.Now
SearchString
SessionID
You could also store a counter in the Session that will be incremeted each time a user loads a page, that is not the search page.
If the users performs a search you could read that value from the session, store it in the database and reset the counter.
Be aware that the metric of "how many results does a user browsw before a new search" should only be taken as an estimate and not as a real metric, due to cookie support, multitabbing, page reloads et cetera.
Explanation of the problem:
Right now my asp.net mvc 3 application is using cookieles="auto" setting which I really hate and I am trying to find something that will allow me to turn that feature off.
So I came across HTML5 storage solutions and I am having some trouble understanding the idea behind it. So basically all I need to do is take my userID variable and move it from one page to another and then on the backend I pull out this userID and pass data to view as a model. Now, how can I do it without cookies and using HTML5 storage? If it's only accessible via JavaScript do I need to pass it via ajax to my controllers? But I don't see any sense in this since I already passed my model to the view with empty userID because the cookie was empty.
Is there a way to access the HTML5 storage in the backend? Maybe I am missing something here, please advise!
No, there's no way except javascript code, which will read storage content and send it to backend. For small portion of data, which should be available to the server, use cookies.
Local storage was created specially for content, which will not be transfered to the server with each request and therefore allowing to store more data, than cookies w/o traffic spoiling.
I am facing an issue when we are using multiple tabs since its sharing the same session. Any alternatives to this? Can we create a unique session when someone uses the tab or CTRL+N.
It's a Java EE/Struts2 enterprise application if this matters.
This is a problem all server-centric web applications face, it's not specific to Java EE. The problem is that most browsers store cookies on a per-user basis, not per tab. Also, this behaviour is not generally transparent to the user, adding to the confusion. A few solutions I can think of (although none of them is really satisfactory):
Host the application under more than one URI. This way, any browser will store cookies independently, and consequently, you have one session per application version.
Propagate session IDs through a different mechanism, e.g. through the URI. This, however, has a few caveats - it exposes the session ID to the user, it makes for ugly URIs, and it forms a security risk (session hijacking and such) when users copy-paste or bookmark the current URI (because they then store the session ID in the link).
Propagate session IDs through hidden fields inside the page. This solution probably requires you to rewrite part of the built-in session handling, and it loses the session ID when your page contains links to other pages within your application.
For Firefox, there's an add-on called "cookie pie", which allows users to have independent cookie stores for some or all tabs. Downside is that users have to actively enable it, and working around the tab problem becomes the user's responsibility. Also, it doesn't work under all circumstances (e.g., google finds your active login regardless).
Avoid using session state, and use other mechanisms to preserve state between requests. Like passing session IDs through hidden fields, this breaks under certain circumstances.
Make the application fully client-centric, that is, program the entire interface in javascript and communicate with the server through ajax calls. This way, you won't depend on the browser's cookie implementation at all. Chances are you'll have to rewrite substantial amounts of code though, assuming your application is basically working already.
There is no simple way to achieve this that I know of.
The usual way to fix this is to change the app so that it can deal with users using multiple tabs (if possible).
There are several workaround ideas for how to "disable" the old window if the user presses Ctrl+N while walking through a multi-step form, but you'd have to give more detailed information for ideas on that.
Usually a browser instance is treated as a single user/entity for session tracking purposes. Especially if you are using cookies to track the sessions. I am not sure that I like the idea of allowing different tabs to have different sessions. It feels unintuitive for web based applications. All IMHO, of course.
That said, if you want to change this you will have to come up with a custom implementation. Perhaps you can generate and attach different session ids to the URL for different tabs. Never tried this myself so do not know how easy or difficult it will be.
we have some application that this is vital to prevent users from opening multiple tabs/windows per session on the website ?
Edit:
The reason is that those pages communicate with flash and we cannot know on server side whether the user has two windows open or not.
Of course you can suggest to make those changes in application design so it will use Flash Media Server as "token generator" but we cannot allow ourselves to change the infrastructure without good reason because it can take months
This is a bad idea - you are restricting how the user expects their browser to behave.
Don't do it.
The only way I could think of to reliably do such would be to have a session that kept track of a token which was updated each time a page was requested - links on the served page would all include the token, and when a page was loaded using that token, a new token would be generated (in essence, only allowing any page's links to be valid for a single use). However, this would break things like the Back button and whatnot, and thus isn't a very good solution.
What is so important that you have this requirement in the first place? Is there any way you could re-think your interface so as to avoid such?
If limiting the user to 1 interface at a time is vital to the app, you should consider writing it as a desktop application instead of a web application.