I have implemented adobe analytics 5 domains UK, AU, NZ, USA & CA under one property. Suddenly, adobe analytics stopped populating data for UK, AU, and NZ domains for non-mobile devices. The data is available for mobile devices for the /UK, AU, and NZ domains. And it is working fine for both mobile and non-mobile devices for USA and CA domains. It would be great if someone helps me out on this issue
PS - Network hits for those domains are 200OK also the data is shown in the cloud debugger
Solved! Go to Solution.
Views
Replies
Total Likes
I strongly suggest that you set your cookie domain periods, otherwise it defaults to 2, and that won't work with domains that have 3 periods. See https://experienceleague.adobe.com/docs/analytics/implementation/vars/config-vars/cookiedomainperiod...
It's possible that while the network calls are being made (i.e. data is being sent to Adobe), the dimension that is holding your domain name isn't properly being populated? Or maybe you are sending to the wrong suite (a dev suite? the wrong suite name? etc)
Try looking at that server call more closely.. if you aren't as familiar at reading the parameters, you can try to compare against a server call that is working so that you can compare what is the same and what is different.
If you look at your data (without the server breakdown), does the total look like its only capturing the sites that also show data, or are the values significantly higher? This would be a clue that the server dimension isn't populating properly and that is the best place to start your investigation... if the totals are still low, then dig deeper into the suite that you are sending data too.... Make sure that it is sending to the correct suite... it could be the smallest typo too...
If I take our tracking calls and add "fakesuite" to the end of our suite name... I know this doesn't exist in Adobe, but the tracking call still returns a 200 response code... basically, Adobe doesn't use that information as part of the domain resolution, they just use it to process the data to the correct client suite....
(so let's say my suite is "testingsuite", and when I change it to "testingsuitefakesuite" both calls "work", but only one will send data into my actual suite)
Thanks, Jennifer for the reply.
The script tag implemented on all domains is the same, and we are capturing the data in a single report suite. So, the data is not going to a different report suite.y
I have observed a drop in numbers for overall level data too. In addition to that I have had to monitor order details for a day. I have placed multiple orders on UK, AU, and NZ domains. Then I store screenshots for reference and check the order id present in the screenshot in adobe workspace. And found that those details are not present in the adobe workspace. I also check those order IDs with backed data.
If you see the below screenshot, the numbers were captured for some days and the drop was observed from the 3rd of march because the nonmobile devices data is not getting populated.
Also, I compared server calls, the only difference between them is cookie support. and I don't thinks it could be the reason as data is being captured for mobile devices.
UK, AU, & Nz - Cookie support disabled
US, CA - Cookie support enabled
So, I am getting confused if I had not changed my setup. Network hits are passed to adobe as per the console and cloud debugger. Then why the data had stopped populating on the dashboard?
Views
Replies
Total Likes
That is very odd.. is it just orders that are failing? Are other metrics impacted?
If other orders are impacted, would you be willing to share one working and one non-working domains with me? (PM would be fine if you don't want to share here)
Also, this is a long shot... but if you are using a PurchaseID as a Unique Recording ID on your orders, can you confirm that those sites aren't reusing codes that have been used already on the other sites...
Since some data is getting through... (albeit very small amounts), I wonder if the issue could be Adobe seeing a repeated purchaseID value and ignoring the order as a "duplicate"?? Remember, purchaseID is limited to 20 characters... it could be that you have more than that and the end is truncated, and therefore lots of purchases could be lost as they are actually different numbers that no longer look different?
If you aren't near your 20 character limit, maybe try appending a letter or two to the start of the purchaseId to make it site specific?? (i.e. "us" + xxxx OR "uk" + xxx, etc)
Including visits, other metrics are getting impacted from 3rd march for non-mobile devices. I have shared a screenshot with you on PM.
I download purchase id data from the data warehouse and nothing suspicious was found there.
Sometimes I have observed the XHR server call/post method, but as per my knowledge, that would not be the case.
My website is based on react, is there anything that I need to check on the website too?
This is a head scratcher for sure... I can see that Cart Views is also impacted.. and that doesn't use PurchaseId as a unique reference... so it can't be that.... unless you have changed the default behaviour to use serialization...
I am on two versions of your site comparing a cart view on each variant and I can't see anything that looks amiss between the two.... I'm still looking though...
I am not using any serialization. Do let me know if you find anything that impacted our data tracking.
Literally the only difference I can see (and I really don't think this would impact tracking things like Orders and Cart Views), is that on the site that is not working (i.e. your UK site), "Cookies Enabled" is set to No.. whereas on your working site (i.e. US site), it's set to Yes....
I then checked your .ca and your .co.nz sites... ca (which is working) has cookies enabled, and co.nz site (which is not) has cookies not enabled...
It looks like the sites most impacted (based on the samples) are the ones that have more domain periods.... so ".xxx" vs ".xx.xx"??
I don't know why that would make a difference... but currently it's the only thing that I can see that is set differently from the .xxx sites...
I will continue to think about this issue... and maybe another advisor will have some ideas as well.... but maybe take a look at the cookie configurations and see if maybe some minor tweaks could get this to be consistent between the sites (even if only to rule out that difference as a factor)...
Thank you for the time and effort you spent on the suggestion. I will drill down further into it and I will keep you posted on the results.
Views
Replies
Total Likes
You're welcome.. I wish I could have found a more concrete "smoking gun" so to speak.... if this doesn't pan out, you might need to get Client Care involved who can look at the raw data and see if there is something strange happening there...
Oh, one more thing.. are you using the Experience Platform Debugger? Have you tried logging in to it and enabling the post-processed hits? Maybe there is something happening during post processing that we can't see here on the surface checks?
Views
Replies
Total Likes
Ah! I missed that part. Thanks for pointing this out. I will check "post-processed hits" and share the screenshot with you
It takes quite long time to load "post processed data" in debugger for AU, NZ & UK domains (I have waited for more than 15 minutes). While, it was loaded faster for US domain compared to them (in 2/3 minutes)
Views
Replies
Total Likes
Ouch... that definitely warrants a support call...
Some questions from me:
Hi Yuhuisg,
I strongly suggest that you set your cookie domain periods, otherwise it defaults to 2, and that won't work with domains that have 3 periods. See https://experienceleague.adobe.com/docs/analytics/implementation/vars/config-vars/cookiedomainperiod...
Views
Likes
Replies