Search the Community

Bonjour à tous, Je n'arrive pas à trouver la Destination de la page de confirmation de commande de mon site ; c'est pour configurer un Goal dans Google Analytics afin de tracker la performance des ventes (transactions). J'ai configuré l'objectif sur CHIFFRE D'AFFAIRE et EFFECTUER UN PAIEMENT. J'ai activé aussi Ecommerce Enhanced. Par exemple, lorsqu'un client achète un produit par carte bancaire ou avec Paypal, il est redirigé sur le site avec une page qui récapitule la commande. Ce que je cherche à faire, c'est placer cette url dans Google Analytics pour obtenir des données sur les ventes. Le problème, c'est que l'url est différente selon la commande : voici l'url d'un achat test -> https://nomdusite.com/confirmation-commande?id_cart=XXXX&id_module=70&id_order=XXXX&key=numerodelacle Si je mets cette url dans Analytics, ça ne marchera pas bien sûr, parce que ça concerne uniquement 1 commande. J'essaie de trouver la destination qui prendra en compte toutes les commandes. Je me suis renseigné, d'autres personnes ont eu le même problème sur 1.6. J'ai mis pour l'instant /order-confirmation.php. Cela me fait une estimation de conversion 0.03%. Je pense que ce n'est pas la bonne Destination. Il y a eu depuis des ventes, et aucune donnée n'est disponible dans Conversions -> Commerce Electronique -> Performance des ventes Vous auriez la possibilité de m'indiquer comment je peux trouver la bonne destination ? Le site utilise le module de paiement Systempay. Si vous pouvez me renseigner, je vous remercie d'avance !

Hallo, Ik zie niet alle bestellingen terug in mijn Analytics account en Facebook business manager. Ik heb de missende transactie-id's geanalyseerd maar zie geen verband tussen de transacties. Ik heb bijvoorbeeld een periode waarin Analytics aangeeft dat er 55 bestellingen zijn geweest, terwijl dit er in werkelijkheid 80+ zijn geweest. (relatief gezien, groot verschil dus) Ik heb het idee dat het misschien kan liggen aan het feit dat niet al mijn klanten de 'thank you'-page zien. Daar haalt Analytics immers de 'conversie' vandaan (volgens mij). Wat zou ik kunnen doen dit te verhelpen (& hoe), Ik ben erg benieuwd of jullie mij kunnen helpen want ik ben inmiddels radeloos bij dit probleem. Met vriendelijke groet, Bas

Salut, J'ai un bug depuis deux semaines et je ne trouve pas de solution. Aidez moi!! Certaines transactions sont bien acceptées et payées, mais ne sont ni renvoyées sur le Back office (donc impossible de savoir qu'une commande a été passé sauf en allant dans la liste des transactions de mon prestataire de paiement...) et ni renvoyées sur le front office, le client ne reçoit aucun mail de paiement accepté, et sa commande n'apparaît même pas dans son historique de commande. En fait les commandes sont sur Paypal mais ne figure pas sur mon back office dans "commandes". Elles sont dans paniers dans "non commandé" la plupart du temps. Et certaines fois, je n'ai même pas de trace de la commande. Je ne reçoit pas toutes les commandes par mail ni tous les avis de paiement de paypal. C'est très aléatoire. J'ai contacté Paypal, ils m'ont demandé de changer l'URL de notification instantanée de paiement IPN au format http://www.monsite.com/modules/paypal/ipn.php . Ce que j'ai fait. C'est activé.Ils sont bien envoyés mais le problème persiste. Prestashop après 10 messages en une semaine sans réponse m'a dit de réinstaller le module paypal, ce que j'ai fait mais rien n'a changé. Par ailleurs, je ne comprends pas aussi pourquoi sur une commande , il y a deux paiements dont un de 10,25€ qui apparaît sur paypal et l'autre de 952€ qui apparaît payé par paypal sur le back office et qui n'est pas dans paypal sachant que la cliente nous a bien dit n'avoir jamais commandé les 952€ de produits. Enfin, ce n'est pas normal non plus que durant le we où tout a commencé, il y a eu 85 paniers abandonnés du même produit d'une valeur de 69.30€ . Nous faisons-nous pirater?

