Track State / Track Action not firing on Purchase Confirmation when app is suspended — expected Adobe behavior? | Community
Skip to main content
J
jaishal
Level 4
July 8, 2026
Question

Track State / Track Action not firing on Purchase Confirmation when app is suspended — expected Adobe behavior?

  • July 8, 2026
  • 2 replies
  • 39 views

Hi everyone, I’m running into an issue with Adobe Analytics on our mobile app and hoping someone can clarify whether this is expected behavior or a configuration gap.

We’ve noticed that on certain flows, when a user completes a purchase and lands on the Purchase Confirmation page, if they suspend the app immediately (background the app, switch apps, lock the device, etc.), our Track State and Track Action calls for the confirmation step do not fire.

This is causing a measurable drop in attribution — we’re missing at least ~20 confirmed customers per day because the confirmation events never reach Adobe.

Expected behavior

Track State / Track Action should fire as soon as the user lands on the confirmation page, even if the app is suspended right afterward.

Actual behavior

Events only fire if the user stays active on the confirmation page long enough for the hit to dispatch. If the app is suspended immediately, the confirmation events are dropped.

Questions for the community

  • Is this expected behavior with Adobe’s mobile SDK lifecycle handling?

  • Does Adobe drop hits if the app is backgrounded before dispatch completes?

  • Are there recommended configurations or patterns to ensure critical events (like purchase confirmation) fire reliably even during rapid app suspension?

  • Should we move the confirmation event to a more synchronous trigger or queue it before the app enters background?

Any guidance or best practices would be greatly appreciated. We want to ensure our purchase tracking is accurate and not losing conversions due to lifecycle timing.

Thanks in advance!

2 replies

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
July 8, 2026

Default App behaviour only sends hits when the app is active, when the app is sent to the background activity is paused. 

 

I am not even sure if enabling “offline” tracking would fix this, as pausing Adobe tracking is different than an App being run without Internet.

 

Honestly, this sounds more like a race condition of your checkout flow. If this were our app, I would ask our developers to process the purchase, send the tracking, and then show the confirmation; ensuring that the tracking is complete before the user gets the visual confirmation?

 

The tracking hit shouldn’t be significantly slow, I am kind of surprised you are having that may lost purchases due to users closing / sending the app in to background. You should also maybe check with your implementation that there isn’t something holding up the tracking calls?

manpreetkaur27
Adobe Support
manpreetkaur27Adobe Support
Adobe Support
July 10, 2026

Based on the behavior you described, this is generally consistent with how mobile app lifecycle timing can affect analytics delivery.

trackState and trackAction are triggered from the app, but that does not necessarily guarantee the hit has been fully dispatched and processed before the app is backgrounded or suspended. If the user leaves the app immediately after landing on the confirmation screen, there can be cases where the confirmation-related event does not complete delivery.

You may treat these as two separate signals:

  1. Purchase event
    Fire this at the moment the transaction is successfully confirmed by the app/backend flow.

  2. Confirmation screen view
    Fire this when the confirmation page or screen is displayed.

I think this would be more reliable because it avoids making purchase attribution dependent on the user remaining active on the confirmation screen long enough for the event to finish sending.

 

Terms & ConditionsAccessibility statement

Loading footer...