I cleaned up Sales and Wishlist data but It still did not work. I am using Magento 2.3.4. any suggestions?
Same here on 2.3.3.
- followed exact config instructions
- read dozen topics and tried all sorts of solutions
- cleaned up all tables, like stated in this topic
Still giving me 404.
It's these (among a lot of other) things that irritates me about Magento 2. Sigh.
Hello @MacDokie, did you have any luck finding a solution for this? We're in the same "404" situation with the Advanced Reporting Data feature. Magento 2.3.4 version with the patch applied too. Appreciate it any suggestion @adrián_martínez1. Thanks!
Nope, and nobody is at home around here.
Delete your actual integration user and create a new with the name “Magento Analytics” with the email and password the the user profile of your admin bagento backend.
Select API-Analytics and save . Do magento flush and reauthorize user just created.
Then go to terminal and do cd public_html
do the 3 following statements:
./n98-magerun2.phar sys:cron:run analytics_subscribe
./n98-magerun2.phar sys:cron:run analytics_update
/n98-magerun2.phar sys:cron:run analytics_collect_data
do magento flush again
Advanced reporting should work now
Try deleting the "Magento Analytics user" from System -> Integrations menu and then add a new user, calling it "Magento Analytics". Wait until after the scheduled update time and then go to the Advanced Reporting link.
We found this made it work. However, we have a new user called "Magento Analytics user" now that we did not add, so perhaps this deletion was the key and not so much the name change in the user.
I know that this is bumping the question, but we experienced the same with 2.4.2 EE version. Our issue was orphaned wish list items, and next day we were able to access the Advanced reporting. However, since we created a ticket we got some other things to debug out of which one got my attention (for the people here that cleaning up orphaned products didn't sort out the issue) namely this one and I quote the support:
5. Check for escaped quotes and/or double quotes in sales_order_item table
Merchants having records with product names in sales_order_item table with either escaped double quotes (\\") or double quotes (") can create two different issues on MBI side:
· MBI cannot process the file and thus, merchant will not be able to access Advance Reporting (sees 404)
· MBI processes all but sales_order_item feed and thus, merchants will not see Product Data populated in the Advance Reports.
select name, count(*), sku from sales_order_item where name like '%\\\\"%' or name like '%\"%' group by name,sku;
Also, it doesn't support multi currency stores so there is that as well...
>>Check for escaped quotes and/or double quotes in sales_order_item table
>>Merchants having ... create two different issues on MBI side:
This seems to be a fairly major issue that is not mentioned in any documentation or troubleshooting checklists. My customer is experiencing the second issue described
MBI processes all but sales_order_item feed and thus, merchants will not see Product Data populated in the Advance Reports.
They sell screws and washers etc, so using a double quote in description is a long established euphemism for inches. Also the issue only started Jan 2021 and they had been using Magento for some time.
Is there a way to extract the contents of the .tgz extract file that is created so I can
check for this and any other possible issues?
I can see that it is encrypted in some way but could not figure out from the code
how or what key was used
Thanks in advance
We are using Magento 2.4.4 and we are also facing the very same issue.
We've tried everything (resetting api user, reviewing data in sales_order_item, etc.)
Advanced Reporting is enabled form backend and we are running analytics_subscribe, analytics_update and analytics_collect_data with success.
We don't have any error in logs whatsoever.
Does anyone have any tips regarding how to fix the 404 issue.
The only issue that we have is that it seems that generated data.tgz is corrupted (we can't open it). Could it be the reason of the issue?
Oh, by the way, we also tried to recreate the api user.