1. The Problem: Two-Thirds of iPhone Traffic Has No Deterministic ID

When Apple shipped App Tracking Transparency with iOS 14.5, the Identifier for Advertisers stopped being a default. Before ATT, IDFA availability sat above 90% because opting out required a deliberate trip into Settings. ATT inverted the model into explicit opt-in, and industry opt-in rates settled in the 20 to 35 percent range for consumer apps, lower in gaming and some utility categories.

The arithmetic matters for anyone running paid media: for roughly two-thirds of iPhone users, deterministic cross-app attribution simply does not exist. The user clicked an ad, and there is no identifier that joins that click to what happened next.

What changedBefore ATTAfter ATT
IDFA availabilityAbove 90% by default20–35% opt-in, category dependent
Attribution typeDeterministic, user-levelAggregated or modelled for most traffic
Reporting latencyReal timeDelayed by an Apple-controlled timer on the native path
User-level rowsAvailableNot available on Apple's privacy-preserving path

Android took a different road. Google Play's referrer API and third-party advertising IDs remain largely intact, so device-level signal is still available on that side for most volume. The asymmetry between iOS and Android measurement is one of the more underappreciated operational realities in mobile marketing.

2. Two Different Answers: SKAdNetwork Versus Consortium IDs

Apple's answer was SKAdNetwork — the operating system, not the advertiser, controls attribution and reports it back aggregated, on a delay, with intentional noise. Conversion values are capped at a 6-bit integer (0–63), one postback arrives per install, and no user identifier ever leaves the device. You are measuring campaigns, not people.

China did not take that route. There is no equivalent of a single operating-system-controlled attribution API in the Chinese market. Instead, two mechanisms emerged, and they coexist:

Western defaultChina
Attribution authorityApple's SKAdNetwork, OS-controlledIndustry consortium and individual platforms
Identifier typeNone (aggregated only)Device-derived IDs: CAID, PAID
GranularityCampaign level, aggregatedDevice level, deterministic
User-level rowsNot availableAvailable to the receiving advertiser
GovernanceAppleChina Advertising Association (CAID); individual platforms (PAID)

The practical consequence is significant. An advertiser running in China can, in principle, receive a device-level identifier that joins a click to a downstream conversion — the thing that ATT removed in Western markets. That is only possible because the identifier is derived from device parameters rather than issued by Apple.

3. CAID: The Industry-Consortium Identifier

CAID is the Chinese advertising industry's collective answer, produced under the China Advertising Association. The rationale is stated plainly in Baidu's own developer documentation: IDFA began being restricted from iOS 14, and no other device information could replace it — so device information is used to generate CAID as a substitute for IDFA in attribution.

Its structure is worth understanding because it appears in the raw data you receive:

FieldMeaning
Leading segmentA short numeric prefix, for example 00_, identifying the generation scheme
Core identifierA long hexadecimal string — the derived device identifier itself
versionThe algorithm version that produced the identifier, for example 20260506
vendorWhich vendor's algorithm implementation generated it

A real CAID payload from the documentation carries multiple candidates at once, each tagged with its version and vendor, plus a generateTime timestamp. That structure is deliberate: the receiving system can pick the newest supported version and fall back if it cannot parse it.

4. The 2026 CAID Algorithm Switch

This is the part most advertisers did not act on, and it has a dated schedule.

Per the China Advertising Association, the 2026 annual algorithm update was scheduled to begin with a central server upgrade on Monday 22 June 2026, supporting the new algorithm version, and complete the formal switch on Tuesday 30 June 2026.

The guidance issued alongside it is a window-management instruction: during the upgrade period, prefer the new version (20260506) and keep the old version (20250325) as a fallback so the transition is smooth. Older generations such as 20230330 also appear in payloads as further fallbacks.

For an advertiser or an MMP, the operational implication is concrete. If your conversion callback pipeline only accepts one CAID version, you have a single point of failure during every annual switch. The correct design accepts a ranked list and resolves against the versions the platform currently supports.

