Not all purchases are tracked

Hi! Were you able to identify what do untracked orders have in common? I’m asking because we recently received a support ticket where, apparently, orders payed via Google Pay or Apple Pay didn’t have split test information in them, hence explaining why they weren’t added as conversions…

Anyway, because of this ticket I’m mentioning, we’re currently working on a new method to attach to an order the variants each visitor has seen (via WoooCommerce sessions). This should hopefully catch your missing data.

Stay tuned for the upcoming version!

Hi David,

interesting question. We track only completed orders. So, bank transfer is excluded. We offer PayPal, Amazon Pay, credit cards and SOFORT. 90% of the customers choose PayPal or Amazon Pay. It is very likely that these methods work perfectly well. My best guess would be that credit cards and/or SOFORT might be the problem. Is a more detailed logging available for the test?

Anyway, it’s really not a big deal, since almost 90% tracking is quite ok, I guess.

Mike

You can look at your orders and see if a Nelio A/B Testing metabox is available (it’s only present if there’s some test data related to that order). If there’s none, that order, for some reason, was unable to capture the variant the visitor has seen. It could be that, indeed, they didn’t see any variant. Or there’s just something in that order in particular that prevented our plugin from attaching test data to it.

Sounds great. The data seem to be stored serialized in the postmeta table. How would I check this directly in the database? As far as I can see there are two meta_keys:

_nab_synched_goals
_nab_experiments_with_page_view

It would be be very time-consuming to go through all orders manually in the WP dashboard. At first glance, I couldn’t see a pattern. It seems that credit cards orders were synched correctly.

You should look for _nab_experiments_with_page_view, which is the meta that links the variants a visitor saw to the order itself. The other meta keeps track of the conversion: i.e. has it already been sent to Nelio’s cloud or not?

Ok, that’s even more strange. The test has so far tracked 72 conversions, but I found 84 entries for _nab_experiments_with_page_view (a tracking rate of 85%). All missing conversions were PayPal orders. In addition to that I couldn’t find any pattern.

I have an idea: The variant B in our test removes the PayPal express checkout button from the cart page. Could this be the problem? Due to some issues with Google Tag Manager we have to deactivate Nelio on the thank-you-page. Customers that use the express checkout might not be tracked, right?

I guess that’s possible, yeah. If you deactivate Nelio on the page where you’re supposed to track conversions…

Hi David,

that’s not the whole story. Most orders are tracked just fine even with the tracking disabled on the order-received page. The problem is the express checkout button that forwards user from the cart page to PayPal and back to the order-received page. At least that’s my best guess.

Not a big deal, since we will probably disable all express buttons anyway.

Thanks, Mike

I understand. And I guess it makes sense, given that the current version of our plugin links an order to test data by appending some data into the checkout form.

Well, as I said previously, we’re working on an update that’ll also attach test information to a customer’s WooCommerce session. Hopefully, this will fix the issue.

Hi David,

that would be awesome. However, I understand that this is probably quite tricky. The more important issue was the problem with Google Tag Manager (GTM). This gave us some headache before we understood that the redirection to the variant is simply so fast that GTM won’t get the data. Many shop owners do use GTM. With Nelio running in standard mode, they will loose 50% of actual conversions.

This gave us some headache before we understood that the redirection to the variant is simply so fast that GTM won’t get the data

But that’s precisely what you want, right? I mean, GTM should (ideally) not track anything until the visitor has been redirected to the appropriate variant. Otherwise, anything that GTM tracks before the redirection occurs would be “a lie,” since the visitor will be redirected away from that page anyway.

But that’s precisely what you want, right?

Not sure, that I understand what you mean. Among other things GTM tracks the actual conversions. For the SEM guys it is not relevant whether variant A or B converts better. They just don’t want to MISS any conversions. This is what the customer pays for! In terms of SEM a conversion is a user clicking on the Google ad. From the SEM point of view it’s irrelevant which variant perfoms better.

Am I missing anything? ??

• This reply was modified 1 year, 2 months ago by cutu234.

I’m not sure we’re talking about the same things, lol

If you want GTM to track a visit on a page that’s under test, I agree with you: it doesn’t really matter if the user is supposed to see variant A or variant B. And, if I understand you correctly, the fact that the visitor might be redirected to variant B before GTM tracked anything might result in a page view being lost, correct? In that case, you’re right.

Hi David,

usually, the test does not interfere with GTM. Tracking (in terms of conversion = purchase) works just fine, IF we deactivate tracking on the order-received page. The reason is that the purchase event is not fired fast enough. I have no idea why this is a problem on this particular page, but we lost 50% of the conversions. So, it’s pretty clear that the running test was the problem.

Just to make this as clear as possible. We track, for example, URLs that contain:

/cart/
/checkout/

But we always exclude:

/checkout/order-received/