To begin with, since we implemented visitor ID service (and started using first party cookie for visitor id) our cross domain tracking got f*cked.
The scenario is
- a visitor lands on www.rackspace.co.uk
- clicks on start a chat button and a new pop up come up
- when a visitor types in something in the chat box event77 fires
The issue is that now in marketing channels 60% of event77 go to session refresh channel. This would suggest that the chat window sees it as a new session but I maybe it simply sees it as a new visitor with a new ID. Could someone help out as I have no idea how to fix it.
Thanks for the help!
The ID service has undergone extensive changes since this was posted. Please review the latest on Adobe's Unified Customer Profile - https://helpx.adobe.com/marketing-cloud/how-to/unified-profile.html
It looks like the latest release of Visitor ID looks to fix the issues with cross domain (although doesn't explicitly say there was an issue to begin with...)
When you update to the new 1.6.0 code it changes the default loadTimeout to 30secs however if like us you were advised to manually set the loadTimeout to a different time in DTM you'll now need to make sure you remove this to let the default time take precedence.
I haven't implemented 1.6.0 yet plan to begin dev testing next week along with AppMeasurement 1.6.2 but hoping it starts to resolve this issue.
In our case is the same. I increased the load timeout to 3 seconds as per arob87 suggestion in a pervious post and it did help. However, still around 50% of visitors going do a different domain are seen as new visitors. The company is not able to evaluate key conversations based on website interactions that happen on another domain. Client care is useless as they barely understand the issue. I can't believe that this is a known issue and there is no documentation about it. Moreover, client care have no clue about it as well.
Secondly, Visitor ID service must support passing the mid in the query string rather then f*cking around with API calls and timeouts. I found the article (https://www.pedromonjo.com/2015/08/hybrid-apps-visitor-stitching-visitor-id-service/) which suggests exactly that and suggest to use setMarketingCloudVisitorID() method.
I can see that visitor ID does have this method in the code. However, this method is not documented under Code Library section(https://marketing.adobe.com/resources/help/en_US/mcvid/mcvid_library.html)
Could Adobe please comment on this approach.
@Tanmay - the incident number is "151026-000235", but please know that your team is already very on top of the matter (i.e. a dedicated Product Manager is assigned exclusively to the VID service, and I am receiving updates as a fix continues to be worked towards).
@RyoMatsumoto - you're right that it's an issue with the Visitor ID service. And yes, it's the "loadtimeout" that we've been adjusting. At first we started with smaller increments (i.e. 900ms and then 1500ms), and when none of the increases have worked, the most recent was to set it extremely high at 30000 ms (30 seconds) ...which we haven't attempted yet given that it's not a quick/easy process for us to update our AppMeasurement file.
If you're interested, Aaron Hadley (firstname.lastname@example.org) may be able to help you enable some client testing they are doing in their efforts to work towards a fix. Here is a recent update:
From a product update perspective, our engineering team just released a non-production version of the VisitorAPI code that adds functionality to track timeouts specifically. We are in process of having a number of customers deploy this version in order to collect better information on the timeout behavior. These results will influence the eventual fix for the issue.
I believe the timeout increase to 30000 is only recommended in conjunction with using the new code. Here are the instructions we had received:
1 Set Timeout to 30000 milliseconds (30 seconds).
2 Enable the flag to capture instrumentation metrics (this can be disabled after 24 hours if desired).
In code, they would add:
var visitor = Visitor.getInstance(
Some customers have tested at 30000 ms over 24-48 hours and then reverted back to previous timeout settings. I’m not sure if that type of approach would work with your release processes or not.
I suggest reaching out to Aaron if you'd like to inquire further about this. Hope this help.
we have same problem.
I think that VistorID service has some problems.
1:in case of use cname(fpc).
at new visitors land satellite domain at first time(not visit main domain)
VisitorID service generated & write crazy mid to main domain amcv_orgID cookie.
(Normal operation: If users accept 3rd party cookies,same mid value is generate & write to cookie)
Adobe already fixed this bug.It occurred from 28th March 2016 to 19th May 2016.
If you use omtrdc.net,This problem did not occur.
2:in case of repeat users come to sites.they came before the implement VisitorID service(they have s_vi cookie)
Normal operation: If they land VisitorID service implemented sites at first time.
VisitorID service generate mid and converts s_vi to aid,after that mid&aid are save to cookie&send beacon.
Adobe Analytics ditect user by aid.
but occasionally Visitor ID service can't convert s_vi to aid.Then user has only mid & Adobe Analytics Treat as new user.
In general, you can fix If you set the "loadTimeout" parameter of VisitorID service(default value is 1500)
Usually we set 2000 or 3000.
Still but, there is a failure case.
s.t() was run before return value from Visitor ID service.
(we found by local proxy software)
We think that There are times when loadtimeout is not operating properly.
Also such as tag location on page(fire timing),Line speed,machine speed and other elements on page affect it.
in often my encounter case, open satellite domain by new popup/window/tab from main domain at first time(User doesn't have satellite domain's amcv_ cookie.)
Is loadtimeout parameters you've adjusted in appmesurement?
We've been experiencing the same issue since implementing AppMeasurement last March.
It's a known issue to Adobe and their Engineering team is currently working on a fix (although it's unknown as to when it will be available).
At Adobe's recommendation we adjusted our timeout settings in AppMeasurement multiple times, but unfortunately it hasn't helped the issue (at least in our case). Maybe it's worth considering for you to try anyway.