I have an issue with the refunds import through standard Property menu "data import". I use refund import only by ga:transactionId.
As i have read in help in this case there is no need to supply any additional information about transaction (sku, quantity, revenue, etc.).
Whole transaction will be refunded.
In fact i see in report Sales Performance that all refunds are linked with correct transactionId, but have different date, source / medium, etc.
For me it seems to be absolutely random attribution (except date may be, it's date of import)
For example, one transactionId.
Originally it happened at June, 28 in yamarket / cpc. And refund is linked to June, 30 and webvisor.com / referral. Date of refunds common for all transactions and it is date of import (today). Source / medium is absolutely random.
May be i need to wait one day, but i doubt that.
And due to different dates if i choose date range that does not include both dates i will receive only refund or only transaction payment.
Does system work correct?
If system works correct, can i unload all refunds back?
All work as it supposed to be. While it is strange logic for my opinion.
Google will change help content to cover this topics.
Refunds are always linked to date of import, not to date of initial transaction.
And, unexpectedly for me, to the last session of buyer on the moment of import. So this session does not necessarily coincide with the purchase session if buyer visited site after transaction.
That's why i get different source/medium for refund and transaction.
Related
I use Woocommerce to add orders from admin manually. Most of my clients pay after 15 to 90 days after order is created, in some cases longer than 90 days.
I notice that Woocommerce Analytics always shows revenue based on Order created date. I agree with it by one point of view as order was created on that day, so, the revenue belong there.
I think orders tab in Analytics shows it right, which is Date, Order, customer, amount, etc..
But I think Revenue should be based on order->get_paid_date() rather than created date as the money still comes in on the paid date. If Woocommerce changes the formula, it would make little to no difference for those whose orders are paid online immediately. And it will take care of those whose orders are paid later on.
Just curious, since logically Revenue is the money coming into account and Analytics>Orders tab shows Orders by created date well already.
Thanks for your input for me to understand how Woocommerce thinks.
Currently Woocommerce Analytics does not take paid date meta into account, it considers order creation date for revenue consideration.
It depends how one looks it, it's right and wrong.
For my use, where customers pay days or months later, it's wrong. but still the order was placed on the creation date, so, the revenue should still be linked to the creation date. so, it's right too.
One thing I did was from Analytics settings, I removed some custom status of the order to exclude from Analytics, that way until the order is actually either in Pending status or Completed status, it does not consider it in revenue. Not a perfect solution, but it helps me to exclude canceled and some custom status like Quotation not be included in Revenue.
I ended up programming my own custom admin page where I pulled all orders in completed status with paid date between start and end date and did the total manually to get my actual income for the year.
Just for someone else looking for similar question, it might help.
I own multiple affiliate websites and I am currently working on a piece of software that matches clicks and sales to visitors in GA. This allows me to see my earnings, the number of transactions and best advertisers directly in GA rather than having to sum up the different commissions from various networks.
However, sometimes a sale is rejected by an advertiser, for instance if someone returns (some of) the products sold. In these cases, I need to update the sales in GA. I currently use the normal (not enhanced) GA E-commerce plugin where I can easily submit a transaction or (partial) refund with this payload via the measurement protocol:
{v: 1, t: transaction, tid: something, cid: something, ti: xxx, tr: (-)xx, ta: advertiser}
However, every time I issue a refund, GA increases the transaction count and conversion rate, which skews my data. How can I solve this? I've had a look at the enhanced E-commerce plugin, but it seems partial refunds only work when using products and their respective prices, which is information that I simply do not have for every sale.
Thanks in advance.
You can't. Even though Google supports negative transactions via their documentation this is not a refund, this is just another transaction (which e.g. means if you select your timeframe so that is encompasses only the original or only the negative transaction your data is just as skewed as before, this works only if both transactions are within the timeframe. Also make sure your negative transaction is attributed to the same channel as your original transaction, or channel based reporting will be off).
Even EEC does not reverse transactions, it stores the refund in a separate field.
Since a proper reversal or removal of transactions would require a massive recalculation of data I do not think this will come anytime soon.
i have a question on e-commerce tracking. As i know in a latter stage that a conversion is successful or not i want to be able to convert a sale as conversion but with 0 value and then when the sale is actually converted to change the value of revenue for this specific sale. Is somebody able to help on that?
Best regards and happy weekend to all.
As far as I can tell this does not really work.
If you do E-Commerce tracking you can send a second transaction using the same transaction id, and at a first glance this will look like it changed to original value; however internally this will still be recorded as two transactions and change some of your metrics (e.g. conversion rates). Also the second transaction will not be connected to the original session and will most likely be attributed to a different marketing channel. Still, this is the closest you will get to change the transaction value (and you won't be able to change goal conversion values at all).
While GA has data imports it does not have a transaction data import, and at least the free version cannot change data that is already collected (data imports only apply to newly incoming data), so this will not help you.
All in all it would be simpler/more reliable to pull the data via the API and connect it to your revenue data in a spreadsheet.
I wish to extract (via the Analytics Core Reporting API) all the transactions made TODAY by users that had a specific ga:eventCategory few weeks ago.
I'm looking to see the date of a transaction and all dated of event that are related to that transaction.
If GA was sql I would join by the ga user and take in the dimension both his transactions date and his dimension update date...
Thanks.
Noam.
Like I have indicated in my comment you can segment the data to include only those users who have the specific event. Segmentation works fine with the core reporting API.
Your segment defintion would look like this:
users::condition::ga:eventCategory==[myEventCategory]
(where obviously the thing in [brackets] is a placeholder that needs to be substituted for the event category name). The "users::" prefix means you are segmenting by user scope (as opposed to sessions), so this will include all sessions in the selected timeframe for users who had the event at least in one of their session (even if the event was outside the selected timeframe).
Select transactionId as dimension and some metric (revenue) and todays date and you are done. Or you would be done if this was actually going to work, but there are at least two caveats:
Google Analytics does not work in realtime, so it's unlikely that TODAYs transactions are fully available (Google says it's 24 hours until the data is processed - actually it might happen faster, but you cannot rely on it).
If a user has deleted his or her cookie she won't be recognized as a recurring user and GA will be unable to segment her out. The longer the interval between the event and the transaction the less likey it is that the GA cookie is still present.
So even with a technically correct query it might be that you won't get the data you need.
I've got a problem matching shopify data with google analytics data. The numbers were more than a few hundred dollars off, so I figured it was a bigger problem than the normal problems.
I exported the shopify sales and the sales counted in google analytics. The values and quanities of orders were the same, but the dates were different. In GA, it was saying a sale was on 3/6/2015, but shopify had it as 3/16/2015. I checked with the client and they had received that order on the 16th. So somehow GA had the time 10 days off. And this is happening on many orders, but not all.
Have you seen this before? And how is shopify sending an incorrect date to GA/how is GA reading an incorrect date?
I'm not sure what more information to give here. I checked the implementations and everything seemed normal.
in the addTrans and addItem calls you're passing the data to, there is no formally passed date. GA related the instance of the addTrans to whatever time it was received.
what % of orders would you say are being dated incorrectly?