Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Guarding against Jirafe false positive conversions #2273
Whoever pulls this one in should cherry pick this to 1-2-stable as well as master, AFAIK they all suffer from this.
Should be pretty obvious, but basically after cross-referencing actual collected conversions server-side against client-side GA and Jirafe, it was obvious Jirafe was way too optimistic.
I'll look into the regression test.
The semantics of tracking a conversion is as this: 'a customer has given us money'
Existing Jirafe implementation tracks conversions, or in the case of Jirafe, sends order data whenever the Spree::OrdersController#show renders the view.
This is a problem because viewing your order history does not constitute a conversion. Similarly, if one refreshes the success\completion page multiple times, only a single conversion should be tracked.
Current Spree approach utilizes the expiring flash pseudo-hash, so that the conversions only run once.
The Google Analytics implementation of Spree already does this correctly.
Sure thing, just that you asked for an explanation.
The above is correct. Now:
Jirafe just reported 2 sales. Google Analytics reported 1. Jirafe is wrong. GA is correct.
I read the older bug report trails that @schof referenced and fail to see how this has since been addressed in 1-2-stable or master.
Google Analytics, AFAIK, will actually reject duplicate submissions based on the (unique) transaction id, in our case Spree::Order#number. Now Jirafe, from what is confirmed in our production environment, does NOT do this.
IMHO this bug is extremely simple and this is an issue of miscommunication or something. If I can further clarify anything, let me know.