5. PAID: Baidu's Own Construction

Alongside the consortium identifier, Baidu maintains a separate device identifier of its own: PAID. It has existed at Baidu since 2023, and it also appears on ByteDance's ad platforms — so it is a platform-level technique, not a Baidu-only one.

PAID is built from three parameters, each of which the media platform and the advertiser can both obtain without handling personal data:

InputNote
System initialisation time (Initialization Time)Device-level, non-private
System update time (Update Time)Device-level, non-private
System boot time (Boot Time)Device-level, non-private

Each is MD5-hashed into a 32-character lowercase string, and the three are then joined with hyphens. The result is a parameter over 90 characters long, which Baidu passes to the advertiser for attribution monitoring and conversion callback.

Two practical notes. First, the name is a false friend: PAID here does not mean "paid", and "PAID attribution" is not paid attribution. The expansion is not officially published; plausible readings are Private Advertising ID or Private Anonymization ID. Second, PAID attribution currently requires a separate application to Baidu before it can be used — it is not on by default.

There is a useful piece of corroboration available to anyone auditing this. Baidu's own advertising SDK privacy disclosure lists, among the device information it collects, the device restart information, the device system update time and the device system creation time. Those are the three PAID inputs, disclosed in public-facing privacy documentation. An advertiser does not have to take the construction on faith.

6. What Baidu Actually Sends You

Baidu's conversion callback documentation defines the parameters available on the return path. The device identifiers are the ones that matter for attribution:

ParameterMeaning
idfaiOS device identifier, original value
imeiAndroid device identifier, original value (32-character lowercase MD5 where applicable)
oaidAndroid device identifier, original value
android_idAndroid device identifier, original value (32-character lowercase MD5)
caidCAID payload — a ranked list of candidates with version and vendor
attribution_eshow_scoreBaidu-supplied flag governing impression attribution

Two of these deserve separate attention.

CAID arrives as a list, not a value. As shown in section 3, the payload carries several candidates distinguished by version and vendor. A pipeline that reads caid as a single string will fail on it.

attribution_eshow_score is a media recommendation, not a metric. Baidu issues this field automatically on impression-attributed conversion callbacks. A value of 0 means the media side does not recommend returning that impression-attributed traffic; a value of 1 means it does. Treating it as an instruction rather than a diagnostic is the difference between a clean callback pipeline and one that feeds impression-attributed noise into optimisation.

Baidu also supports an extensive set of optional vertical parameters alongside the identifiers — for example book title, reading chapter count, and short-drama theatre identifiers — which indicates how much downstream context the platform is willing to carry on the callback.

7. The Signature and the Callback

Convincing a platform to accept your callbacks requires proving the callback is yours. Baidu's documentation specifies the signing method: take the substituted callback URL excluding the final signature parameter, append your akey, and MD5 the result.

The mechanics are simple; the failure modes are not. Three that recur:

  1. Signing the wrong string. The signature must be computed over the URL after macro substitution but before the signature parameter is appended. Signing the templated URL, or the URL including a placeholder signature, produces a mismatch that looks like an authorisation failure.
  2. Macro substitution order. If a substituted value itself contains characters that alter the URL structure, the signed string and the transmitted string diverge.
  3. Reading caid as a scalar rather than a ranked list, as noted above.

8. What This Means for International Brands

The strategic point is that China's iOS measurement problem was solved in a way that does not resemble the Western solution, and that has three consequences for planning.

Your iOS conversion data in China can be better than in your home market. Because CAID and PAID are device-derived rather than platform-issued, a correctly configured pipeline can receive device-level attribution signal for iOS traffic that would be unattributable under SKAdNetwork alone. Whether you actually receive it depends entirely on your callback configuration.

The identifiers are not interchangeable across platforms. CAID is consortium-governed with a version schedule; PAID is platform-built and requires separate application. A brand assuming a single "China iOS ID" exists will mis-specify the integration.

