Are you a Google Analytics enthusiast?
More SEO Content
Posted 13 December 2004 - 06:08 PM
We've attempted to implement precautions to prevent double postings of this nature, from disabling the back button to displaying a visual warning not to use it... and still some of these creep through.
I've started tracking the IP of the online order for the single purpose of identifying entries in the log files when there are double postings such as this. I'm curious if there is a way to identify and interpret all of the extra info tacked onto the user agent strings that may help me to identify some consistency in the orders/users that are causing the double postings, then testing with that browser version/opsys version, etc... to test and attempt to code around the problems.
Has anyone else experienced double posting problems with online forms such as this and how have you gone about troubleshooting the problems?
Also is there a way to identify the individual pieces of the user agent strings, such as:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sbcydsl 3.12; YPC 3.0.1; .NET CLR 1.0.3705; yplus 4
What is the "sbcydsl 3.12" and "YPOC 3.0.1" on the agent above?
Has anyone spent any time troubleshooting in this manner before or am I on the wrong track?
Posted 13 December 2004 - 06:57 PM
Yes there are ways to pull out very specific user agent data, but how to do that is going to depend upon your back end programming language. If you can let us know if you're using PHP, ASP, etc I'm sure someone here will have a solution.
We get a duplicate order occasionally on our systems, but it's not often thankfully.
Usually what is happening is that the order page doesn't refresh quickly enough for some reason and people think nothing is happening so they click on the Submit button again. People get impatient.
That can happen for a lot of reasons. Ranging from the buyer's connection speed, to DNS issues to a load on your https server. Hard to say which without some testing.
Posted 14 December 2004 - 11:52 AM
We're using PHP/MySQL.
Maybe I just expect too much from our users . I know not everyone is a programmer, but it gets frustrating sometimes and is nice to hear someone else say they have similar issues...
I'm not really interested in pulling out VERY specific information from the logs for tracking and analysis purposes... just curious if that would be a way to troubleshoot the double postings.
I'm just trying to find some consistency in either the customer, browser or opsys from the logs to determine if we have a post/get problem with that particular software piece or user.
Keep in mind that as much as I hate it, many of our customers are still on dial up and the lag time in submits probably results in many of the dupes. But I've also encountered duplicate postings even while I was testing from my PC. Particularly with Firefox. There was a period of about 4 days that I repeatedly entered test orders from my PC using Firefox and each of the test orders posted a good test order and a blank dupe order with nothing out of the ordinary going on at the server level. Think I was on .8 at the time, but now 1.0 and I haven't had the opportunity to test again since then. We've also had one customer whose husband was a Tech guy and had his wife using firefox and we encountered duplicates from their shop.
By the way, love the signature.
Posted 14 December 2004 - 12:04 PM
Posted 14 December 2004 - 12:12 PM
Posted 14 December 2004 - 12:13 PM
I guess this is the difference in application programming via the web vs. straight display of information on the web... I could add more strict validation before the database writes, but I'm thinking that the customer might see a message on a second submit and think "Well I don't think that order went through... I'll enter it again". Then we'd have 3 dupes. The blank orders are not such a chore to handle now, but our relay business is booming and I expect the problems to multiply...
Thanks for the replies... any other takers?
Posted 14 December 2004 - 12:15 PM
didn't see your reply while I was writing, I'll look in to the submit disable further,
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users