Why are tracking callbacks executing twice?

Avatar

Avatar
Seeker
Level 3
jkm-disco
Level 3

Likes

24 likes

Total Posts

130 posts

Correct reply

15 solutions
Top badges earned
Seeker
Contributor
Shape 1
Give Back
Affirm 10
View profile

Avatar
Seeker
Level 3
jkm-disco
Level 3

Likes

24 likes

Total Posts

130 posts

Correct reply

15 solutions
Top badges earned
Seeker
Contributor
Shape 1
Give Back
Affirm 10
View profile
jkm-disco
Level 3

29-09-2020

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?

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar
Shape 1
Level 1
MSchoenmakers-Signify
Level 1

Likes

3 likes

Total Posts

7 posts

Correct reply

1 solution
Top badges earned
Shape 1
Boost 3
Boost 1
Affirm 1
View profile

Avatar
Shape 1
Level 1
MSchoenmakers-Signify
Level 1

Likes

3 likes

Total Posts

7 posts

Correct reply

1 solution
Top badges earned
Shape 1
Boost 3
Boost 1
Affirm 1
View profile
MSchoenmakers-Signify
Level 1

29-09-2020

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

Answers (2)

Answers (2)

Avatar

Avatar
Seeker
Level 3
jkm-disco
Level 3

Likes

24 likes

Total Posts

130 posts

Correct reply

15 solutions
Top badges earned
Seeker
Contributor
Shape 1
Give Back
Affirm 10
View profile

Avatar
Seeker
Level 3
jkm-disco
Level 3

Likes

24 likes

Total Posts

130 posts

Correct reply

15 solutions
Top badges earned
Seeker
Contributor
Shape 1
Give Back
Affirm 10
View profile
jkm-disco
Level 3

30-09-2020

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.

Avatar

Avatar
Shape 1
Level 1
MSchoenmakers-Signify
Level 1

Likes

3 likes

Total Posts

7 posts

Correct reply

1 solution
Top badges earned
Shape 1
Boost 3
Boost 1
Affirm 1
View profile

Avatar
Shape 1
Level 1
MSchoenmakers-Signify
Level 1

Likes

3 likes

Total Posts

7 posts

Correct reply

1 solution
Top badges earned
Shape 1
Boost 3
Boost 1
Affirm 1
View profile
MSchoenmakers-Signify
Level 1

30-09-2020

Hi @jkm-disco,

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.