The annual CAID version switch is a recurring operational event. It happens on a published schedule, and the correct handling — accept a ranked list, prefer the newest supported version, keep the prior version as fallback — needs to be in the pipeline, not in someone's calendar reminder.

9. Common Failure Modes

SymptomLikely cause
CAID missing entirely from callbacksCallback pipeline reads caid as a single string and discards the array
iOS conversions appear to drop after late JunePipeline pinned to a superseded CAID version during the annual switch
Callback rejected as unauthorisedSignature computed over the templated URL or over the URL including the signature parameter
Impression-attributed conversions inflate reportsattribution_eshow_score treated as a metric rather than a media recommendation flag
PAID never appears in dataPAID attribution has not been separately applied for from Baidu
iOS and Android performance look inconsistent in reportingiOS signal dependent on ATT consent and on identifier configuration; Android unaffected by ATT

10. Action Plan

PriorityActionWhy
P0Audit whether your conversion callback pipeline accepts caid as an array with version and vendor, not as a single stringCAID arrives as a ranked candidate list by design
P0Confirm which CAID version your pipeline currently resolves, and whether it prefers the newest supported version with a fallbackThe annual algorithm switch is a dated, recurring event
P0Verify your callback signature is computed over the post-substitution URL excluding the signature parameter, appending akeyThe most common cause of rejected callbacks
P1Establish whether PAID attribution is enabled for your account, and apply separately to Baidu if it is in scopePAID is not on by default
P1Instrument attribution_eshow_score and use it to filter impression-attributed returnsIt is a media recommendation flag, not a performance metric
P1Document which identifier you receive per platform (CAID on Baidu and ByteDance; PAID where applied for)Identifiers are not interchangeable across platforms
P2Reconcile iOS and Android reporting expectations against ATT consent realityDeterministic iOS signal is consent-dependent; Android is not affected by ATT
P2Add CAID version monitoring to your regular data-quality checksA silent version mismatch degrades data without raising an error

11. Key Takeaways

  • ATT reduced IDFA availability to an estimated 20–35 percent opt-in, leaving roughly two-thirds of iPhone traffic without a deterministic cross-app identifier.
  • Apple's answer was SKAdNetwork — aggregated, delayed, one 6-bit conversion value (0–63) per install, no user-level data.
  • China did not adopt SKAdNetwork. It built device-derived identifiers instead: CAID, produced under the China Advertising Association, and PAID, built by individual platforms including Baidu and ByteDance.
  • Baidu's documentation states the rationale directly: IDFA became restricted from iOS 14 and no other device information could replace it, so device information is used to generate CAID as a substitute for IDFA in attribution.
  • The 2026 CAID algorithm update was scheduled for a central server upgrade starting 22 June 2026, with the formal switch completed 30 June 2026. Guidance during the transition: prefer version 20260506, keep 20250325 as a fallback.
  • PAID is built from three non-private device timestamps — system initialisation time, system update time and system boot time — each MD5-hashed to 32 lowercase characters and joined with hyphens into a parameter over 90 characters long.
  • PAID does not mean "paid." The expansion is not officially published. PAID attribution requires a separate application to Baidu and is not enabled by default.
  • The PAID inputs are visible in Baidu's own SDK privacy disclosure, which lists device restart information, system update time and system creation time among the device information it collects.
  • Baidu's callback returns caid as a ranked list carrying version and vendor, alongside idfa, imei, oaid and android_id, plus attribution_eshow_score — where 0 means the media side does not recommend returning that impression-attributed traffic and 1 means it does.
  • Callback signatures are computed over the substituted URL excluding the signature parameter, with akey appended, then MD5.
  • The operational risk is not the mechanism but the maintenance: a pipeline that reads caid as a scalar, or pins a single algorithm version, fails silently at each annual switch.
  • This article is a technical documentation summary for information purposes and is not legal or compliance advice. Identifier requirements and platform rules change; confirm current specifications with the platform and your MMP before changing production pipelines.

Sources