Bonjour, Je me suis toujours demandé pourquoi Prestashop ne gérait pas les transactions SQL pour la création de ses commandes. Malheureusement hier j'en ai fait les frais pour la première fois. Le serveur SQL qui sature et les tables qui se retrouvent en Deadlocks résultant en des commandes à moitié créées sur le site. Sur un site à 300/600 commandes l'heure je vous laisse imaginer les dégâts si je n'avais pas réagit dans les 5 minutes pour passer le site en maintenance. Je me demande pour quelle raison Prestashop ne met pas en place un système plus robuste de transaction pour s'assurer qu'une commande ne soit jamais corrompue en base de données ? Il me semble que l'intégrité des données est un point primordiale pour un système de vente en ligne ? Au plaisir de vous lire

AuthorizeAIM module is not connecting with Authorize.net though the keys are correct and work on eBay. Unlike the FedEx or UPS con not modules AuthorizeAIM does not provide any feedback that the module is on line and working. Currently using 1.6.1.1.8

Hello, I have a multistore containing 2 shops which share the stock, but nothing else (they have different domains, in 2 different countries). Each shop has its own property ID (Universal Analytics) which I've set accordingly in the ganalytics module for each shop and data started flowing into Analytics (ecommerce is enabled on all the properties' views in Analytics). And here is my problem: all was well until I noticed that not all transactions are getting recorded in Analytics and to make things stranger: for shop1 about 30% of transactions go to UA for shop2 (same multistore) about 75% of transactions go to UA. Now I can't be sure about pageviews either, part of them may be missing too. Both shops have the same theme, the same modules active and have the same performance settings, the only difference is that they are on different domains, for different countries, thus in different languages and currencies. Setup details: Prestashop 1.6.0.9 on Ubuntu 14 ganalytics module: Google Analytics v1.8.2 - by PrestaShop One page checkout, the only payment option (for now) is Cash on delivery (so no leaving the website during checkout) Varnish cache, js, /order-confirmation and all account / checkout related pages excluded from getting cached. What I've tried: I simplified \modules\ganalytics\views\templates\hook\header.tpl to keep only the UA part of the code I've tried testing with CCC options (from Advanced Parameters > Performance) on and off, with no notable difference. Now I have them all On, except Move Javascript to the end => pageview script goes near the end of <head> and order-confirmation somewhere in the middle of <body>. I've removed from the above mentioned header.tpl the ga('ecommerce:addItem'...) part to eliminate any potential unescaped characters in the product names - though they were escaped by ganalytics smarty when $isOrder eq true, no pageview is sent, only the ecommerce part is run (the module is hooked on header too, so that will send the pageview) In Analytics there are transactions recorded from all major browsers / operating systems / device types (it's not like mobile/tablet or some browser type transactions are completely missing). When I make tests (from different browsers, mostly on shop1 - where the problem is bigger), most of the times the transactions pass to UA correctly. Each time I check the JS output in the page source and it looks fine, but I also had a few cases when the JS looked by the book and still the transaction didn't go to UA For shop1 the missing/passed transactions seem to happen in periods (consecutive days with mostly missing and consecutive days with mostly recorded transactions). What I don't understand: Why is a (big) part of my transactions missing? Since another part of them gets recorded I don't think it's a problem with the UA tracking code. What could explain the difference of percentage of recorded transactions between shop1 and shop2? Did anyone else experience anything like this? Was there a solution or workaround? Any thought will be greatly appreciated, because I'm out of ideas Thank you, Dan

In the order page when I tried to add a new transaction manually then I got the following error in the back office but the transaction is getting added each time though there is error on the page. Here is the screen shot of the error. Can somebody tell me why this error is occurring ?

Bonjour à tous, Je vous contacte pour vous demander quelques renseignements concernant la prise en compte des transactions par CB dans Analytics. Je suis traffic manager et je rencontre la problématique pour quelques une de mes clients. Comme vous le savez, Analytics n'est pas en mesure de tracker toutes les conversions par carte bleue car les clients sont renvoyés vers le site de la banque et ne reviennent pas toujours sur l'ecommerce. Ainsi, pour le moment, il me faut éplucher toutes les commandes une par une sur Prestashop pour en déterminer la source (Adwords, SEO, ...) et le CA. Cela prend un temps fou. J'ai vu que des modules semblent proposer une solution (Ganalytics Report entre autres). Ce type de module est-il fiable ? S'intégre-t-il à Analytics ? Peut-il être couplé aux segments déjà mis en place ou faut-il l'utiliser seul ? N'y a-t-il pas d'autres solutions ? Merci d'avance, Bien à vous, Laurent

Having a nightmare with website! The website is live and transactions are being made but nothing is being shown in the back office?? We are using atos sips and I have done a test payment which worked fine but now it is live it is saying no transactions have been made even though they are in our bank account!!! Please help, this is a major problem Thanks in advance