可接受的电子商务失败率？
我是一家小型但不断发展的电子商务网站的网络开发人员之一。现在每天收到约 150 个订单，而网络星期一的订单量会更多。这是足够的容量，因此一小部分遇到难以重现问题的用户会导致严重的堆缓存。我的理论是，以下情况之一是正确的：
- 客户使用的是不寻常的浏览器/操作系统
- 客户遇到网络故障
- 支付网关返回响应的时间太长
- 客户在关键时刻以某种方式按下了退出按钮或后退按钮订购过程中的某个时刻
- 客户关闭浏览器
- 客户的浏览器拒绝导航到下一页
这些问题的最终结果通常是客户在不知情的情况下从信用卡中扣款，并经常尝试下第二个订单。在这种情况下，必须对这些重复交易之一进行退款。
尽管我想说服我的客户，总会有“正常”百分比的订单出现“奇怪”的故障，但我不知道“正常”是什么。
因此我的问题是：
根据您作为电子商务开发人员的经验， 您观察到的这些故障的发生率是多少？
或者，如果您能给我提供统计数据，那也会很有帮助！我还没找到。
谢谢！
附：我知道解决此类问题的根本原因是理想的选择，但即使在提交了数百个测试订单后，我仍然无法重现该问题。
I am one of the web developers for a small-but-growing e-commerce site. It is now getting about 150 orders per day, and a lot more on Cyber Monday. This is enough volume so that the small fraction of users who have hard-to-reproduce problems are causing significant heacache. My theory is that one of more of the following are true:
- The customer is on an unusual browser / OS
- The customer experiences a network glitch
- The payment gateway takes too long to return a response
- The customer somehow hits escape or the back button during a critical moment in the ordering process
- The customer closes their browser
- The customer's browser just refuses to navigate to the next page
The end result of these problems is usually that a customer unknowingly gets their credit card charged, and often attempts to place a second order. In that case a refund has to be issued on one of these duplicated transactions.
Although I would like to convince my client that there will always be a "normal" percentage of orders that have "weird" glitches, I don't know what "normal" is.
My question is therefore:
In your experience as an e-commerce developer,
what is your observed rate of these glitches?
Alternatively, if you can point me towards statistics, that'd be helpful, too! I haven't been able to find any.
Thanks!
ps. I know that it would be ideal to fix the root cause of such problems, but I simply have not been able to reproduce the problem, even after submitting hundreds of test orders.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你知道那句老话吗——“如果你必须要求，你就做不到”？
它适用于此。
You know the old saying - "If you have to ask, you can't affort it"?
It applies here.
您的问题很可能是由上面列出的原因引起的 - 当然，除了代码中的任何错误之外。
但这对您的客户来说是一个足够好的解释吗？随着应用程序流量的增加，这些问题也可能会增加。
您可能需要实施一个更强大的流程来处理意外问题，以便客户不会被收取费用，除非您捕获了他们的订单，或者通过电子邮件通知他们订单已完成/出现问题/他们应该采取什么行动。
编辑：
您的问题是何时停止改进网站。我认为这取决于您想要为客户提供的服务水平（即时间）与他们对所支付费用的期望。
你如何处理它构成了你的业务策略的一部分，但我的方法是非常诚实地向他们展示这样的列表，并估计修复每个项目的时间。确保他们了解每项修复所实现的收益递减。免费给他们一些东西，然后向他们收取其他费用。与他们谈判；给他们一个您保证达到的 KPI 或绩效目标。重要的是，他们了解设计近乎完美的交易系统所涉及的成本。
It's very likely that your problems would be caused by the reason you listed above - apart from any bugs in your code, of course.
But is that a good enough explanation for your client? As the application traffic increases these problems are likely to increase as well.
You may need to implement a more robust process that can handle unexpected problems, so that customers are not charged unless you have captured their order or they are notified by email that their order completed / something went wrong / what action they should take.
edit:
Your question is when to stop improving the website. I think this depends on the level of service (read: time) you want to give to your client vs their expectations of what they have paid for.
How you deal with it forms part of your business strategy, but my approach would be to very honestly show them a list like this with time estimates to fix each item. Ensure they understand the diminishing returns that each of these fixes achieves. Give them something for free, and charge them for anything else. Negiotiate with them; give them a KPI or performance target that you guarantee to meet. It's important that they understand the costs involved in designing a near-perfect transactional system.
我不会猜测，而是尝试断言错误是如何引发的，构建一个简单的表单，用户可以在其中向您留下他们使用的浏览器、系统规格（可能）以及重现所出现的缺陷的步骤。
然后，利用这些信息，您可以调试您的应用程序，进行单元测试并修复这些错误，或者将它们减少到不会妨碍用户在您的网站上购买商品的形式。
Rather than guessing, I'd try to assert how the errors are raised, build a simple form where users can leave you the browser they used, system specs (maybe) and the steps to reproduce the defect that araised.
Then with that information you can debug your app, make unit tests and fix these bugs, or reduce them to a form where they won't impede your users from buying stuff at your site.
通常，只有一两个人使用奇怪的卡或奇怪的浏览器/操作系统组合引起所有头痛，而所有“正常”人都进展顺利。
您最好切换到支持后台处理的网关（当订单信息打包成 XML 并发布到网关时，客户始终停留在您的结帐页面上，并且它会立即响应任何错误） - 这至少可以消除傻瓜的导航问题。
Usually it is just one or two people with weird cards or weird browser/OS combo that cause all the headache, while all "normal" people proceed fine.
You better switch to a gateway that supports background processing (customer always stays on your checkout page while order info is packed into XML and posted to the gateway, and it instantly responds with any errors) - this will at least eliminate navigation problems for dummies.