RudderStack now supports the Singular SDID for mobile attribution

If you run a mobile app with Singular for attribution and RudderStack for data collection, you’ve probably built what Singular calls an independent hybrid setup. Singular SDK handles installs, sessions, deep linking, and SKAdNetwork. RudderStack handles in-app events and routes them to Singular alongside every other destination in your stack. It’s the “best of both worlds” architecture, and it works well.

That architecture still works. The gap was in how SDID—Singular's new universal device identifier—flowed through the server-side pipeline.

SDID, or Singular Device ID, is Singular's answer to a post-ATT world where IDFA only reaches roughly 25% of iOS users. Rather than depending on Apple or Google's device identifiers, Singular generates their own first-party ID at the moment of first app open. When a customer adopts SDID, Singular's server starts returning it in the response to the initial session event, and V2 is the API built around it. CDPs without V2 support can still send events, but only via legacy identifiers. SDID never makes it into the server-side pipeline, so the attribution accuracy SDID was built to restore doesn't carry through.

With SDID V2, RudderStack will automatically detect SDID in your event payloads and routes to Singular’s V2 endpoints. No configuration changes. No dashboard updates. No migration.

Why IDFA alone no longer reaches most iOS users

Apple’s App Tracking Transparency framework reduced IDFA availability to roughly 25% of iOS users. The identifiers that mobile attribution has relied on for years are going away, and MMPs are adapting. Singular’s answer is SDID: a universal device identifier generated server-side that works across platforms without depending on IDFA, AIFA, or any other OS-level ID.

Singular is rolling SDID out across their customer base. When a customer's account is enabled, the Singular SDK starts returning SDID in its session response. CDPs still on V1 have no way to pass SDID through their server-side pipeline. Events keep flowing, but via IDFA and other legacy IDs that cover a shrinking share of users. The longer a team waits, the more attribution data falls into the gap.

This is a slow attribution bleed, not a hard failure. Events don't stop, but they increasingly route through identifiers that can't reach most of your iOS users. SDID was built to close that gap. But a CDP that can't pass SDID server-side can't help you close it.

How RudderStack routes SDID through the server-side pipeline

The change lives entirely in RudderStack’s transformer service. There are no SDK modifications, no new dashboard fields, and no configuration toggles.

Here’s the logic:

Auto-detection and routing

When an event arrives at the Singular transformer, RudderStack checks for the presence of singularDeviceId in the integration options (integrations.Singular.singularDeviceId). If it’s there, the event routes to Singular’s V2 endpoint (/api/v2/evt) with the SDID parameter. If it’s not there, the event routes to V1 exactly as before. Existing customers without SDID see zero change.

Platform ID handling

When SDID is present, platform-specific device IDs (IDFA, IDFV, AIFA) are dropped from the request. Singular confirmed that SDID replaces these identifiers entirely in V2 mode.

LAUNCH endpoint skip

In hybrid mode, the Singular SDK already handles session tracking. RudderStack skips the LAUNCH endpoint when SDID is detected, preventing duplicate session events.

Privacy flag support

The limitDataSharing flag can be passed alongside SDID via integration options. RudderStack maps it to Singular’s data_sharing_options parameter for GDPR and CCPA compliance.

Partner attribution

All requests to Singular now include partner=rudderstack, giving you visibility into RudderStack-sourced events in the Singular dashboard.

Data isolation

SDID is passed via RudderStack’s integrationOpts pattern, not in the event properties. This means the Singular Device ID is only sent to Singular. It doesn’t leak to Amplitude, Mixpanel, or any other destination in your stack.

What your instrumentation looks like

If you’re already running a hybrid setup, the only change is passing the SDID from the Singular SDK callback into your RudderStack track calls via integration options.

The Singular SDK provides the SDID through its sdidReceived callback. Your bridging code captures it and passes it to RudderStack. From there, the transformer handles everything.

How to pass SDID from Singular to RudderStackGet started

This update is available now to all RudderStack customers at every pricing tier. If you’re already sending events to Singular through RudderStack, here’s what to do:

1. Check with Singular whether SDID is enabled (or will be enabled) on your account.
2. Implement the SDID bridge in your mobile app: capture the SDID from the Singular SDK’s sdidReceived callback and store it for use in RudderStack calls.
3. Pass the SDID in your track calls via integrations.Singular.singularDeviceId.
4. Verify delivery in the Singular dashboard. Events should appear with partner=rudderstack attribution.

If SDID isn’t enabled on your Singular account yet, there’s nothing to do. Your V1 integration continues to work unchanged. When Singular does enable SDID, you’ll be ready.

Read the Singular destination documentation to get started