Why are tracking callbacks executing twice?

[Jacob-DDdev]

I'm registering a callback using s.registerPostTrackCallback() . In particular, within the console I'm testing with

s.registerPostTrackCallback(function(){console.log('test text')};

On the page, I click an object that sends an s.t() beacon and the network calls show that only one beacon fired, but the console is displaying

test text
test text

 What else could be executing this callback causing it to duplicate the expected output?

[MSchoenmakers-Signify · Accepted solution]

Hi jkm-disco,

I've seen this before too, and I came to the conclusion this occurs as soon as the data is being sent in a POST request instead of a GET request. At that point, the XHR is triggering the request for a second time.

I've reported this about a year ago at Adobe (via customer care), but after some disscussion I gave up and implemented a hotfix myself instead of waiting for Adobe engineers to fix the bug.

Maybe, since you are facing it too, it is time to re-address to issue to Adobe...

Regards,

Martijn

[Jacob-DDdev]

Hi Martijn,

That makes sense since these are POST requests. Seems worth addressing to Adobe since the registerPostTrackCallback() feature is extremely useful.

Do you have an Experience League post suggesting this fix so that I can follow it?

Also, could you give me a rough idea of your work around because it's going to be rough to track down every time a beacon is fired in order to inject the desired functionality.

Thank you very much,

Jacob

[Jacob-DDdev]

I s'pose if one knew that each beacon were always going to be a POST request, there might be a way of leveraging the length of the requestURL.

Maybe as a reasonable hack, one could force the size of the requestURL to always be big enough to require a POST request (maybe setting up registerPreTrackCallback() to force the size of the request) and then put a condition in all PostTrackCallbacks to run only when the requestURL is greater than the necessary length.

[MSchoenmakers-Signify]

Hi @Jacob-DDdev,

[MSchoenmakers-Signify]

Hi @Jacob-DDdev, for what's worth: the work-around I use is based on the asumption it being highly unlikely that two succeeding pixels are alike. Therefore in my callback function I keep track of the last payload (from the parameter) and compare that to the last received. If they are equal, the call is ignored. Furthermore: I see if I can get my Customer Care ticket reopened and will refer this topic.

[MSchoenmakers-Signify]

Recreated another issue with Customer Care: #200930-000158

[MSchoenmakers-Signify]

Hi @Jacob-DDdev, FYI: I just received confirmation that the Adobe engineering team has identified this as a bug and will create a fix in a future release. I don't have any information on when we can expect this to be fixed.

[Jacob-DDdev]

Thanks @MSchoenmakers-Signify . I appreciate you letting me know.

[MSchoenmakers-Signify]

Hi @Jacob-DDdev,

for what's worth: the work-around I use is based on the asumption it being highly unlikely that two succeeding pixels are alike.

Therefore in my callback function I keep track of the last payload (from the parameter) and compare that to the last received. If they are equal, the call is ignored.

Furthermore: I see if I can get my Customer Care ticket reopened and will refer this topic.

[Jacob-DDdev]

As per @MSchoenmakers-Signify mention of the bug, the workaround that I'm using is as follows:

On Library Load, I'm updating the s.t() function.

var tempTrack = s.t.bind({});
s.t = function(e,t,justInCaseParam,justInCaseParam2){
    tempTrack(e,t,justInCaseParam,justInCaseParam2);
    someOtherPostBeaconCode();
}

Seems to be sufficient to just add on to the existing track function, but played it safe, in case new parameters are added to the s.t() function in the future. Similar code can be replicated for s.tl() as well.