Duplicate server calls

[AEPAA]

I am seeing duplicate calls on the particular page. Whe testing my implementation.

Usually, we get two server calls while testing using debugger. But, here I am seeing one more duplicate which says text/ plain as content type.

Does anyone faced such issue , what could be the reason for this multiple call??

[igupta]

Hey @AEPAA ,

Can you please share screenshot? 

Best,

Isha

[Jennifer_Dungan]

I assume you are using Adobe Launch? If so, have you tried enabling the Satellite Debugger?

// Turn On Debugging
_satellite.setDebug(true);

// Turn Off Debugging
_satellite.setDebug(false);

This should help determine if multiple rules are being triggered creating duplicate calls.

[pradnya_balvir · Accepted solution]

Hi @AEPAA ,

Top Reasons for the Extra text/plain Adobe Analytics Call

1. CORS Preflight or Beacon API Fallback

• Adobe Analytics (AppMeasurement.js or Web SDK) tries to use modern methods like sendBeacon() or XMLHttpRequest.
• If those methods fail (e.g., CORS misconfiguration or security policy blocks it), it may fall back to a text/plain POST call.

Why it happens:

• Adobe AppMeasurement tries to send tracking data with Content-Type: application/x-www-form-urlencoded or application/json.
• Some browsers or environments force a fallback to text/plain if those fail.
• You'll see this especially when:
  • You're in a restricted iframe/webview
  • Or CSP (Content Security Policy) or CORS headers are misconfigured

Adobe Launch Rule Fires Twice

• A page view rule and a custom event rule (e.g., DOM Ready, Window Loaded) might both fire a s.t() call.

• If Adobe Launch is configured with custom code that also uses s.t() or s.tl(), you might get multiple hits, with one using a fallback transport method.

How to fix:

Step	Fix
1. Upgrade AppMeasurement.js	Ensure you're using the latest version of AppMeasurement or the Web SDK. Older versions are more prone to fallback behavior.
2. Check for Redundant Tracking	Review Adobe Launch rules or hardcoded calls. Make sure only one s.t() or s.tl() fires per page load or user action.
4. Fix CORS and CSP Issues	Make sure Adobe’s tracking domain allows CORS (Access-Control-Allow-Origin) and your Content Security Policy (CSP) allows beacons, XHR, and image requests.
5. Avoid Launch Fallbacks	If using sendBeacon, configure Adobe Launch to prefer image or XHR transport, or monitor the browser for sendBeacon() failures.
6. Use clearVars() in SPAs	For single-page apps, call s.clearVars() before every s.t() to prevent duplicate data in consecutive hits.
7. Add Console Logs	Temporarily log every s.t() or s.tl() call to confirm only one fires. This helps identify silent or unintended extra calls.

[harishkumar]

@AEPAA this happen if we have consent management implemented and sometime custom consent management implementation load analytics calls as text so that it does not get processed. However after consent is accepted and when user load the page it populate actual gif or xhr server call which are processed by adobe engines. 

[Sukrity_Wadhwa]

Hi @AEPAA,

Were you able to resolve this query with the help of the provided solutions, or do you still need further assistance? Please let us know. If any of the answers were helpful in moving you closer to a resolution, even partially, we encourage you to mark the one that helped the most as the 'Correct Reply.'

Thank you!