Ways to Test Your Ecommerce Analytics Setup/
September 8, 2016
Like any computer system, website analytics shouldn’t be trusted until it has been verified. Many parts of a Google Analytics implementation are easy to verify: Nobody really minds if you go to their website and click around random pages, looking for pageviews and link tracking. Testing form submission tracking can be labor-intensive if they have many fields, but most website owners don’t mind a few spurious submissions from Testy McTesterson.
But testing ecommerce tracking is different. There’s a part of the checkout process where it says “Thank you for your purchase!” with tracking that you want to test, but getting to that page usually involves putting in credit card information and charging real money to it. And furthermore, the tracking on that page is extremely important, because that’s how you know how much money your website made and begin attributing those transactions to the appropriate traffic channels.
But don’t worry! There are ways to test the tracking on that page and make sure it’s working correctly (or fix it!) that don’t involve spending money.
The most important thing to remember is that every website is set up differently, and you need to communicate with your development team. There is no single strategy for placing test orders that will work with every ecommerce system. You need to find out which strategy will work for the particular system that you’re tracking.
Hopefully, the developers already have a method that they use for their own testing. But sometimes you may not be allowed access to the developer’s internal tools, or their process may not meet your tracking needs. It helps to have a few suggestions in your back pocket. It also helps to ask about this as early as possible (i.e. when you find out that an ecommerce system exists), because some methods have a lead time to set up.
A common challenge is making sure that your test process exactly duplicates the real, live checkout process. Sometimes test environments have missing features, or aren’t kept up-to-date.
The following strategies are commonly used by LunaMetrics, along with the pitfalls of each:
Get access to a test server or QA environment where you can place as many transactions as you want. Ideally, your analytics implementation is exactly the same on both environments.
Pitfalls: Test servers fail to exactly duplicate the production environment more often than you would expect. Also, you may have some tags that only fire on the live site.
Fake User Account
Often, the website may already have a login to a special account on the site, whose orders will be ignored. Log in, shop as normal, place order, and the system automatically kicks out the order.
Pitfalls: an account cannot be used to test “guest checkout,” which is often a different page flow.
Fake Credit Card Number
Similarly, many credit card companies have special credit card numbers that are recognized as fake, and the website you’re testing may recognize one of these and allow the order on the front-end, but then stop the order on the back-end. A quick Google search can give you more info on testing credit card numbers.
Pitfalls: The credit card may be treated differently by the payment platform, but not the ecommerce back-end, resulting in strange errors or discrepancies.
Provision a special coupon code that the ecommerce system will recognize and drop.
Pitfalls: Requires extra development work.
Order and Cancel
Place an actual order, and then cancel it. Sometimes the site already allows cancellations or refunds, but sometimes you have to get on the phone with Operations and ask them to delete the order manually.
Pitfalls: Logistically complicated. Sometimes orders move past the point of cancellation too quickly.
Worst case scenario, place a real order. This is your last resort, and should only be considered if no other options are available. At the very least, use a company card and/or expense your order.
Pitfalls: Costs real money. On the flip side, your office might get some cool swag!
As with all testing, you can only find bugs in the parts of your implementation that you actually test. And ecommerce tracking is more complicated, so it’s harder to get all the details right. It helps to have a testing plan, so you can guarantee you aren’t missing any features or edge cases.
A testing plan is just a list of interactions you will perform, the hits those interactions should generate, and the values those hits should have. Writing out your testing plan also lets you compare against other documents, like a requirements document or an implementation plan, to make sure you haven’t forgotten anything.
A testing plan can also help you minimize the number of test orders you need to place. Some testing methods are onerous or restrictive, so you want to make sure that your small number of tests covers the entire implementation.
Your testing plan for checkout should include all of the Google Analytics Ecommerce features that your site is using. At a minimum, your test purchase should include multiple items, and different quantities, categories, and brands for each item. If you are making use of advanced ecommerce features such as coupon codes, product variants, or product-level custom dimensions, then make sure to include those in your test plan as well. You should also include any features or edge cases that your ecommerce system may have, such as product bundles or items on sale. Be sure to test all possible transaction flows, such as logged-in/logged-out checkout or one-click checkout.
For an enhanced ecommerce implementation, your test plan should include the full end-to-end purchase process across all the touchpoints: from Product Impressions, through Product Detail Views, through Adding to Cart, all the way to Purchase. Several Enhanced Ecommerce reports, such as the funnel visualizations, require these events to be tracked in a consistent fashion. Testing them in isolation may not reveal consistency errors that break conversion rate calculations and funnel reports.
Testing Enhanced Ecommerce is not complete until you have looked into the reports and verified the funnel flows. You can isolate your own visit by using UTM parameters to give your visit a custom campaign, or by creating a visit-level Advanced Segment from your Transaction ID.
No matter how thorough you are in your testing, sometimes you won’t uncover a bug until days after your original round of testing. Despite all your hard work, you may need to place more test transactions—unless you’ve saved a recording of your session! Session recording tools can also help you figure out if something changed on the site since your original test.
Session recording is useful for testing any aspect of website tracking, but it’s almost a necessity for ecommerce tracking. In addition to avoiding repeat orders, ecommerce tracking requires consistency across multiple hits. Catching this sort of error requires recording information about each hit.
While it’s possible to record sessions manually by pasting values into Notepad or Excel, it’s much easier to use a program that records sessions for you. The following are a handful of tools that can debug tracking and record sessions at the same time:
Ecommerce tracking is harder to get right, so communication and planning pays off. Work with your developers to create a test process and plan your testing to cover every feature and edge case that you’re tracking. Record your tests, because those records will make your life easier.