I am implementing Google analytics onto a ecommerce site. We are already tracking events like adding to cart, removing etc using the event tracking. I would like to know what is the ideal time to use the ecommerce tracking apis (addTrans & addItem). Here are my questions:
Should I call these functions for each product being added to cart?
Should I call these functions only when the payment is complete and them while displaying receipt screen?
What is the ideal way of implementation? please provide best practices if possible.
Thanks in advance
I would track few things,
1.How many got into payment form and failed to buy, which can indicate to you that something wrong with payments or page itself. Count number of visitors in checkout - number of orders.
2.How many users got into site and haven't added at least one product, which will indicate that something wrong with advertisement, landing page or website layout in general. Number of unique visitors - those who added at least one item.
Adding statistics for each product added to cart shows you what? If users buy certain product you can get that this product is most wanted but in cart means noting imho. As for your second question, i would implement my solutions written above.
I wonder if your customers should go to an externally hosted page to make a payment. If they do, then GA tracking will not show you the real source of your profitable traffic - it will show you the payment processor page as the source.
It is recommended, or at least suggested, that you place the eCommerce tracking that includes the _trackTrans call on the "Thank You" or "Confirmation" stage of your checkout process.
Also, it's worth noting that if the user refreshes that page that the tracking is on then the code will be fired again and you may see skewed figures in Google Analytics.
I was like you, I also implemented the event tracking first but I wanted to get a chance to implement the ecommerce tracking to get some $ data in there to browse. So, on the developers page. One of the examples is on the reciept page, but on my implementation that wasn't going to work since I am use a payment API. So, On my checkout page I setup the parent transaction. using :
_gaq.push(['_addTrans',
'1234', // transaction ID - required
'Acme Clothing', // affiliation or store name
'11.99', // total - required
'1.29', // tax
'5', // shipping
'San Jose', // city
'California', // state or province
'USA' // country
]);
Then when I am listing my items in the cart, I use PHP and a foreach to dump each item, sku, price per item and quantity into the parent level transaction like this :
_gaq.push(['_addItem',
'1234', // transaction ID - required
'DD44', // SKU/code - required
'T-Shirt', // product name
'Green Medium', // category or variation
'11.99', // unit price - required
'1' // quantity - required
]);
For the last step in the process, I send transaction data to my merchant processing (paypal) via the SOAP api and get numerous responses back. I do different stuff based on the response I get back. If there is no error from the JSON response I get an COMPLETED response, at that point is when I fire the :
_gaq.push(['_trackTrans']);
I'm not really sure if this is the true way to go about it, but it makes sense to me.
Related
A product in my store (e.g. a fine art print) has a base price of £20 and it has multiple customizable options (size / framing) that are added as additional items to the cart (e.g. Small [£0] / Medium [+£10] / Large [+£20] or Unframed [£0] / Framed [+£10] )
I have to do it this way because some products have more than 3 variant options (Shopify only supports 3)
These additional items that represent the customization options for the base product are added when the customer adds the base product to cart, but the additional products representing options are hidden to the customer in the cart.
At checkout however all is revealed, the base product appears with 2 additional items along with their additional prices. Not ideal but OK!
However, it occurred to me that there's nothing stopping a tech-savvy nerd from grabbing the variant ID of the additional items and sending a POST request to /cart/update.js that removes them from the order during checkout.
The customer just reloads the checkout page and they've just halved the price they have to pay!
I need to prevent this from happening.
I don't suppose there's a way to validate all the items in the cart when the customer requests the checkout page?
If that's not possible, how do other Shopify stores get around this issue?
If you are on the Shopify Plus plan there are two things you can do:
During checkout validation - use Script Editor to check the cart contents and if it's invalid, set the base product quantity and additional products to 0. This will prevent customers from checking out.
Post checkout validation - use Shopify Flow to cancel the order after it's placed and if it's invalid
But that's a lot of development, especially when you are not familiar with it, it will be hard to go through and make it work as expected (covering all edge cases). It's possible to create a such script but analysis of all possible scenarios and writing a code for it will take some time. If I were you I would consider an app that creates bundles as a single item. Adding such a bundle to the cart takes a few seconds to process as the app is making some admin API calls in the background but it solves your problem. I cannot promote any paid solution on StackOverflow but you will easily find something - there are plenty of solutions in the app store.
The decision comes down to your estimation + possible change requests and fixes vs. the cost of the app on a yearly basis
For our Spartacus project, we need to introduce additional Data properties in the checkout:
We have the case, that the user needs to select a delivery mode per product.
In an ideal world, upon selection, the selected delivery mode would be saved in the NGRX Store and also in the Backend to stay within the principle of the data binding defined here: https://sap.github.io/spartacus-docs/connecting-to-other-systems/#component-data-binding
Expected Data / User flow:
User goes to Checkout and to Delivery Mode Step
Custom OCC Call is made to load the supported delivery modes for each product (depends on product type and further customer specific logic)
The cart items are displayed, enhanced with a dropdown containing the available delivery modes
The user selects a delivery mode
The selected delivery mode is stored on the cart entry within the NGRX Store and saved in the backend
The new Cart totals is calculated based on the costs of the selected delivery mode
The new Cart totals is stored on the cart within the NGRX Store and saved in the backend
The user clicks on continue to get to the Review Order Step
The cart items are listed with the previously selected delivery mode
After some analysis of the existing code, we found a property deliveryMode on the orderEntry. This does not seem to be used anywhere in spartacus, but could be used to make Step 9 work by following this stackoverflow answer and this one.
Questions regarding this flow:
How can we extend the NGRX Store? We assume, it would be possible to just extend the facade (Active Cart Service), bypass the store and save the information in the backend (Described here) and afterwards refresh the store from the backend. Is that Assumption correct? If yes, that feels awkward though, as we need to reload the whole store just to contain the new property deliveryMode on the orderEntry
How can we hook into the price calculation of the cart totals to update the total based on the selected delivery mode? And again, how can we bring the new total sum into the store?
There seem to be several Answers within the Slack Channel without very few usable answers around extending the ngrx store, even though for us, it seems to be a quit normal task.. :-/
Any thoughts, inputs or support would be very appreciated. :-)
This seems like a difficult thing to accomplish seeing as delivery modes per product aren't supported as-is in spartacus. But some ideas:
You can extend core CartEntry classes (adapter, connecter, facade, etc.) to include the delivery mode for entries added to the cart. You will probably need to change all to include the delivery mode setting(s). All of these are exposed so you can modify them as needed including the store.
Utilizing multiple carts to have a product per cart and set delivery mode that way. But this would be cumbersome in my opinion.
As far as price calculation goes, I'm assuming OCC calls return total prices. Does the call for the cart entries include delivery mode costs per entry?
We have implemented the following work around and it works so far:
Enhance the Cart Model in the backend
Add new Endpoints to load the available delivery Modes per Product (by bypassing the NGRX Store)
Add new Endpoints to save the selected Delivery Mode (by bypassing the NGRX Store)
After Save Endpoint, a cart Reload is triggered, which loads the new cart totals having a custom property on the order entry (via type augmentation) into the store from the backend
It's already a lot of years past since Spartacus project started, but looks like it's still really raw projects. Spartacus is not ready to deal with real word customer's requirement and complexity of customize it quickly grow at real project(so you start to think do we really need it, as it's so unflexible at some dimentions). Some parts is really hard or not possible to customize, so you begin to search a workarounds(This question is one common case).
I think NGRX Store is one of the biggest pain in the ass to customize something at Spartacus. 2 years past and nothing changed by Spartacus team...
All I'm wanting to do is track sales of certain products from a certain date. My company is wanting to add a banner to track sales goals for raising money for charities. So basically, we'd tag a few products as being part of that goal, set a goal, and then need to update the goal progress by a certain amount every time a sale is made on one of those products. As far as I can tell, without access to Shopify's analytics API, this is not possible. How can I do this?
What you want to build is perfectly possible. However, you need to generate Private App Credentials, so you can use Shopify API. It doesn't matter if you have an account by yourself, someone else can follow these steps and send you the credentials your way.
If you don't actually need to modify anything through the API, you could have them set a webhook (Settings -> Notifications -> Webhook) on Order Creation (or similar) that posts to your server and you can check what product got sold and see if it has got the tag.
The "easy" way to do this is to create an app that receives order webhooks and can check on tagged products and keep a sum of target items sold.
Then the app should have use a script tag to insert a simple script with the current value into the web page at a configured place by css selector
OR the app could update one or more snippet files that you could include until the promo is done.
I'd tend to go with the script tag option since that's a bit more flexible and you should be able to change your theme when the promo is over to report results without having to touch the app again.
I'm a first-time Shopify developer looking for a way to let customers enter additional data about themselves in Shopify. Specifically, I'd like to add a page or modify the account info page so the customer can enter measurements. I'd then like to take that measurement information, process it, and return a recommended size for products in the shop.
Is this possible in Shopify? I am trying to figure out how to add metafields for customers to record their measurements, but I'm a bit lost.
This should work, but would require a fair bit of customization on the merchant's part and is a bit of a hack:
When a customer is logged in their info is available through Liquid.
This allows you to reference that customer's data when rendering shop pages, e.g. a Product page.
You can assign Metafields to customers using the API. These are also available through Liquid.
Putting this all together, you can have a form on the shopfront asking the customer for info once they're logged in. The form submits to your server where you add the info to the Customer object as Metafields using the API. Then you have some clever Liquid on the Product page that either does the necessary calculations itself or embeds the relevant info into javascript to be processed client-side.
on my website I sell unique items. I have programmed it so that on the selling page, users can select any amount of these items, and it calculates the cost. The key is that I only have 1 of each of these items. So I need the shopping cart system to not allow the payment to go through unless it is available.
I've been searching for a good quick/easy/cheap solution and can't find one. I don't expect this site to make a lot of money (the transactions are a few bucks), so I didn't want to need a ssl certificate.
The only way I know of not needing an ssl certificate would be to use paypal or google checkout. However, I do not think there is a way of using these services and making paypal's server run a script to check how many are available on the site. Any solution?
Thanks
I was thinking about it more, and I think the problem is that once the user gets to the paypal payment screen, I have no control. I guess I could do something like they click the buy it now link, a php script updates it to sold, then they go to the paypal screen, but then they might not continue the purchase...
If you use PayPal Website Payments Standard (using a cart rather than 'Buy Now' Buttons) then you could use IPN or PDT (see the paypal docs here) to get PayPal to call back to you with the status of the payment.
The work flow would then be to set status to reserved when the item is added to the cart, and then wait for the IPN/PDT call to come back with the payment status, and mark the item as sold.
You would still need to check and reset to available any item that had been reserved for longer than say 2 Hours. (You could do this before serving a page to a user so that they have the latest availability and you don't need a cron job or long running process)
If you could provide a little more information about how you have implemented ur shopping card, it would have been more easier for other to assist! If you are using any ecommerce solution then it should be there already in the track inventory section. But Provided that you have implemented d shopping cart manually, why don't you add little bit of codes that checks the inventory status first before letting your customers check out?