I85PREP
⌘ K
Adobe Analytics Developer Expert study materials
Adobe Analytics Developer Expert study resources

The Mobile App Upgrade That Lost Its Identity

Adobe Analytics Developer Expert · Put your knowledge to work in context.

All case studies

The Mobile App Upgrade That Lost Its Identity

A fintech client has an iOS and Android app using the Adobe Experience Platform Mobile SDK with Analytics and Identity for Edge Network extensions. They recently upgraded from the v4 SDK to the v5 SDK and enabled Edge Network. Post-upgrade, they see a 22% drop in unique visitors month-over-month and a spike in 'unknown' device type in some segments. The app uses a custom visitor ID set via setCustomerIDs in the v4 implementation, which was migrated to Identity.setIdentifiers in v5. The client also uses a CRM integration that joins on the custom visitor ID. The migration was done by a contractor who is no longer available, and there is no documentation of the identity configuration.

1. What are the most likely causes of the unique visitor drop and the 'unknown' device type spike, and how would you investigate?

Read the worked answer

Two symptoms, likely two related causes.

Unique visitor drop: The v4 setCustomerIDs and v5 Identity.setIdentifiers are not drop-in equivalents in terms of when they take effect and how they stitch to the ECID. If the contractor migrated the call but changed the identifier namespace, authentication state, or the timing (e.g., calling before the Identity extension initializes, or after the first sendEvent), the custom ID may not be stitching to the ECID. Result: the same user is counted as a new visitor, or the CRM join fails and the user falls into an anonymous bucket. A 22% drop is consistent with a subset of users (those who authenticate) losing their stitching.

'Unknown' device type: This is a separate signal. Device type is derived from the user agent / device context in the XDM payload. If the v5 migration changed how device context is populated (e.g., the Device extension is missing from the mobile property, or the datastream is not forwarding device context), the edge will not have device info and segments will show 'unknown'. This is a configuration gap, not an identity gap.

Investigation plan:

  1. Pull the mobile property configuration from the Tags UI and confirm which extensions are installed and their versions (Identity for Edge Network, Analytics, Device).
  2. Inspect a debug build with the Assurance (Project Griffon) session to see the actual setIdentifiers call, its namespace, auth state, and the ECID in the same session.
  3. Compare a known user's ECID and custom ID pre- and post-upgrade from the CRM side.
  4. Check the datastream mapping for device context fields.
  5. Segment the drop by authentication status - if the drop is concentrated in authenticated users, identity stitching is the cause; if it is uniform, look at the SDK initialization or Analytics extension config.

2. The CRM integration joins on the custom visitor ID. What is the risk if you simply re-run the migration to 'fix' identity, and how would you protect the CRM join?

Read the worked answer

Re-running the migration without understanding the current state risks compounding the problem: you could generate new ECIDs for users who already have stitched identities, orphaning the CRM join for the entire post-upgrade cohort. Identity is stateful - the ECID is persisted on-device and in the edge identity graph. A careless re-migration can break the graph for users who are currently correctly stitched.

Protection plan:

  1. Freeze and snapshot. Before any change, export the current identity configuration and a sample of on-device ECID-to-custom-ID mappings (via Assurance or a debug build) so you have a baseline to compare against.
  2. Stage environment first. Run the corrected migration in a staging mobile property with a separate datastream and report suite, and validate stitching end-to-end before touching production.
  3. Preserve the namespace. Do not change the identifier namespace or authentication state during the fix. The CRM join depends on the exact namespace string. A namespace change is a breaking change to the integration and must be coordinated with the CRM team.
  4. Backfill awareness. Users who lost stitching during the outage will have a gap. Coordinate with the CRM team on whether to backfill via the custom ID or accept the gap, and document it.
  5. Monitor. After release, track the ECID-to-custom-ID join rate and the authenticated-user segment size daily for two weeks, with an alert threshold.

The core judgement: identity migrations are not idempotent. Treat the fix as a new migration with a rollback plan, not a re-run of the old one.